作者:天羽
我一直深信,“不是因为有了机会才争取,而是因为争取了才有机会;不是因为会了才去做,而是因为做了才能会;不是因为拥有了才付出,而是因为付出了才拥有!”
DRC是什么?
DRC(Data Replication Center)是阿里技术保障-数据库技术团队自主研发的数据流产品,支持异构数据库实时同步,数据记录变更订阅服务。为跨域实时同步、实时增量分发、异地双活、分布式数据库等场景提供产品级的解决方案。DRC在阿里服务了数万个实时通道,在刚刚过去的2015双11,DRC峰值每秒解析一千万条记录,三单元同步平均延时500毫秒。
![2715977a56ab3420ce4742244f00dcb4edcb7f6a](https://i-blog.csdnimg.cn/blog_migrate/573b667a284c1c85653629c6ffab24c3.png)
DRC今天已经是阿里巴巴的基础设施,支持电商异地多活、大数据实时抽取、搜索实时数据、蚂蚁商户账单,甚至双11的“酷毙了”的媒体大屏等。在云上已经有上百个外部用户通过阿里云数据传输产品DTS调用DRC建立自己的容灾体系。我认为DRC是阿里数据生产到数据消费的底层基础设施,就像网络一样无处不在。
DRC是怎么做起来的?
很肯定的说,DRC是以解决数据库的痛点为出发点的,是在一次次刚需驱动下做起来的。
大家知道MySQL数据库Master到Slave的同步,一直是单线程apply。在2011年,淘宝的评价库作为一个写入大的应用,最早出现了主备延时,Slave单线程apply很容易出现主备延时,因为主库的业务写入一直是并发的,再加上我们当时都是SAS硬盘(写入性能不足)。一般这种情况只能拆库,把库拆小一点,单实例写入就少一点。
另外就是淘宝一直在做单元化项目,最早叫做“走出杭州”,我们要在北方站点A建设一个单元来跑读流量,该项目2009年是冷备,2011年开始试验流量,2012年才有正式切读流量,2013年实现淘宝最小单元化环境,2014实现近距离异地双活,到今年双11实现远距离的异地多活,大家可能都听说过了。
2011年站点A大概部署了几十台服务器,混跑全站MySQL,远距离的单线程复制就更加不可保障延时了。技术上此时有两种解法,在MySQL内部做并发apply,或者做个第3方工具模拟Slave拉数据再像应用一样并发写入Slave。我们相信在内核里解一定是未来,但因为当时对MySQL内核把控没有足够把握,就先在外面做。
DRC第一任开发者董开,在MySQL内核专家希羽的指导下,经历近半年的迭代,于2011年9月完成了第一个版本DRC 1.0。一个进程负责实时拉取MySQL日志,并且并发写入Slave,单进程干完所有的活。然后很快就发布了了DRC v1.1,解决了过多线程重复拉Slave日志以及表过滤规则正则匹配。当时的架构大概是这样的[2011年10月]。
尽管理论上解决了问题,但这个版本配置复杂,易用性和稳定性很差,加上投入不足,DBA一度质疑DRC的作用(当时我是DBA,也是这么看的)。后来数据库内核专家丁奇了解了这个需求,用MySQL框架快速实现了一个transfer,作为一个独立的MySQL进程,模拟从库拉日志,然后并发写备库。使用上相当于一个定制化的Slave,跟MySQL Slave长得几乎一样,只有部署的DBA本人才知道那是一个transfer。
当时DRC和transfer都在用,DBA在实际工作中基本是遇到延时了就临时启一个,不延时就去掉,因此只有个别DBA会用到这两个工具。站点A单元本身O记延时就大,主要是应用和搜索测试。但是因为站点A没有部署完整链路,业务都是读,没有写逻辑,无法自己失效Tair,跨域远程失效代价太大,因此需要依赖数据库日志来失效本地Tair。DRC-Tair版本7月份发布,站点A2011年8月就已经用DRC来失效Tair。
交易主库2011年12月底去O后,站点A读流量终于不依赖O记延时,开始规划2012年站点A正式跑生产流量,店铺、商品详情页等应用要支持30%的读流量,我们开始批量使用DRC用于杭州到站点A的复制。当时我们意识到这条链路是非常重要的生产依赖,开始找人才加大投入。
去IOE后大量使用MySQL,DBA开始感到不幸福了。除了运维自动化程度不够之外,还因为拆库拆表非常频繁,每次都要去通知下游,漏通知一个就会故障。而此时数据库,除了DRC同步站点A链路外,还有非常多的账号来拉取数据,搜索每天晚上全量拉数据,数仓也是按表拉全量,业务也开始使用精卫来拉数据做业务逻辑,而部分数仓实时业务也想把增量的O记版的dbsync改成MySQL版。这就意味着核心库除了前台业务外,还会有至少5个下游账号,预期还会增加。而一个业务方内部也会有很多子团队,因此拆一个库要通知十几个团队是很正常的,靠接口人发邮件,然后晚上拆库时一起熬夜改配置。上下游都很痛苦,一个漏通知就故障了。另外,数据库性能瓶颈和账号安全性也是很大问题,因为一般拉数据都是公共账号,内部多团队共用。
因此,我一直希望DRC把单进程的抓取和写入分开成两个进程,通过进程间通信做到一次抓取,多次分发,至少以后新接入不要再建账号拉数据了。这时,一个契机来了,搜索刚好也在做技术迭代、做实时搜索。DBA和搜索团队达成全改增的一致目标,2012年1月份基本确认需求。
当时DRC已经有站点A数据同步和失效Tair链路的业务,是一个选择,而另一个阿里内部的数据分发工具精卫正在同步给前台业务逻辑,数仓dbsync在同步离线抽取,但这些工具里面没有一个可以马上服务于搜索,都要经过改造。
此时DRC已经在考虑统一同步链路的设计,2012年1月的插件化设计文档,只解决各种数据库间技术差异的问题,不解决DRC数据服务问题。
刚才提到的数据库拆库要通知下游,2012年站点A的实时需求,多个账号的同时存在,都是我们必须去解决掉的。因此我们必须建设一个增量同步中心,而当时可以说没有任何工具能够同时解决这些问题,除了DRC。
因为DRC从第一天设计开始,就选择了一条最难的路,保障数据库的事务一致性,包括DDL(表结构变更)也可以进行同步或过滤。而这是其他数据同步产品第一天就想避开的,因为那样简单高效。而DBA天生就在这个坑里,绝对不能让主备不一致、或事务不完整,哪怕只是一条数据。而且DBA迫切希望以后不用通知下游了,让DRC自动适配主备切换或拆库。
后面的路该怎么走其实很清晰,但是我们首先要服务好搜索这个业务。杰睿、二败、赤天三个主力开发,玉龙负责测试,本空作为架构师,开始考虑抓取和写入对不同的数据源插件化,引入zookeeper,调研Server?Framework做集群管理和路由。中间经历好几个版本,把各模块原型都开发完了,大概5月份,整体架构已经基本完成。此时主要考虑的需求有4个:
1. 机房容灾(站点A异地实时读)
2. 搜索的增量数据同步
3. 阿里云RDS数据库版本升级的数据迁移
4. MySQL数据导入到OceanBase(集团业务上OB迁移)
DRC团队提出了三大技术前提:1).强一致性; 2).实时性(<1S) 3).强鲁棒性。全力以赴,守护这几点。
原架构:通过插件支持多种源和目的,单机版工作,需要较多运维配套。
![ebaf4081c0e49a95e1563b2d41461d3137cf0e12](https://i-blog.csdnimg.cn/blog_migrate/d04b9fe161aeb9fbc22f05a57ecbbac3.png)
定下搜索增量服务的目标后,当时还有很多其他的需求需要经常沟通和核对,感谢玉龙记下这些珍贵的资料。
这段时间,我很少关注DRC,但我知道在角落里,有两个人天天干到深夜。二败和杰睿为了兑现给客户的承诺,为了心中的梦想,不眠不休。这段时间,我在做DBFree运维平台,对DRC的希望是,站点A不要延时太大。另外生产上我让吉远做了个工具,可以在MySQL原生复制和DRC之间一键切换,我们靠这个应对了2012年双11的主备延时。
在开启高大上新篇章之前,我特别想说一下参与的同学。DRC在2011年作为一个工具存在,还有很多问题很难解,董开压力巨大,走了。赤天前后脚进来,一直做失效Tair链路,直到12年7月离开DRC。杰睿和二败在12年初进来,有了玉龙和本空协助,面临巨大的机遇和挑战。我经常说DRC干挂了两批人,活下来真心不容易,但有了阿里这个舞台,有了梦想的坚持,一切皆有可能。
2012年7月,DRC内部版本,实现ClusterManager原型,主要是路由功能和容灾守护,引入zookeeper,已经和现在的架构非常接近,当时杰睿有个DRC免运维的梦想。2012年11月,增量平台v1.0正式发布,支持自动主备切换,支持DDL,支持库、表、列过滤。而搜索选择DRC的最主要原因是,DRC提供了心跳信息,搜索一般只订阅几个表,如果这几个表没有新的业务写入,位点就会停止,搜索不知道是任务异常了还是没有数据。而DRC在整个库有任何写入都会推进心跳位点,搜索可以基于心跳位点做合并时间。这成为搜索选型时确定使用DRC的最核心因素。
此时DRC服务于站点AMySQL同步、Tair失效、搜索和广告增量。虽然有集群管理,但依然是单进程服务架构,三个场景的进程版本不一样,使用插件式,已经支持数据库主备切换自动联动,DBA不需要再通知上下游。
但是问题又来了,一方面,数据库已经有那么多账号各拉一份自己的数据,DBA提出DRC一个账号只能来拉一次。另一方面,搜索业务已经成功上线,我们要合并版本,为马上要来的2013淘宝最小单元化环境准备。当时的DBA负责人后羿在交给我时,就已经提出了增量中心的目标,让数据库的账号安全和稳定性有保障。
我们做了两个重要业务决定,1、做好小淘宝单元化是首要目标 2、做增量中心,收敛账号,降低实时链路维护成本(非搜索场景DBA的人工通知还在持续)。
2012年底二败预研LevelDB做数据持久化,此时一个重要人物,来自华为的时勤博士加入,接手二败已经预发的版本,做DRC Queue。2013年4月年完成开发测试,DRC具备数据持久化能力。3月份我正式带DRC了,5月延瑛加入。我们在技术上做出两个重要技术决定,1、抓取和写入作为两个进程分离,一次抓取,多次订阅,reader继续插件化不变以支持多种数据源,合并DRC版本。2、引入embedded MySQL,所有的DDL都会内部执行一遍,为单元化架构准备,保障延时情况可复原数据格式,不丢一条,不错一条。
2013年7月,DRC单元化版本发布,同步和增量版本统一。
* Feature 持久化队列引擎
* Feature支持避免增量循环复制功能
* Feature 增量数据一对多分发
* Feature 数据事务并发复制
* Feature 增量任务自动容灾
* Feature 增量任务自动主备切换
问题来了,为什么是DRC?
我深信只有足够艰苦的付出才能获得丰厚的回报。DRC从第一天就选择了一条最难的路,做的是最底层,因此才能统一链路。从一开始,DRC就是为了解决MySQL内核缺陷,DRC团队找的人,全部都是数据库内核研发背景的。最最核心的是,DRC是被DBA骂起来的,也是DBA在单元化过程中反复使用推动了迭代,没有一直在边上骂的DBA,DRC可能会取巧走偏,不会硬着头皮,把看似不可能变成可能。DRC技术上最重要的3点,也是其他数据同步产品都不具备的能力。
* 保障事务的高效并发同步,DRC申请了多项事务冲突并发算法专利。其他同步产品不保障事务,保障事务是关系数据库同步的底线。
* MetaBuilder,解决回拉历史而表结构变更的问题,保障强一致。今天给你一条binlog,你可以知道数据,但不知道格式,是bigint还是varchar。如果是实时的,可以回查DB得到表结构Meta,来获得格式并完成拼接,这就是取巧的做法,但如果不实时,回查DB时,DB已经发生过DDL,拉到的Meta不是这个日志当初产生的样子,就无解了。而DRC的内嵌MySQL会执行和同步每个DDL,因此自己实时构造着和日志相同步调的Meta信息。
* DRC的代码效率,不管是存储压缩、带宽压缩、实时性、吞吐性能,一直赶在单元化需求前面。虽然在单元化上摔过跤,但我们一直按数据库内核的质量要求保障着核心代码。
是什么成就了DRC?
如果觉得以上3点答案还不够,那么我想说我们最大的财富就是有一票DBA兄弟共同战斗。非常感谢最早天天梳理单元化逻辑到深夜的胜通,出故障时顶着压力的张瑞、云浩,做数据实时校验产品的千震、奚越。
当DRC团队在角落埋头苦干解决下面3个问题的时候,DBA就在DRC的坑里一起扛着。我一直非常认可张瑞的一句话:没有DBA,就没有DRC。
* 站点A容灾机房,2009年开始建。2011年初核心去O后MySQL出现延时, DBA经常重建Slave。
* 2011-2013,大量的MySQL,大量的下游公共账号,部分还非得拉主库,DBA主备切换或拆库,要通知10多个团队,N个邮件列表,大家一起熬夜变更,一旦出现漏通知故障就由DBA扛。
* 2013年,淘宝最小单元化环境,数据库之间双向同步,循环复制。
2013年除了淘宝最小单元化,搜索、数据仓库、阿里云RDS都已经使用DRC做同步或增量服务。我称之为DRC基础设施建设年。
2014年,异地双活,阿里云官网上云,精卫也已经接入DRC,我们提供了自动化接入能力。我称之为DRC基础设施落地年。
2015年,也就是现在,是DRC的云上服务年,通过DTS提供数据同步服务。
DRC作为数据库同步基础设施,功能更好,因为我们的对手是阿里数据生产到数据消费日益增长的需求和成本。DRC要通过规模化服务能力,做好数据质量、稳定性和成本,成为网络一样无处不在的基础设施。
当我们聚焦在单元化场景时,现有架构已经可以把分发需求的服务成本边际化掉。但今天DRC的集群规模已经很大,线上几十个集群,最大的集群有接近7000个实时任务通道,目前正在进行着新一代集群架构研发,面向未来3年,支撑单集群5万个任务的管理。
最后,我想感谢一下曾经为DRC战斗,如今已经离开战线的老战友们。