京东的也出来了,明显的阿里痕迹
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官网已经有了数据迁移的功能,另外也在公测更多服务。
到底怎样的应用会需要异地的双活?比较常见的场景有三个。
-
两个地域或多个地域都有大量用户的场景,比如在中国的用户希望他们用杭州的RDS服务,在美国的用户用美国RDS服务,这就需要数据在异地同步。很多游戏、金融、传媒、电商业务都有这种需求。满足这个需求的难点主要在于跨地域的网络,比如网络延时长,丢包多,而且数据在公网传输会有数据泄漏风险。
-
数据来源较多,需要接入各种异构数据的场景。比如一个应用需要从ODPS、RDS、OTS、OceanBase、PostgreSQL这几个服务接入数据,它们的数据结构和接口都不同 ,这种接入的成本会比较高。因此另一个可用的方法是数据写入的时候就一份多写为不同数据结构。
-
下游订阅很多的情况,比如一份数据,备份系统、通知系统、大数据分析系统、索引系统等等都要来取,如果用上面一份数据多写的方案是可以应对的,但这里还有其他难点,就是数据一致性、可扩展性、跨网同步稳定性、以及同步的实时性。
所谓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)实时性,需要做到秒级别的延迟。
双单元的同步架构有两种,一种是读写分离的方式,中心写,单元读。单元需要的数据如果没有从中心及时同步过来,或者同步错了,那有问题这段时间的交易会全部收到影响。这里的核心是,保证秒级延迟,同时,保证一致性。
第二种同步架构是单元封闭的方式。中心和单元各有写入,我们通过冗余,使得中心和单元随时可以各自接管。
这里的关键是:
-
-
异地多活中DRC的核心能力就是在低延迟,一致性和高可用。
一致性:
-
-
-
-
单元化对DRC的要求是跨单元的延迟在1秒以内,否则,可能会影响用户体验,双十一峰值的用户量非常大,一旦延迟用户有感知,可能会有带来很多投诉。通过很多方面来实现这个稳定的秒级延迟:
-
-
-
-
-
-
-
-
-
-
-
-
在2014年双十一,我们处理了2000个实例的增量数据,峰值每秒处理了30GB的数据,有17000多下游做实时订阅。除了交易峰值限流,核心库同步均无延迟。
在小微里,DRC支持OB1.0的跨域数据同步。
在集团,DRC支持不同的下游消费订阅实时增量数据。
在云上,DRC已经提供了一年半的迁移上云的服务,每周有300+RDS
DRC正在实现为更多RDS用户提供便捷的服务:
-
-