背景

在服務高度拆分，數(shù)據(jù)庫不斷細化切分的情況下，我們經(jīng)常有連接多臺數(shù)據(jù)庫查詢的需求，如果不斷的把數(shù)據(jù)庫連接的邏輯添加在代碼中，那么這種耦合會越來越嚴重，這會給程序的拓展和維護帶來很大的麻煩。

mysql的federated引擎，可以在本地創(chuàng)建遠程數(shù)據(jù)庫的映射表，創(chuàng)建完后，拓撲如下：

如此，我們可以在本地構(gòu)建多個遠程數(shù)據(jù)庫庫的統(tǒng)一入口，這樣可以極大的簡化在分布式環(huán)境中，跨服務器數(shù)據(jù)庫的交互查詢問題。

1.開啟引擎

查詢數(shù)據(jù)庫是否支持

SHOW ENGINES;

有，說明支持，但是沒有開啟，開啟一下：

配置文件添加：federated，如下：

[mysqld]

federated

#

# Remove leading # and set to the amount of RAM for the most important data

# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.

# innodb_buffer_pool_size = 128M

#

# Remove leading # to turn on a very important data integrity option: logging

# changes to the binary log between backups.

# log_bin

#

# Remove leading # to set options mainly useful for reporting servers.

# The server defaults are faster for transactions and fast SELECTs.

# Adjust sizes as needed, experiment to find the optimal values.

# join_buffer_size = 128M

# sort_buffer_size = 2M

# read_rnd_buffer_size = 2M

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks

symbolic-links=0

log-error=/var/log/mysqld.log

pid-file=/var/run/mysqld/mysqld.pid

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

然后重啟mysql，再次查詢，發(fā)現(xiàn)已經(jīng)開啟：

2.場景

數(shù)據(jù)庫1：阿里云 java4all,表product_stock；

數(shù)據(jù)庫2：華為云 wangtest1,表user;

user表中有一個product_stock_id。

需求：需要跨庫查詢。

3.創(chuàng)建數(shù)據(jù)庫表映射

在華為云的wangtest1數(shù)據(jù)庫中，創(chuàng)建一個阿里云的java4all庫的product_stock表的映射表。

CREATE TABLE `product_stock` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` varchar(255) DEFAULT NULL,

`stock` int(11) DEFAULT NULL COMMENT ‘庫存‘,

PRIMARY KEY (`id`)

) ENGINE=FEDERATED DEFAULT CHARSET=utf8 COMMENT=‘庫存表，來自阿里云映射‘

CONNECTION=‘mysql://username:[email?protected]:port/java4all/product_stock‘;

這里需要注意，數(shù)據(jù)庫引擎的選擇，要明確指定引擎ENGINE=FEDERATED，

創(chuàng)建完后，會發(fā)現(xiàn)，在wangtest1庫中，也有了product_stock表：

此時，其實在華為云的wangtest1庫中，就有了阿里云的java4all庫中的product_stock這張表的映射了。我們可以看到，這張表外觀看起來和正常的表是一樣的，但是其實華為云這邊這是存儲了表結(jié)構(gòu)，數(shù)據(jù)還是從阿里云拉取的。

我們嘗試在阿里云修改數(shù)據(jù)，在華為云這邊刷新，也會看到變化。反之也是可以的。在使用層面看來，這個product_stock和本地原本就創(chuàng)建了的效果是一樣的，各種查詢都是支持的，但是不建議給映射表寫的權(quán)限。

查詢測試：

SELECT * from user a ,product_stock ps

WHERE a.product_stock_id = ps.id

and ps.`name` LIKE CONCAT(‘%‘,‘香‘,‘%‘)

and a.user_type = 1;

4.注意事項

1.映射表的字段，要少于等于原表(遠程表)字段。

2.遠程表的數(shù)據(jù)庫據(jù)密碼，[email?protected]，因為在創(chuàng)建映射表時，CONNECTION=‘mysql://root:[email?protected]:3306/java4all/product_stock‘，這里用戶名密碼，和數(shù)據(jù)庫地址之間的分隔符是@，如果你的密碼含有@，會導致解析出錯。

3.修改本地表結(jié)構(gòu)，是不允許的，因為你這個表是映射遠程表的，遠程表沒改，你改了，可能會映射不上一些字段。如果遠程表修改了，這個表需要重新映射。所有，理論上，為了防止不必要的麻煩，本地的映射表禁止任何結(jié)構(gòu)性修改，如果遠程表結(jié)構(gòu)修改了，本地的刪掉重新映射即可。

4.刪除本地映射表，對遠程表無負作用。

5.本地數(shù)據(jù)庫服務必須支持federated引擎，遠程服務器可以不支持。

6.數(shù)據(jù)庫版本需要在5.0以上。

7.federated引擎是基于表級別的，無法實現(xiàn)基于庫級別的整體映射。

8.如果遠程表添加了索引，及時同步更新到本地映射表中。

9.limit是個比較慢的操作，引擎會將所有滿足條件的數(shù)據(jù)讀取到本地，再limit處理。

10.顯然，看起來，你可能會覺得，那我把各個相關(guān)微服務的表全部映射過來，那連分布式事務的問題都一并解決了，因為本地看起來就擁有所有的表，那分布式事務的各種解決方案都不需要存在了。這里，由于沒有這么大規(guī)模生產(chǎn)壓測過，不好定論，不好反駁。但是既然微服務拆分了，解耦了應用，那庫顯然也是解耦的，mysql只是提供了這種功能，讓你在某些特殊需求場景下，來連接和簡化多數(shù)據(jù)源數(shù)據(jù)的交互問題。而不是讓你里用這個，將原本做好了解耦和合理拆分的東西，再重新糅合一團。

11.Pay attention to the border！

5.關(guān)于連接的問題

1.本地虛擬表與遠程實體表之間是 TCP 長連接，并且是多個客戶端利用的。所以不用擔心因頻繁建立連接帶來的網(wǎng)絡開銷。

2.本虛擬表表與遠程實體表之間的網(wǎng)絡連接斷開后，當對虛擬表發(fā)起查詢時，它會嘗試重新連接遠程實體表，所以我們不用擔心網(wǎng)絡連接斷開造成的永久中斷問題。

3.如果長時間未對本地虛擬表作任何操作，虛擬表與實體表之間的連接將在遠程主機的 wait_timeout 秒后自動斷開，當對虛擬表發(fā)起查詢時，連接又會重新建立。

6.性能

由于少見有大廠專門對此進行過性能測試，網(wǎng)上資料也比較少，目前未見到什么明顯的性能短板，但沒有大規(guī)模生產(chǎn)使用，應該還是有短板的(待我去官網(wǎng)翻譯一波文檔)。打算踩坑的可以一起組團踩坑。直接上生產(chǎn)的，注意風險把控。

起碼是個跨服務查詢，數(shù)據(jù)量大的時候，網(wǎng)絡和傳輸應該是個起碼的瓶頸。

總結(jié)

以上是生活随笔為你收集整理的mysql ef 分布式事务_分布式事务系列--分布式跨库查询解决方案 mysql federated引擎的使用...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。