分布式事务系列--分布式跨库查询解决方案 mysql federated引擎的使用

背景

在服务高度拆分，数据库不断细化切分的情况下，我们经常有连接多台数据库查询的需求，如果不断的把数据库连接的逻辑添加在代码中，那么这种耦合会越来越严重，这会给程序的拓展和维护带来很大的麻烦。

mysql的federated引擎，可以在本地创建远程数据库的映射表，创建完后，拓扑如下：

如此，我们可以在本地构建多个远程数据库库的统一入口，这样可以极大的简化在分布式环境中，跨服务器数据库的交互查询问题。

1.开启引擎

查询数据库是否支持

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，再次查询，发现已经开启：

2.场景

数据库1：阿里云 java4all,表product_stock；

数据库2：华为云 wangtest1,表user;

user表中有一个product_stock_id。

需求：需要跨库查询。

3.创建数据库表映射

在华为云的wangtest1数据库中，创建一个阿里云的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:password@ip:port/java4all/product_stock';

这里需要注意，数据库引擎的选择，要明确指定引擎ENGINE=FEDERATED，

创建完后，会发现，在wangtest1库中，也有了product_stock表：

此时，其实在华为云的wangtest1库中，就有了阿里云的java4all库中的product_stock这张表的映射了。我们可以看到，这张表外观看起来和正常的表是一样的，但是其实华为云这边这是存储了表结构，数据还是从阿里云拉取的。

我们尝试在阿里云修改数据，在华为云这边刷新，也会看到变化。反之也是可以的。在使用层面看来，这个product_stock和本地原本就创建了的效果是一样的，各种查询都是支持的，但是不建议给映射表写的权限。

查询测试：

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.远程表的数据库据密码，不能含有@字符，因为在创建映射表时，CONNECTION='mysql://root:1xxx@1xx.xx.xx.xx:3306/java4all/product_stock'，这里用户名密码，和数据库地址之间的分隔符是@，如果你的密码含有@，会导致解析出错。

3.修改本地表结构，是不允许的，因为你这个表是映射远程表的，远程表没改，你改了，可能会映射不上一些字段。如果远程表修改了，这个表需要重新映射。所有，理论上，为了防止不必要的麻烦，本地的映射表禁止任何结构性修改，如果远程表结构修改了，本地的删掉重新映射即可。

4.删除本地映射表，对远程表无负作用。

5.本地数据库服务必须支持federated引擎，远程服务器可以不支持。

6.数据库版本需要在5.0以上。

7.federated引擎是基于表级别的，无法实现基于库级别的整体映射。

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

9.limit是个比较慢的操作，引擎会将所有满足条件的数据读取到本地，再limit处理。

10.显然，看起来，你可能会觉得，那我把各个相关微服务的表全部映射过来，那连分布式事务的问题都一并解决了，因为本地看起来就拥有所有的表，那分布式事务的各种解决方案都不需要存在了。这里，由于没有这么大规模生产压测过，不好定论，不好反驳。但是既然微服务拆分了，解耦了应用，那库显然也是解耦的，mysql只是提供了这种功能，让你在某些特殊需求场景下，来连接和简化多数据源数据的交互问题。而不是让你里用这个，将原本做好了解耦和合理拆分的东西，再重新糅合一团。

11.Pay attention to the border！

5.关于连接的问题

1.本地虚拟表与远程实体表之间是 TCP 长连接，并且是多个客户端利用的。所以不用担心因频繁建立连接带来的网络开销。

2.本虚拟表表与远程实体表之间的网络连接断开后，当对虚拟表发起查询时，它会尝试重新连接远程实体表，所以我们不用担心网络连接断开造成的永久中断问题。

3.如果长时间未对本地虚拟表作任何操作，虚拟表与实体表之间的连接将在远程主机的 wait_timeout 秒后自动断开，当对虚拟表发起查询时，连接又会重新建立。

6.性能

由于少见有大厂专门对此进行过性能测试，网上资料也比较少，目前未见到什么明显的性能短板，但没有大规模生产使用，应该还是有短板的（待我去官网翻译一波文档）。打算踩坑的可以一起组团踩坑。直接上生产的，注意风险把控。

起码是个跨服务查询，数据量大的时候，网络和传输应该是个起码的瓶颈。

原文地址:https://blog.csdn.net/weixin_39800144/article/details/88684475