【Mysql数据库之otter 介绍】

otter 基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库. 一个分布式数据库同步系统

 

名称：otter

译意： 水獭，数据搬运工

语言： 纯java开发

定位： 基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库. 一个分布式数据库同步系统

 

 

原理描述：

1. 基于Canal开源产品，获取数据库增量日志数据。 什么是Canal, 请点击

2. 典型管理系统架构，manager(web管理)+node(工作节点)

    a. manager运行时推送同步配置到node节点

    b. node节点将同步状态反馈到manager上

3. 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作.

 

什么是canal?

otter之前开源的一个子项目

 

 

 

事前控制：比如paoxs协议，在多地数据写入各自数据存储之前，就已经决定好最后保留哪条记录

事后处理：指A/B两地修改的数据，已经保存到数据库之后，通过数据同步后保证两数据的一致性

事前控制

paxos协议，相信大家研究的人也比较多，但是它有一些局限性，就拿zookeeper来说，它使用了paxos的一个变种，但基本原理还是相似的。

我们拿zookeeper的几种部署模式来看：

1. 先看： A地部署leader/follower集群，B地部署observer.

此时A地收到数据后，需要的网络操作基本为同机房的leader/follower的paxos协议，耗时基本可控

此时B地收到数据后，需要的网络操作为：

B地接收到请求，转发给A地，一次机房网络

A地接收到请求，由leader转发给follower进行投票决策，同机房网络

A地leader将投票的结构，反馈给B地，一次机房网络.

这样一来，也就是说，事务时间 = 一次异地机房RTT + 同机房paxos算法耗时. 比如中美网络延迟200ms，那事务时间基本就是200ms+ 。 但此时，B地机房基本是一个只读镜像，读数据也有延迟，其系统写扩展性全在A机房，某一天当A机房不够用时，A机房进行拆分，就会遇到下一个问题。

 

2. 再看：A地和B地组成leader/follower

此时A第收到数据后，需要的网络操作为：(假如A不是leader，B是leader)

首先需要发送数据到B，一次机房网络

B收到A的提议数据后，发起一个投票到A，一次机房网络

A收到提议后，返回一个投票结果到B，一次机房网络

B收到大部分投票结果，做出决定之后，将结果反馈给A，一次网络交互.

这种理想无冲突的情况，总共会有2次RTT，如果优化A发起的提议自己默认投票，不返回给A进行投票，可以优化为1次RTT. 针对中美网络延迟200ms，那事务时间基本是200ms+. 如果A地和B地同时写入，那事务时间可能会翻倍。

总结：如果你能接受事务时间的影响(比如你A地和B地的网络延迟只有10ms)，那是可以考虑选择paxos协议. 但目前otter所要解决的需求为中美200ms的RTT，暂时无法接收paxos协议来解决一致性问题.

 

事后处理

针对事后处理，不管哪种方案，一定会是一个最终一致性，因为在你做处理前，A地和B地的数据内容已经不一致了，你不论选择任何一个版本，对另一边来说都是一个数据版本丢失，最终一致性。

针对数据最终一致性处理，goldengate文档中提到了几种case :

trusted source. 信任站点，数据出现冲突时，永远以某一边为准覆盖另一边

timestamp，基于数据的修改时间戳，修改时间新的覆盖旧的数据

数据类型merge， 比如针对库存信息，A地库存减一，B地库存减二，两边同步之后A地和B地的数据应该是减三，合并两者减一和减二的操作

针对trusted source/timestamp模型，一定需要建立一个冲突数据kv表，(比如trusted source场景，如果B地修改了记录，而A地没修改此记录，那B地可以覆盖A地，即使A地是trusted source) ，对应冲突数据KV表的插入和删除，如果插入和删除不及时，就会有各种各样的误判，导致数据不一致。

举个插入不及时的case: 比如A地和B地进行双向同步，同时修改了同一记录，但A地的binlog解析器因为异常挂起了，导致构建冲突数据KV表数据延迟了，而此时B地的数据就会认为无冲突，直接覆盖了A，即使A地是trusted source，然后A地数据解析恢复后，同步到B地时，因为A是trusted source，就会覆盖B地的数据，最后就是A和B两地各位两边之前的版本，导致数据不一致。

 

因为goldengate外部文档针对双A机房同步，数据一致性处理描述的比较少，我只能推测到这，基本结论是风险太大，所以otter需要有一种完全可靠的数据一致性方案。