阿里DRC介绍 zt

京东的也出来了，明显的阿里痕迹

Jingobus。呵呵没准也是canal/otter派生出来的。

http://server.it168.com/a2015/1109/1775/000001775824.shtml

-------------

http://pan.baidu.com/s/1mg9o4TM#path=%252FQCon%25E5%258C%2597%25E4%25BA%25AC2015%25EF%25BC%2588PPT%25EF%25BC%2589%252F4%25E6%259C%258823%25E6%2597%25A5%252F%25E4%25BA%2591%25E8%25AE%25A1%25E7%25AE%2597%25E9%25AB%2598%25E5%258F%25AF%25E7%2594%25A8%25E6%259E%25B6%25E6%259E%2584%25E8%25AE%25BE%25E8%25AE%25A1%25E4%25B8%258E%25E5%25AE%259E%25E8%25B7%25B5

异地双活数据架构基础设施DRC

傅翠云（延瑛）分享的话题是阿里巴巴的异地双活数据中心DRC。傅翠云在2008年加入Oracle，曾任Berkeley DB的高级软件工程师，从事Berkeley DB数据库和高可用内核开发。2013年加入阿里巴巴数据库技术团队，任数据库专家，目前负责数据流产品DRC，参与了2014年阿里巴巴双十一交易异地双活数据同步和订阅、RDS迁移上云服务、七网隔离跨域同步、性能分析和优化、数据校验、链路优化等。

所谓异地双活主要关注两件事，一个数据同步，一个数据分发。阿里异地双活数据架构基础设施DRC目前已经正式上线在RDS产品，现在RDS官网已经有了数据迁移的功能，另外也在公测更多服务。

到底怎样的应用会需要异地的双活？比较常见的场景有三个。

1. 两个地域或多个地域都有大量用户的场景，比如在中国的用户希望他们用杭州的RDS服务，在美国的用户用美国RDS服务，这就需要数据在异地同步。很多游戏、金融、传媒、电商业务都有这种需求。满足这个需求的难点主要在于跨地域的网络，比如网络延时长，丢包多，而且数据在公网传输会有数据泄漏风险。

2. 数据来源较多，需要接入各种异构数据的场景。比如一个应用需要从ODPS、RDS、OTS、OceanBase、PostgreSQL这几个服务接入数据，它们的数据结构和接口都不同 ，这种接入的成本会比较高。因此另一个可用的方法是数据写入的时候就一份多写为不同数据结构。

3. 下游订阅很多的情况，比如一份数据，备份系统、通知系统、大数据分析系统、索引系统等等都要来取，如果用上面一份数据多写的方案是可以应对的，但这里还有其他难点，就是数据一致性、可扩展性、跨网同步稳定性、以及同步的实时性。

所谓DRC，就是Data Replication Center的缩写，数据复制中心。这种复制是同步的，支持异构的，高可用的（有严格容灾系统，实时性好），支持订阅分发的。

以前在一个城市做双机房主备，两个机房是数据对等的，写入是随机分布，然后通过主备HA进行数据同步。这样机房对等的思路会导致业务增长、数据增长只能通过两个机房不停堆机器来解决。另一方面，如果整个城市断电，那么双活就成了双死。下一个思路是做跨城市，早期常用的做法是一个城市写，另一个城市冷备，就是晚上做同步，但这就意味着白天如果发生了什么事儿，这一天的数据就比较危险。另一个思路是两个城市多写，数据落两边，这样的问题是应用调用次数频繁的话，如果调用异地数据多来那么一两次，整个应用的延时就很长。这个思路再进一步发展，就是做单元内封闭以减少异地调用，这就涉及到业务上的改造。

顺着这个思路，阿里的异地双活重点做了几件事。一个是热插拔，可以做到在业务高峰时增加节点，高峰过了把增加的节点关闭。做到这个的一个关键是流量实时切换，DRC可以在20秒以内把一个单元（region）的流量迁移到另一个单元。另一个是数据实时恢复，就是通过一定的冗余设计，一旦一个单元挂掉了，可以在另一个单元做全量恢复。

2014年双十一，这套异地双活系统处理的规模是，抓取了约100TB的实时数据量，给17000多个实时下游提供了最高每秒30GB的数据量。2014年期间DRC已经覆盖了超过50%的新增RDS实例。

ppt做的实在不敢恭维。。

-----

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

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

 

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

 

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

 

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

 

 

DRC的架构图：

 

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

 

 

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

 

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

 

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

 

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

 

 

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

 

 

这里的关键是：

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

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

 

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

 

 

 

一致性：

-          数据有序：抓取的增量是流式的，通过pipeline实现保证数据的有序性。//kafka？？

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

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

-          事务一致：在DRCcongo模块实现的一种基于事务冲突检查方法，通过事务间的有向图实现事务并发逻辑。//？？？

 

 

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

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

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

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

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

-          数据稳定性：热点数据，缓存，并发解析等…

-          …

 

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

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

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

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

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

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

 

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

 

 

在小微里，DRC支持OB1.0的跨域数据同步。

 

 

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

 

 

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

 

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

-          RDS跨域同步：RDSreplication本身不支持跨域，DRC通过异步复制，对RDS无入侵。

-          RDSbinlog服务：目前已支持RDS和DRDS。可以通过单机版集群版的客户端订阅新增数据，就像水龙头一样。目前我们已经支持的内部客户包括opensearch，CDP，精卫，网聚宝等数据搜索服务。