异地多活数据流基础设施DRC --双11支持571亿交易额背后的武器

延瑛 AIS 技术平台开发 数据库专家

本文将简要介绍我在QCON上做的DRC在异地双活的场景设计和应用分享,另外,我将介绍一下DRC在阿里云的使用场景。

 

DRC(Data Replication Center)是阿里巴巴技术保障部数据库团队自主研发的、数据同步和数据分发的实时数据流服务。这个数据服务在阿里巴巴里已经上线了几年,2014年双十一成功支撑了571亿交易异地双活的异地秒级数据同步。

 

DRC支持读取集团MySQLRDSOceanbaseHBaseOracle等多种不同的数据源的实时增量数据,支持写入数据库、MetaqODPS等多种存储媒介。另外,在RDS官网提供外部用户迁移上云服务,目前可以支持RDS跨域同步,RDS实时binlog订阅,七网隔离数据订阅等等。

 

首先简单介绍一下,DRC是什么。

 1.png

 

DRC的架构图:

2.png

 

淘宝新一代架构 – 异地多活,实现了一种数据中心热拔插的方式来应对业务峰值,能实现流量实时切换,数据实时恢复。

 

3.png

 

淘宝异地双活的实现简要图。

4.png

 

异地多活在数据方面的挑战是非常大的。双十一期间,交易会激增,所以交易链路做了单元化。交易链路的数据分为三个维度,买家,卖家,商品。买家之间通常没有太多交叉,天然的适应这种隔离,而且买家对延迟的敏感度非常高,所以按照买家维度切分,在单元内封闭,而卖家和商品都是在中心写入。

 

数据方面的两个核心要求是:1)一致性,要求卖家和商品一致,单元和中心一致,也就是数据同步不能丢数据,不能错数据,还要保证事务;2)实时性,需要做到秒级别的延迟。

 

双单元的同步架构有两种,一种是读写分离的方式,中心写,单元读。单元需要的数据如果没有从中心及时同步过来,或者同步错了,那有问题这段时间的交易会全部收到影响。这里的核心是,保证秒级延迟,同时,保证一致性。

 

 

第二种同步架构是单元封闭的方式。中心和单元各有写入,我们通过冗余,使得中心和单元随时可以各自接管。

 

 

这里的关键是:

-          避免循环复制:通过在DB透传打标事务的方式实现。

-          限流:峰值的压力,我们单元化本来就选取了流量激增的业务,两边都实时同步100%全量数据,峰值对每个系统的压力有增无减。DRCstorecongo都可以根据TPS或者流量限流。限速算法的核心思想分为批量采样,奖惩时间,平滑变速。

 

异地多活中DRC的核心能力就是在低延迟,一致性和高可用。

 

 

 

一致性:

-          数据有序:抓取的增量是流式的,通过pipeline实现保证数据的有序性。

-          数据不丢:通过二分查找的方法定位时间戳的最早日志,另外,也检查了传输的完整性。

-          数据不错:这里面需要解决的问题非常多,例如: binlogmeta不完整的,通过本地回放机制保证解析正确;多重存储校验机制确保数据正确;通过自适应字符集的方法处理不同字符集的正确性。

-          事务一致:在DRC congo模块实现的一种基于事务冲突检查方法,通过事务间的有向图实现事务并发逻辑。

 

 

单元化对DRC的要求是跨单元的延迟在1秒以内,否则,可能会影响用户体验,双十一峰值的用户量非常大,一旦延迟用户有感知,可能会有带来很多投诉。通过很多方面来实现这个稳定的秒级延迟:

-          最优部署:跟DBA同学搭建线上最小单元化测试环境,找到性能最优的部署方式。

-          数据传输:针对网络稳定性,DRC有一些不同的策略。流式传输的实时性最好;中美同步这种场景,丢包率高,网络延迟较大,需要多连接复用和压缩;对于下游处理速度有限的,下游可使用批量发送;另外,DRC正在优化传输消息协议。

-          数据存储:DRC store有三层存储机制,缓存,本地,分布式。本地存储DRC queue可以支持读写50w qps。对于实时数据,基本都在缓存中,读效率高;对于部分有延迟(比如批量订正),或者需要读历史的场景,做了预读等IO优化;对于只需要订阅部分库表的,做了索引优化。为了提高容灾能力,历史数据将存到分布式存储,如果一旦任务异常,只需要恢复部分实时数据。为了提高高可用性,备store可以减缓下游压力,也可以支持跨地域容灾。

-          并发复制:写入数据库将并发,同时,在热点的问题上,我们还要做到尽可能热点串行,非热点能并发。

-          数据稳定性:热点数据,缓存,并发解析等

-          

 

-          数据源和目的端如果发生主备切换,需要立刻感知,并且找到正确的切换位点重拉,保证不丢数据。

-          当任务挂了,我们能自动重启任务,当机器挂了,能漂移到其他机器上。

-          数据包括两个部分,meta和数据,他们都有容灾机制。

-          核心业务和非核心业务需要隔离,核心业务在双十一的峰值压力会很大,而过了双十一又恢复平时的水位,再散列任务,提到机器利用率。

-          如果有非常慢的下游,下游可能会对顺序写有影响,DRC也有备store,将部分延迟较大或者影响较大的下游隔离,扩展store的能力。

-          监控是个非常重要的部分,需要产品和运维配合,产品上需要有心跳,打点,运维上需要确保延迟告警。

 

2014年双十一,我们处理了2000个实例的增量数据,峰值每秒处理了30GB的数据,有17000多下游做实时订阅。除了交易峰值限流,核心库同步均无延迟。

11.png

 

12.png

 

在小微里,DRC支持OB 1.0的跨域数据同步。

 

13.png

 

在集团,DRC支持不同的下游消费订阅实时增量数据。

 

14.png

 

在云上,DRC已经提供了一年半的迁移上云的服务,每周有300+RDS 实例使用这个服务,全量+增量,应用可以无缝切换。数据库团队提供了一个升级服务,DTS,已经在云上服务一个月。

 

DRC正在实现为更多RDS用户提供便捷的服务:

-          RDS跨域同步:RDS replication本身不支持跨域,DRC通过异步复制,对RDS无入侵。

15.png

-          RDS binlog服务:目前已支持RDSDRDS。可以通过单机版集群版的客户端订阅新增数据,就像水龙头一样。目前我们已经支持的内部客户包括open searchCDP,精卫,网聚宝等数据搜索服务。

 blob.png

没有更多推荐了,返回首页