DRC介绍
饿了么的 Data Replicate Center(DRC)项目用于数据双向复制和数据订阅,使用场景如下图:
要点说明:
-
跨机房的 Mysql 数据复制完全通过 DRC 来完成
-
还有很多业务团队通过 DRC 来实现数据订阅
目前饿了么100%的跨机房数据复制,90%的数据订阅都通过DRC完成,每天有大量的数据流经DRC。复制延迟保持在1s以下,从来没有发生过数据丢失和错乱的情况。
DRC的设计目标包括:
-
实时双向数据复制,延时 < 1s ,并能够解决双向修改时的数据冲突
-
数据变更订阅,能够在DB数据发生变化时通知到相关订阅方
-
高度可靠和保持顺序,不能丢失数据,也不能因为错乱执行顺序导致数据错误
我们最终达到了这3个目标,下面围绕着如何设计以满足以上目标介绍一下。
DRC的总体设计
DRC采用了多组件的集群化设计,整体结构如下图:
要点说明:
-
DRC有两个核心服务,Replicator 和 Apply,他们以集群化的方式部署,一个负责从源头数据库拉取变更,一个负责应用变更到目标数据库。
-
Master Replicator目前实现了 Mysql Binary Log Dump 协议,从Source Mysql 中取得 DataChangeEvent。
-
对于任何唯一的数据源,数据修改事件(DataChangeEvent)需要能够映射为唯一的单调递增的SCN(System Change Number),如果不能执行这样的映射,则DRC的一致性就不能得到保证。
-
Replicator接收到 DataChangeEvent 数据后使用一个Heap外的环状内存结构(MMAP)保存,减少GC负荷,为了保证低延迟的复制,不写入本地文件。
-
Replicator Slave是一种稍微特殊的 Replicator,从 Master Replicator 拉取 DataChangeEvent,并保存到本地EventBuffer中。
-
Replicator中保存当前 SCN Number,有一个 Master 和任意多个 Slave ,当 Masters失效后,Slave Rep