MySQL 数据出海之数据同步方案

优质博文IT-BLOG-CN数据库出海流程【1】业务出海1数据库出海2应用出海3流量分发【2】数据库出海涉及业务方、信安、DBA和框架组。数据库出海流量在国内 -- 应用出海流量在国内 -- 公有云灰度流量[GateWay] -- 完成灰度流量切分完成注意事项【1】若出海的数据分散在多个库先汇总到一个集群统一出海【2】双向复制时需要做好流量切分避免数据复制出现冲突【3】保留流量切分到上海的能力防止复制中断影响业务【4】如果相同的数据存在多个更新场景在并发的情况下还容易产生数据冲突的问题也需要通过单元化部署避免数据同步方案方案一手工触发数据迁移将海外数据迁移到AWS的DB。然后将海外流量从上海机房切换到AWS;备注 灰度过程中一般会分为多个批次进行每个批次对应的数据和流量都是重复上述操作优点流程简单容易操作因为操作失误而导致出错的几率极低缺点1. 增量数据可能丢失数据迁移的操作是需要一定的时间才能完成的而在这一段时间内可能有用户写入新数据或者修改数据若修改时间点正好是这条数据已经完成迁移但又在流量切换之前导致AWS上的数据不是最新数据即增量数据在AWS上丢失了。问题场景的时序如下【1】用户A下单订单ID10001订单状态为S此时流量和数据都只是在上海机房;【2】执行数据迁移流量仍然指向上海机房迁移完成后上海机房和AWS的DB都有ID10001的订单且订单状态都是S;【3】用户进行退票操作由于流量指向上海机房所以操作后上海机房的DB中订单状态被值为C而AWS上订单状态还是S;【4】进行流量切换将用户A的流量切换到AWS双边的数据各自保持不变仍然不一致;【5】用户进行查询操作由于流量指向AWS读取AWS的DB的数据看到订单状态S。退票操作差生的S--C的增量变更丢失了;缺点2. 数据迁移的分批策略需要与流量切换的分批逻辑保持一致分批多次切换的过程中每次切换都涉及流量切换和数据迁移二者的分批逻辑必须保持严格一致。再加上我们的数据多样化会有多种切换维度和策略会导致数据迁移工具的实现难度和工作量很大。缺点3. 无法回切流量到上海机房数据单向同步到AWS即灰度过程中AWS上会有全量的数据但上海机房的AWS数据会随着切换比例逐渐减少上海机房将无法处理历史数据的变更也就无法支持全部的AWS流量。当云上的应用出现流程或者环境问题时只能是尽量快速解决AWS上的问题而不能将AWS流量回切到上海。由于上云项目涉及的应用和开发组非常多大家对公有云的运维经验较少上线初期出现问题的几率较高解决问题的速度也可能比较慢无法将流量回切上海带来的风险和影响较大。改进方案一实时同步数据到AWS灰度过程中启用数据同步将上海的AWS数据全部同步到AWS机房时间跨度是从灰度开始一直持续到灰度结束。由于增量数据会持续的同步到AWSAWS上始终是全量的最新数据避免缺点1的问题数据同步是同步所有的海外数据不依赖与流量切换的分批维度可以直接使用公司通用的数据同步工具避免缺点2的问题。缺点由于数据同步只是单向的从上海到AWS仍然无法保证上海是全量的最新数据缺点3的问题仍然存在即无法回切流量到上海机房。改进方案二双向实时数据同步灰度过程中同时启用两个方向的数据同步不仅将海外数据同步到AWS也将AWS的海外数据全部同步到上海机房时间跨度是从灰度开始一直持续到灰度结束。这样上海机房和AWS机房都有全量的海外数据可以随时将海外流量切换到AWS也可以随时回切流量到上海避免缺点3缺点 双向数据同步可能产生数据冲突必须对数据写入逻辑进行严格控制避免冲突。海外订单号数据库独立部署目的海外订单号中存放Location信息通过订单号就能确定是那个Region的订单方便保障订单的处理。产生订单号的数据库在海外独立部署和国内订单号数据库不关联。订单号分配逻辑保留海外的可扩展性。订单号分配基本原则【1】全局唯一性不能出现重复订单号【2】趋势递增有序的主键保证写入性能【3】单调递增下一个ID一定大于上一个ID【4】信息安全避免让竞争对手获取单量数据库多IDC扩展性引入RegionCode插入用户数据时增加记录机房标识RegionCode。根据RegionCode确定数据所在Region使得常用的数据查询或业务处理操作可以在单个节点上执行以达到数据单元化处理和数据合规策略动态调整的效果从而避免跨节点带来额外性能消耗和数据跨境合规问题。