数据库双A同步实现方案

需求：

工作中的业务数据，目前分别存储在美国的服务器和中国的服务器(mysql)，需要把对应的表实施数据同步。

解决方案canal(源码java)

这个工具还是挺强大的，主要实现其实类似于mysql的主从同步机制，监控数据库的bin-log日志从而达到数据同步。
这里简单介绍下它可做的同步流程：

一：既然说了是监控bin-log日志而达到的同步，肯定需要mysql开启bin-log，一般如果是用阿里云服务器和别的商家其实是默认支持的，不需要调整配置。

二：搭建canal,admin为web控制面板(里面可调整配置文件),server部署。两个服务均可使用docker部署。

三：基本操作搭建完成后，可选择合适的同步中间界，目前支持的消息队列为：kafka,rocketMq，另外支持Elasticsearch, 或者直接使用tcp连接来进行消费都是可行的,我们使用的是rocketMq。因为本身使用的消息队列就是rocketMq，所以也就把他当作通道了。

四：直接就讲rocketMq了，和kafka肯定是接近一致的，（tcp消费其实就是检测从节点收到的bin-log信息）.
这里讲下他的简单过程吧，中国服务器cn，美国服务器us,首先cnnal模拟us数据库的从库，从而让us数据库以为canal这边是自己的一个节点，当每次产生bin-log，都会往从节点进行发送(主从同步机制百度一大片),当canal拿到数据后，它自己也会做偏移值记录，再把对用的log发送到rocketMq,客户端在进行消费。

五：客户端消费的时候还是比较麻烦，当时没有直接拿到sql语句，只有对应的数据和对应的操作，相当于客户端这边还写了一个封装方法来进行对log的消费，从而新增到同步的数据库当中。
目前双A数据库同步比较成熟的方案，这个canal算是扛把子了吧，阿里云好歹也是持续了10年在用（在github上自己说的）,不过这中间其实还有很多隐藏的隐患。比如：

1.阿里云的rocketMq建议默认存储三天，（这个其实可以自己也存一份数据，不过不建议）
2.canal挂了：这个好说，他自己记录了偏移值，重启后会从偏移值开始，只要自己别乱删记录，没啥问题。

2.1.消费记录失败时，rocketMq会出现异常情况.
消费情况失败会有两种处理:
处理一:返回失败，这样就会一直重复消费，一直失败，从而也会导致原本bin-log是同步的，到了消费这段就成了异步消费，成了无序的了，（之后的rocketMq记录也会消费）。
处理二:返回成功，那这个就有点猛了，失败了还返回成功，那就得自己去记录失败的值，在用一套体系来保证数据的同步。
还有一些问题就不一一列举了，虽然肯定都是有解决方案的，不过增大了程序的复杂度，加大了开发成本。这个时候就去观察有没有更好的解决方案。
后面发现了阿里封装canal，用java写了一个工具，名叫：otter
不得了，这个东西毕竟是阿里封装好的canal，还是比较成熟的，唯一的区别就是 otter智能大大减少开发成本， canal也不是麻烦，肯定关于所有的风险处理都需要有保障，因为数据同步的准确性还是挺重要的，不过个人觉得otter过于智能如果中间有什么想要做特别处理的话，肯定直接用canal会更方便。
这个时候CTO基于开发成本以及稳定性的考虑，选择了otter，果不其然之前花了两三天把canal弄好，又需要推翻了，不过不要紧安慰自己得有一套，起码熟悉了cannal的机制了。

otter：

在讲这个之前，再说一下双A数据库Id的解决方案，其实就是用的分布式数据库的解决方案，因为有并发的缘故，我们不能让Id重复，这个时候使用了redis做一个id存储，选择cn数据库存储奇数id，
us数据库存储偶数id，如果中途还有别的国家在部署服务器，那就按照余数来进行划分id.
回到otter，otter使用了有。zk进行负载， node来进行操作包括管理canal等。同步可选择 mysql oracle。
好，下面就是一系列配置，部署好之后，大概最后的情况就是美国服务器部署了两个 node ，中国服务器部署了两个node，每个node是数据同步的一个方向，这个时候就成功的把生产测试数据库双向同步完成了，当然这中间有些地方需要配置，比如同步的库名保持一致，这个在同步字段时是需要的，其他的小细节都无伤大雅，github里面的错一般都有。

初次配置的话会有很多的配置细节需要注意，是会有些头疼，个人感觉网上在这方面的资料说明是比较散的，如果有啥疑问，可以评论滴滴。
后面公司需要把mysql数据同步到Elasticsearch，otter不支持，准备继续使用canal了。