网易|网易分布式数据库多活架构的演进与实践( 四 ) |架构|演进|

冲突数据校验：产生了数据冲突的双写数据才进行校验。

风险数据校验：存在版本回退这样的特殊数据才进行数据校验。

数据校验的实现比较简单，将需要校验的数据放入队列中，校验线程不断地去取需要校验的数据，并比对源和目标的数据是否一致即可。

本文插图

十、总结
网易数据库多活经历了机房内多活、跨机房多活和跨机房单元化多活三个阶段。在数据库多活上积累了一些经验，之后也还有更长的路要走。希望这些经验能够给各位一些启发，也期待和大家在数据库多活的话题上有更多的交流。
&gt&gt&gt&gt
Q&ampA
Q1：数据变化是通过什么工具推送到Kafka？
A：通过网易内部自研的数据传输工具NDC完成，它的工作原理与开源的Canal类似，模拟自己为一个MySQL从节点，与主节点建立复制协议获取binlog ，解析后得到行变更数据然后推送入Kafka 。
Q2：请问网易的单元化是分了两个单元嘛？
A：是的，现在是在杭州的义桥与东冠机房做同城双单元，机房延迟大概在2ms-3ms之间。
Q3：什么时候用中间件复制，什么时候用数据库自带复制？
A：原生复制是MySQL自身提供的复制能力，好处是不需要额外的组件部署，也很稳定。但是当需要进行跨大版本复制，原生复制的性能不满足需求，或者想自定义一些复制特性的时候就可以使用中间件来完成复制工作了，中间件复制另外的一个优点是可以自定义很多监控指标，实时监控复制的状态。
Q4：数据同步异常后校验机制落后于业务怎么办？

A：我猜问题是想问在校验机制发现数据不一致问题之前，错误数据已经暴露给业务方时如何处理。由于校验并发现问题距离问题发生肯定是有延后的，所以这个问题没法避免，核心还是在发现问题后能够快速定位这些不一致数据对业务产生的影响，并根据实际情况来处理。
Q5：单元化具有扩展性，怎么理解？
A：单元化的方案对单元的个数理论是没有限制的，在业务规模上来后发展到几十个、上百个单元都是可行的。
Q6：刚刚物理时间不一致，数据回退怎么解决的？
A：由于不同机房物理时间基准存在偏差，可能在数据更新时发生更新后的数据时间戳低于更新前的时间戳，光从时间戳上看是发生了版本（物理时间即为数据的版本）回退，此时我们是通过将更新后的时间戳提升到与更新前的时间戳一样的大小，来保证此条数据能正确同步到对端单元。
Q7：说数据异常了，而业务在校验发现前已经用了脏数据怎么办？
A：单元化方案里的双向同步策略只保证最终一致性，如果中间数据出现短暂的异常读，业务上是能容忍的，这里牵扯出一个问题，什么样的业务模块适合做单元化，我们这里一般认为更新不是特别频繁，且业务上自己有比较好的分区逻辑的业务适合做单元化。

Q8：流量切换的时候，怎么保证业务正确性？
A：在计划内切换的场景下，上层流量控制可以保证在底层同步组件都完成数据同步后再将流量切过来，这个过程一般在1分钟以内，在计划外的切换过程中，无法做这个保证，所以可能产生两边数据不一致，这个需要在事后找出不一致的数据，并按照业务自身特点进行修复。
Q9：支付类数据，如何保证强一致的？
A：支付类的数据为了保证强一致性，一般使用MGR这种类Paxos协议来完成数据同步。
Q10：这种数据的同步是解析的binlog ，然后写入NDC同步到异地机房吗？
A：是的，具体可以参考Q1的回答。
Q11：系统重构、数据库表设计及结构都不一致，一般迁移用什么ETL工具？