Q&A
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工具？
A：网易自研的NDC就能满足这类需求，开源的话Canal提供了比较完善的binlog复制解析能力，但是一些具体的复杂需求可能需要自己实现。
Q12：网易少量的Oracle都用在哪些业务系统上？如何做多机房双活的？
A：Oracle现在基本就只有网易支付在用了，据我所知他们并没有在Oracle上做多机房双活的计划。
Q13：NDC支持异构数据库同步吗，SQL Server Oracle MySQL？
A：支持，现在支持的系统暂时只包括Oracle和MySQL，主要还是网易内部没有使用SQL Server。
Q14：Redis，MQ复制用什么中间件？
A：Redis据我所知是使用的Redis Cluster方案，MQ的复制是业务自研的一个同步工具。
Q15：MGR怎么处理DDL？
A：MGR对于DDL的复制和对于普通事务的复制没有太大区别，不过如果是大表的阻塞性DDL，由于执行时间过长，可能造成较大的复制延迟，网易内部对于大表的DDL一般是用PT-OSC这样的在线修改表结构工具完成。
Q16：一个单元就是一个闭环的机房吗？
A：一般是的，单元化方案里一般要求流量尽量在单元内闭环。
Q17：一个交易，做到一半，挂了，流量切换后，是把交易重新做吗？之前做的怎么处理？
A：交易一般具有事务性，所以做到一半挂了一般理解为这个事务没有提交，切换后整个过程需要重做。
Q18：如果解决分库分表后，数据一致性的问题？本来应该放在一个事务的两个SQL，分库分表后写往两个实例？有哪些方法可以解决，除了分布式事务，性能太低？
A：分布式数据库中的事务基本都是按分布式事务的方式解决的，比较经典的是两阶段提交，如果觉得两阶段提交效率太低，可以业务层使用基于MQ的柔性事务方案。
Q19：版本提升的依据是什么呢？怎么判断是不是时间戳延迟引起的？
A：版本回退的判断即是通过binlog中的时间戳列的数据得到的，所以依据就是binlog中的数据。
Q20：MGR能用在异地多活场景吗？延时太大吧？对网络有哪些要求？
A：可以用在同城单元化的方案里，同城的延迟情况对性能的影响较为可控，同城延迟一般在3ms以下。
Q21：Canal+RocketMQ可以用在异地复制吗？
A：可以。
Q22：银行级的场景下使用哪种方案做多活好啊？
A：银行对数据库一致性要求比较高，除了一些强一致的商业方案外，MySQL的MGR是一个不错的选择。
Q23：流量切换之前，做个一个操作。切换后，发现数据没同步过来，又做了，那不是做了两次吗？
A：答案参考问题8，计划内和计划外可能要分开讨论。
Q24：MGR 和 RAC有比较过吗 同城双活部署的话 MGR是否可以达到RAC的同步能力？
A：MGR本质上还是日志的同步，和RAC存储共享的思路是完全不一样的，性能上MGR也肯定是不如RAC的，但是好像MGR部署门槛低。
Q25：人工做DDL，那人比数据同步慢怎么办？数据过来了，但是表还没改过来，就出错了。
A：流程上一定是DDL在所有单元都执行完成后再开放给业务使用。
文章来源：https://dbaplus.cn/news-159-3289-1.htm
