异地多活数据同步平台
摘自《大型企业微服务架构实践与运营》 薛浩 编著
异地多活数据同步平台
1. 异地多活架构
接入层应用可通过同步调用或异步消息实现相互的调用。通过相关的服务注册和发现机制保障寻址、路由、熔断、切换等。
在数据库层面，通过准实时同步的方式实现数据中心间数据的双向同步。以My SQL数据库为例，其同步示意如图：
中心间采用解析My SQL二进制日志（binlog）实现增量准实时双向同步数据，通过数据稽核检验保障数据最终一致。在灾难发生情况下，业务不中断，可人工或自动进入数据中心切换。
考虑到数据同步的效率，中心间的数据同步需要采取一定的策略。对于共性业务，数据中心之间只对系统静态参数和核心动态业务数据进行增量备份，其他业务数据不做备份；对于个性业务，只对个性业务的静态及配置数据进行两中心同步。
实现异地多活的关键在于数据中心间的数据同步，而数据同步的关键是要保证中心间的数据一致性和数据同步的低延迟。数据同步平台很好地解决了实现异地多活产生的数据同步问题。
2. 数据同步平台架构设计
数据同步平台主要由管理平台、切换感知、传输引擎、binlog解析器、数据稽核模块组成。binlog解析器通过订阅My SQL的binlog实现准实时跨中心数据同步，从而达到中心间My SQL数据的一致性。数据同步平台高度自治，只与My SQL交互。对中心间需要同步数据的My SQL建立传输管道，每个中心下包含需要同步的My SQL主—从数据库地址。
管理平台是My SQL数据同步平台的管理门户，主要提供配置和监控功能。配置功能包括传输管道、传输引擎、数据稽核、切换感知配置以及binlog解析配置；监控功能包括切换感知、传输引擎、异常、binlog解析以及数据稽核过程。
切换感知主要解决中心内My SQL数据库主—从切换后，通知binlog解析器与传输引擎切换到新的My SQL主库上进行解析binlog与回复binlog。
传输引擎通过内嵌解析器方式对接解析器，获取数据库增量日志数据，将增量数据传输到异地机房并加载到相应的My SQL主库中。
binlog解析器采用开源dbsync进行定制开发，以达到数据同步的要求。
数据稽核是在发生异常情况下，中心间数据同步过程中出现数据不一致问题。数据稽核是保障中心间数据同步的最终一致性的主要手段，分为冲突校验、定时全量稽核，根据稽核的结果进行手动、自动修复数据。
管理平台对切换感知、binlog解析器、传输引擎、数据稽核进行管理配置、监控。数据同步平台通过切换感知及时发现中心内My SQL的主—从切换，并通知传输引擎与binlog解析器切换到新的Master上进行数据同步。
2.1 数据同步原理分析
数据同步的前提是配置好需要实现同步的源数据库/表和目标数据库/表，在管理节点（Manager）配置传输管道等相关信息。数据同步平台各功能模块之间的关系如图所示:
图6-14 数据同步流程
流程简述如下：
- ①数据库数据发生变更后，由数据库将binlog发送至binlog解析模块；
- ②解析器对接收到的binlog进行协议解析，补充一些特定信息，如字段名字、字段类型、主键信息、Unsigned类型处理；
- ③将解析后的数据传递给事件队列模块进行数据存储，该操作是一个阻塞操作，直到存储成功；
- ④存储成功后，定时记录Binary log的位置；
- ⑤进入数据队列后，由数据队列实现数据过滤、路由分发等功能；
- ⑥数据通过Ring Buffer实现内存存储，防止缓存数据过大导致Jvm内存溢出；
- ⑦传输引擎从ZooKeeper获取同步任务，并接入binlog解析模块开始同步数据；
- ⑧传输引擎主要实现4个阶段的操作，分别是数据接入（Select）、数据提取（Extract）、数据转换（Transform）、数据加载（Load）；
- ⑨在目标库实现数据入库。
其中，切换感知模块用于监控数据库主—从切换，并通知ZooKeeper以及binlog解析模块对Master实现切换。数据稽核模块在业务负载较低的时段对源库和目标库进行数据校验，用于保证数据的最终一致。
2.2.切换感知
切换感知主要解决中心内My SQL数据库主—从切换后通知binlog解析器与传输引擎切换到新的My SQL主库上进行解析binlog与回复binlog。其技术方案如图6-15 所示。
图6-15 切换感知架构图
切换探测集群通过对My SQL执行探测命令确认主—从切换并找出新的主库，并通过ZooKeeper通知binlog解析器和传输引擎组件。为了实现切换感知的高可用性，切换感知也实现了集群部署。切换感知通过管理平台配置传输管道和探测频率，即可定时发起对传输管道下My SQL集群主—从切换的探测。
切换感知的探测流程如图所示:
为了保障切换感知结果的正确性，切换感知采用双向确认的方式，即当发现My SQL集群有主—从切换，则切换感知会分别向新、老Master发起切换探测，只有结果一致，才会确认发生了主—从切换。具体实现流程如下：
- ①切换感知定时在My SQL集群中实例执行show slave status命令；
- ②获取每个实例的关键信息，对关键信息进行前后两次对比，检查前后差异，根据差异发现Master差异；
- ③查询老Master读写属性，如果老Master写未关闭，不做切换通知，如果关闭，则进入第④步；
- ④查询新Master读写属性，如果新Master写打开，通知切换；如果关闭每隔3s重新读取，新Master写未打开，进入第⑤步；
- ⑤发起My SQL集群内写实例（写属性打开的实例）探查，如果发现写实例，通过命令show slave status分析是否有其他实例从该写实例同步数据，如果有，确认该写实例为新Master，记录日志发起切换通知；如果没有，发起告警，并停止My SQL集群中心间数据同步。
由于切换感知的每次探测中间是有时间间隔的，因此，不可避免地会出现在间隔期发生主—从切换的情况。如果在切换感知探测之后发生了主—从切换，传输引擎在加载数据时会遇到只读异常（因为原主库已经切换成为只读备库），这时切换感知会立即发起主—从探测，等待探测结束后，新Master重新加载数据。
当binlog解析得到My SQL Master切换消息后，会判断当前Master是否同步完成，等待同步完成，再切换到新Master进行binlog解析。切换到新的主库中需要根据binlog的GTID进行数据排重。
3.binlog解析
My SQL主备数据复制实现原理如图6-17所示。
图6-17 MySQL主备数据复制实现原理
从上层来看，复制分成3步：
①Master将改变记录到二进制日志（binlog）中（这些记录叫作二进制日志事件，可以通过show binlog events命令进行查看）；
②Slave将Master的binlog events拷贝到它的中继日志（Relay log）；
③Slave重做中继日志中的事件，将改变反映它自己的数据。
关于binlog的解析原理，感兴趣的读者可参考阿里巴巴旗下的一款开源项目Canal，这里不再赘述。
4.传输引擎
通过对接解析器，获取数据库增量日志数据，将增量数据传输到异地机房并加载到相应的My SQL主库中。
传输引擎架构如图6-18所示。Manager运行时推送同步配置到节点；节点将同步状态反馈到Manager上；基于ZooKeeper解决分布式状态下的调度，允许多节点之间协同工作。
传输引擎采用S/E/T/L阶段模型，即数据接入、数据提取、数据转换和数据加载，如图6-19所示。为了更好地支持系统的扩展性和灵活性，将整个同步流程抽象为Select、Extract、Transform、Load 4个阶段。
Select阶段：解决数据来源的差异性，如接入binlog解析获取增量数据，也可以通过接入其他系统获取其他数据等。
图6-18 传输引擎架构图
图6-19 S/E/T/L阶段模型
Extract、Transform、Load阶段：类似于传统的BI的ETL模型，具体可为数据接入、数据转换、数据载入等操作。
传输引擎的数据同步工作原理如图6-20所示。
图6-20 传输引擎工作原理图
工作原理描述如下：
- ①由配置人员在管理节点配置传输管道的相关信息，同步启动；
- ②由管理节点推送传输管道配置信息到传输引擎以及ZooKeeper中，并在ZooKeeper中写入同步任务，需要跨中心同步配置信息；
- ③开启binlog解析器，同步数据；
- ④由传输引擎获取同步任务，并接入binlong解析器开始同步；
- ⑤传输引擎反馈同步状态给管理节点。
为了提升数据同步效率，数据入库摒弃原有事务顺序，采用最终一致性提升入库性能。入库算法采取了按PK Hash并行载入+batch合并的优化。打散原始数据库事务，预处理数据，合并Insert/Update/Delete数据，然后按照Table + PK进行并行（相同Table的数据，先执行Delete，后执行Insert/Update，串行保证，解决唯一性约束数据变更问题），相同Table的SQL会进行Batch合并处理。
- 数据合并处理：
Insert + Update→Insert；
Insert + Delete→Delete；
Update + Update→Update；
Update + Delete→Delete。
5.数据稽核
主—从数据同步是一个复杂的过程，在中心间数据同步过程中难以避免会产生数据不一致的问题。数据稽核是保障中心间数据同步的最终一致性的主要手段，分为实时增量校验和定时全量校验，根据校验的结果进行手动或自动修复数据。
在数据同步过程中，导致数据不一致常见的有以下两种情况。
第一种情况是同一条数据“同时”修改，造成这种情况有以下两种原因：
- ①上层应用系统通过DNS做流量切换，DNS在收敛时间内可能导致同一条数据同时修改；
- ②上层应用没有控制，导致公共数据同时修改。
第二种情况是在数据同步过程中可能发生异常导致数据丢失，如：
- ①MySQL不可用，包括My SQL所在主机宕机、MySQL宕机等丢失未Dump的binlog；
- ②中心间网络不可用导致binlog未及时存储。
在数据一致性保障机制方面，应根据不一致原因采用不同的策略。
对于第一种同一条数据“同时”修改的情况，由于在双中心的背景下，不允许同一条数据“同时”修改，所以应采用实时校验的方式及时发现不一致的数据并告警。
“同时”是一个时间段，表示A中心修改数据开始直到B中心可见为止。“同时”定义示意如图6-21所示。
图6-21 “同时”定义示意图
实时校验主要解决发现同一条数据“同时”在两个中心修改的问题。通过时间交集算法发现可能“同时”修改的数据，对此数据进行二次校验确认是否异常，以及发起告警、申请手工修复。实时校验原理如图6-22所示。
实时校验过程描述如下。
- ①binlog解析完数据后，根据PK归属原则、分析出数据流向是否异常，例如，中心2的数据流向为从右到左，如果发现中心2的数据出现从左向右流动，说明上层系统发生中心间切换，此时发起数据实时校验。将数据存入Redis中，使用表名+PK作为Key，Value中包含数据产生时间（Ta），失效时间设置为两倍同步时间+消息处理时间。
- ②数据Load完成后，将数据发送给Kafka，数据中包含数据产生时间（Tb1）以及当前时间（Tb2）。
- ③实时校验节点获取Kafka消息。
- ④实时校验节点以表名+PK为Key，从Redis中获取数据，如果数据存在，从数据中读取时间（Ta）；如果时间（Ta）正好在Kafka消息中的两个数据Tb1与Tb2之间，说明数据修改发生冲突。
- ⑤两中心数据发起核对，如果不一致，反馈差异到管理节点，发出告警、申请人工修复。
对于第二种数据丢失的情况，数据丢失修复应采用定时全表数据核对，并根据修复策略进行自动或者手工修复，定时全量校验原理如图6-23所示。
图6-23 定时全量校验原理图
定时全量校验过程描述如下。
- ①该过程由管理节点发起任务，并从两个中心各选一个校验工作节点，并选出其中一个作为主节点。
- ②主节点按块（Chunk）进行CRC32计算，具体计算如：通过分页SQL语句查询出Chunk（例如，Chunk设置为1000）条数据，并按照PK排序，进行数据CRC32计算，并取出边界PK。可以在数据库中计算，也可以批量获取后在校验节点中进行计算。
- ③把SQL语句以及边界PK发给从校验节点，主节点发起下一块CRC计算，等待从节点返回结果。
- ④从节点发起SQL执行，获取CRC校验，并获取边界PK。
- ⑤从节点检查是否有差异，返回结果给主节点。
- ⑥主节点根据返回结果判断，如果CRC32数值不一致，发起该块数据逐条计算CRC32值，找出不一致的数据并记录，等待两倍数据同步时间，再计算该条数据在两个库中的CRC32值，比较是否一致，如果不一致，再与上次计算的值分别计算；如果还不一致说明数据持续有修改，把该条数据反馈给管理节点，发出告警。如果与上次计算CRC32值一致，启动修复机制。
差异告警是数据稽核发现有数据不一致，异步往管理平台发送告警数据，包括差异类型、差异数据点等。差异类型有中心1缺失数据、中心2缺失数据、中心1和中心2字段数据差异。
数据修复针对差异类型不同提供不同的修复策略。如中心1数据缺失或者中心2数据缺失需要根据数据归属以及binlog解析日志进行删除或者插入修复动作；中心1和中心2字段差异，则需要根据数据归属以及修改数据进行修复。修复数据前会记录修复前的数据以及修复时间等信息。
6.同步表限制条件
在没有分布式锁限制情况下，My SQL主—主双活模式不能百分之百保障数据一致，且要满足数据同步时延、吞吐量要求，需要对同步的数据库提以下限制条件（见表6-7），但不仅仅局限于以下条件。