0%

[转]Otter数据一致性

Otter数据一致性实现思路分析

技术选型分析

需要处理一致性的业务场景:

  • 多地修改 (双A机房)
  • 同一记录,同时变更

同一记录定义:具体到某一张表,某一条pk,某一字段

同时变更定义:A地写入的数据在B地还未可见的一段时间范围

基本思路

  • 事前控制:比如paoxs协议,在多地数据写入各自数据存储之前,就已经决定好最后保留哪条记录
  • 事后处理:指A/B两地修改的数据,已经保存到数据库之后,通过数据同步后保证两数据的一致性

事前控制

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

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

1. 先看: A地部署leader/follower集群,B地部署observer.

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

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

  • B地接收到请求,转发给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需要有一种完全可靠的数据一致性方案,这也是本文讨论的重点。

单向回环补救 (基于trusted source的改进版)

思路:最终一致性

适用场景: A地和B地数据不对等,比如A地为主,写入量比较高,B地有少量的数据写入

单向回环流程:(比如图中以HZ为trusted source站点)

  • us->hz同步的数据,会再次进入hz->us队列,形成一次单向回环
  • hz->us同步的数据,不会进入us->hz队列(回环终止,保证不进入死循环)

存在的问题:存在同步延迟时,会出现版本丢失高/数据交替性变化

  • 比如US同一条记录变更了10个版本,而且很快同步到了HZ,而HZ因为同步数据大,同步延迟,后续单向回环中将10个版本又在US进行了一次重放,导致出现数据交替
  • 比如HZ同一条记录变更了10个版本,而且很快同步到了US,而US因为同步延迟,将一个比较早的版本同步到了HZ,后续通过单向回环,将此记录重放到了US,导致之前HZ到US的10个版本丢失.

解决方案:

  • 反查数据库同步 (以数据库最新版本同步,解决交替性,比如设置一致性反查数据库延迟阀值为60秒,即当同步过程中发现数据延迟超过了60秒,就会基于PK反查一次数据库,拿到当前最新值进行同步,减少交替性的问题)
  • 字段同步 (降低冲突概率)
  • 同步效率 (同步越快越好,降低双写导致版本丢失概率,不需要构建冲突数据KV表)
  • 同步全局控制 (比如HZ->US和US->HZ一定要一起启动,一起关闭,保证不会出现一边数据一直覆盖另一边,造成比较多的版本丢失)

同步全局控制方案:(分布式Permit)

注意:A,B,C三点状态都正常才允许进行同步(解决数据单向覆盖)。 任何一边的canal不正常工作,都应该停掉整个双向同步,及时性越高越好。

时间交集补救

算法描述:

  1. 首先定义两个时间概念
  • 数据变更时间A :代表业务数据在A地数据库中产生的时间,即图中的时间A
  • 数据同步时间B:代表数据变更载入到B地数据库的时间,即图中的时间B
  1. 针对每条或者一批数据都记录变更时间A和同步时间B,同时保留历史同步过的数据记录

  2. 图中纵轴为时间轴,Aa代表从数据库A同步到数据库B的一个同步过程,Ba代表从数据库B到同步到的数据库A的一个同步过程,每个同步过程在纵轴上会有两个点,分别代表变更时间A和同步时间B.

  3. 根据同一时间的定义,在两边数据库的各自同步过程中,以数据库A为例,在数据库B的同步过程找到与Aa有时间交集的批次,比如这里就是Aa 与 (Ba , Bb , Bc)有时间交集

  4. 针对步骤4中的批次,根据同一数据的定义,在交集的每个批次中,比如首先拿Aa和Ba的历史同步数据记录,根据同一数据定义进行查找,然后再是Aa和Bb,依次类推。

  5. 针对步骤5中找到的同一数据,最后确定为需要进行单向回环的一致性算法的数据。

此方案相比于单向回环方案:减少单向回环同步的数据量,解决A和B地数据对等的case,不过目前开源版本暂未实现。

otter wiki

欢迎关注我的其它发布渠道