DTCC2019 爱奇艺实时数据传输服务

  • 时间:
  • 浏览:6

数据库间实时数据传输服务可错综复杂业务系统的数据架构,使其专注于业务开发。DBIO是爱奇艺研发的数据库间实时数据传输服务,用于同异构数据库间实时群克隆与数据变更捕获,是业务系统数据共享的核心通道。

作者:郭磊涛

编辑:张晓艺

郭磊涛,爱奇艺数据库服务负责人507年博士毕业于中国科技大学,进入中国移动研究院负责大数据平台的建设,2014年加入爱奇艺负责数据库内核、上边件及运维系统的研发,热衷于 Hadoop 生态系统优化和数据库高效运维架构。

本文根据郭磊涛老师在DTCC数据库大会分享内容分派而成,将介绍 DBIO 的设计与实现,重点分享在源和目标端故障时如可保证服务高可用、如可优雅的支持多种源与目标端系统以及如可高效运维等方案。一起,也将介绍 DBIO 在数据变更订阅、异地多活、数据归档等方面的应用案例。

1. 爱奇艺数据库架构

爱奇艺是一家以科技创新为驱动的伟大娱乐公司,科技创新的前提是提供稳定、安全、高性价比的基础服务。数据库服务团队负责爱奇艺所有业务线的数据库、数据库上边件等的开发与运维工作。面对不同的业务角色,人们 歌词 歌词 针对性地提供相应的服务。人们 歌词 歌词 目前提供了基于开源和自研的缓存、kv、文档、图及关系数据库,部署在物理机、虚机和公有云上,网络环境异构、集群跨DC,那此都给数据库运维带来了巨大挑战。

人们 歌词 歌词 面向DBA的运维管理系统经历了脚本、工具化、平台化到智能化演变。运维平台化还须要确保规范运维,错综复杂运维操作,减少运维失误。在此基础之上,尝试进行智能运维的探索。首先将常见故障及告警的根因定位封装为工具,手动或自动触发后对系统进行全面诊断。比如,MySQL主从群克隆延时告警原因分析分析分析是由写入吞吐量欠缺、网络故障、Slave节点IO/CPU打满、大事务等因素引起,通过那此工具快速定位根因。另外,人们 歌词 歌词 对报警也进行了多维度的聚合,从而减少无需 要的告警或提高一点告警优先级等。一起,人们 歌词 歌词 还对各数据库集群进行容量管理,对不合理的资源进行动态缩容和扩容,并通过合理的数据库实例分配和迁移策略,提升服务器利用率实现降低成本的目的。

对于应用的开发者,人们 歌词 歌词 提供客户端SDK及上边件,来实现运维操作对业务的透明,从而让业务只关注业务逻辑的开发,而涉及到后端DB的工作则由SDK去除理,如连接超时和重试等机制。除了提高运维波特率和开发波特率外,自服务平台提供全版信息展示、预警报告、自助运维等功能,并结合智能客服来降低需人工除理的业务咨询量。

本次将介绍数据库服务团队研发的数据传输上边件DBIO,它还须要协助业务实现多端数据全量和实时同步。

2. DBIO简介

DBIO是数据库的数据迁移、实时变更订阅与同步服务。它基于阿里开源的otter项目逐步完善而来,目标是成为数据库间数据共享的通道,实现任意数据库间数据的灵活搬迁与同步,让业务只关注业务逻辑开发,而底层数据互通则通过DBIO来实现。

没法为什么我么我么实现数据的互通呢?首先,人们 歌词 歌词 要除理的是如可高效的获取源端数据库的实时数据。各种数据库,包括kv、文档和关系数据库在有数据变更时,比如插入、更新、删除等须要记录变更日志。那此变更日志一方面用于故障后重放以保证数据全版性,我本人面用于主库和从库之间的数据同步。没法,人们 歌词 歌词 只须要获取数据库的变更日志,就还须要得到实时的数据库数据。 otter通过将其伪装为MySQL的slave,获取到mysql binlog,并经过ETL数据除理后写入到目标系统。otter部署和使用时主要包括3个服务,即manager提供了web配置和同步任务控制接口,并须要无需 承担数据同步的功能,真正的同步任务都运行在worker节点上,zookeeper用于记录主次元数据及服务高可用的管理。

人们 歌词 歌词 对otter做了扩展和优化,从而更匹配人们 歌词 歌词 的业务需求,也更易于管理。比如,对源端数据库的支持从MySQL扩展到5种数据库,对目标端系统从MySQL扩展到11种,增加了内置向MySQL分库分表同步的组件。支持了全量数据的同步、增强了HA和双向同步、数据除理ETL各阶段都支持用户自定义插件从而实现更加灵活的数据条件过滤、类型/字段映射转换以及写入到目前端时数据存储格式优化等等。本文将主要介绍人们 歌词 歌词 对otter的功能增强的难点、实现方案及应用实践。希望那此经验还须要帮助到人们 歌词 歌词 了解如可基于otter来构建另另一个数据库数据迁移与同步的服务,以及如可灵活的使用你这名 服务来满足各种业务需求。

3. DBIO关键技术

3.1 源端支持更多的数据库

在DBIO中除MySQL外,还支持TiDB、MongoDB、Redis、CB数据的实时获取与同步。

1、TIDB

TiDB是PingCAP公司开源的分布式数据库,适用于TP和AP的场景。在2017年下二天 爱奇艺现在开始了了英文调研测试TiDB,并在2018年中正式上线,目前原因分析分析分析在视频上传、生产、风控等核心业务线应用。人们 歌词 歌词 上线的业务大须要从MySQL迁移到TiDB的,MySQL上的数据变更订阅、同步等也须要在TiDB上支持。一起,TiDB版本更新非常快,为了应对TiDB原因分析分析分析带来的不稳定以及频繁的升级等,人们 歌词 歌词 须要把TiDB的数据同步到MySQL等其它系统。但会 ,人们 歌词 歌词 在DBIO的源端也增加了TiDB。

TiDB的binlog是由TiDB Server生成并发送至Pump Cluster进行局部排序,如果再由Drainer模块归并排序最终形成全局有序的binlog日志,并同步到下游下游支持TiDB、MySQL等,一起为了方便接入其它系统,也支持Kafka。DBIO正是通过Kafka取到TiDB binlog,消费Kfaka消息,解析并转加进DBIO的上边数据格式。人们 歌词 歌词 在接入时主要遇到一点数据格式、数据类型等转换的问题报告 。原因分析分析分析TiDB binlog须要经过Pump cluster->Drainer->Kafka等几条流程才还须要得到,但会 以TiDB为源的同步延时相对要高一点,实测在4-8秒。

2、一点

对于接入Redis和Couchbase(后简称cb)作为源端,人们 歌词 歌词 采用和接入MySQL累似 的法子,即DBIO伪装成Redis和cb的Slave节点,来获取全量和增量的数据变更。接入Redis时,人们 歌词 歌词 启动另另一个同步控制器Replicator,向Redis Slave发送PSYNC runid offset指令,Redis会根据runid和offset来判断否是须要先做全量数据同步,原因分析分析分析须要一句话会执行bgsave把内存中的数据存成rdb文件回传。原因分析分析分析不须要,就从群克隆缓冲区backlog中直接取操作指令给DBIO。要注意的是,全量和增量数据格式不一样,须要分别除理。

Couchbase是另另一个分布式NoSQL数据库,一般作为缓存使用(后简称cb)。cb的kv读写性能高于redis,且扩展性非常好,无需 有在爱奇艺的几乎所有在线业务须要使用cb。人们 歌词 歌词 在DBIO中接入cb的主要动机是希望把cb数据转存到其它更便宜的kv存储中。原因分析分析分析cb数据要基于全内存存储才还须要达到很高的性能,成本较高。而人们 歌词 歌词 发现一点业务人太好使用cb,但它们实际的qps和延迟要求无需 高。这时,人们 歌词 歌词 会建议它们迁移到同样高性能但成本更低的基于ssd和内存的kv存储上,你这名 kv存储在人们 歌词 歌词 组织组织结构的项目叫HiKV。HiKV是基于wisckey的存储法子,即key和value分开存储,key在内存,value在ssd,优化了LSM-Tree的写放问题报告 报告 。把cb接入到DBIO源端相比其它几条系统要简单一点,原因分析分析分析cb的数据群克隆协议DCP还须要把cb变更,包括从磁盘上的存量数据以及内存中的数据写入到DCP queue队列中。人们 歌词 歌词 只须要启动另另一个DCP Client来读取queue中的数据,解析即可。DCP Client读数据时,会带上起止序列号seqno,原因分析分析分析消费的序列号会记录在zookeeper中。原因分析分析分析DCP client故障,DBIO failover到另外一台服务器再从zookeeper读取seqno就还须要继续从cb获取数据了。

累似 的法子,也还须要得到mongodb的操作日志oplog,全版的做法就不赘述了。

3.2 支持更多目标端系统

除了接入更多的源端外,人们 歌词 歌词 对同步的目标端也做了扩展。

DBIO在读取到数据并转换为上边数据格式后,会通过ETL流程对数据进行过滤、转换等。原因分析分析分析要接入更多目标端,只须要扩容Load模块即可。Load模块会根据配置来判断目标是须要MySQL或TiDB,原因分析分析分析是MySQL或TiDB,会继续判断否是向分库分表同步等等。原因分析分析分析目标端须要MySQL/TiDB,则会进入初始化异构目标端Loader的过程,你这名 过程会建立与目标端的连接,并将数据批量的写入。在修改Load模块时,人们 歌词 歌词 遇到的问题报告 主无需 不同目标端数据格式不同的问题报告 、主次系统写入成功否是的确认法子、异常除理以及如可保证幂等。对于批量Load失败时,DBIO会回落到逐条Load,以保证数据写入成功。原因分析分析分析重试多次都写入失败,则该批次同步失败,再次进行重试。

目标端分成另另一个大的通道,其一是原生支持的MySQL,相对来说会比较心智成熟的句子的句子期期是什么是什么是什么图片 图片 一点。人们 歌词 歌词 拿到第一根数据如果,来看它目标端是须要MySQL,原因分析分析分析是,就走MySQL通道,原因分析分析分析须要,就走异构的数据同步通道。原因分析分析分析是像MySQL同步,人们 歌词 歌词 会看目标端是须要分库分表,原因分析分析分析是分库分表,会有另另一个组件来自动将其同步至分库分表。原因分析分析分析是向异构数据同步,人们 歌词 歌词 会先做批量,原因分析分析分析是批量有失败,再逐条加载。

在接入多种目标端时,也支持向MySQL分库分表的同步。目标端是分库分表的场景在爱奇艺非常常见。比如在业务上线初期并未预想到数据的增量,上线一段时间后发现没法分库分表不能满足需求。通过DBIO还须要帮业务提前把全量和增量数据同步至分库。在接入分库分表时人们 歌词 歌词 也走了一点弯路,最初为了接入方便,人们 歌词 歌词 直接用mysql proxy实现分库分表,DBIO写proxy。但会 原因分析分析分析引入了proxy,同步总出 错误或延时,问题报告 排查比较错综复杂,但会 proxy为了实现高可用还须要引入虚拟ip或域名,这又增加了一层依赖。如果 ,人们 歌词 歌词 遗弃了proxy你这名 外接的分库分表上边件,无需 把你这名 功能紧耦合进DBIO的Load模块,通过groovy配置分库分表规则,在性能、灵活性和运维错综错综复杂上须要降低。

Load模块中内置的分库分表组件的实现:Load模块会初始化分库分表规则,并把路由规则缓位于内存。对于每第一根数据,都通过路由规则计算,得到它在目标端的实际数据库名和表名,并把你这名 信息回填到该行记录中。这里要特别提出的是,原因分析分析分析shardingkey(分片键)上有update操作,Load模块会提前把update分解为另另一个操作,即delete+insert。修改完记录后,把该行记录发送到并行加载通道。并行加载通道中,首先对同另另一个主键上的I/U/D操作进行合并,比如U+D合并为D,I+U合并为I等,目的是减小写入目标端的记录数。如果根据DML类型排序,再去构建对应的SQL一句话。SQL一句话执行的粒度是,每个PrepareStatment会并行执行,执行如果会查询该SQL一句话的目标端,获取分库datasource后写入。 在分库分表组件中,人们 歌词 歌词 把无需 的DBCP连接池替换为更为高效的HikariCP,吞吐量有了15%的提升。与外接Proxy的方案相比,内置分库分表组件的吞吐量提升50%。另外,人们 歌词 歌词 对不同分库分表数也做了压测,分库分表数无需 ,性能越低。但会 ,须要合理设置分表,并须要无需 越好。

3.3 MySQL全量数据同步

进行全量的数据在DB间搬迁,须要考虑的最主要问题报告 无需 限流,即如可读源端数据除理影响源端正常的读写,如可写目标端系统除理写入QPS欠缺原因分析分析数据积压或群克隆延迟等。另外须要考虑的无需 如可控制数据迁移的整体逻辑,比如如可并发读写,如可进行错误重试等。

将MySQL数据全量导出到其它系统的方案,中有 另另一个模块,即数据提取模块extract task和数据导入模块load task。通过流程控制器来协调另另一个模块的工作,并对异常信息同步进行重试和记录。在流量控制方面,采用从mysql流式读取的数据,但会 通过令牌桶来保证读取数据的QPS在设置的范围内。如果,对读到的数据进行业务自定义的过滤和转换,并写入到另另一个BlockingQueue中。Load任务从BlockingQUeue读数据,并批量或单条写入目标端。原因分析分析分析目标端负载较高,写入QPS低,则BlockingQueue有数据积压,Extract任务也会阻塞,直至目标端正常。通过读写限流,除理了全量同步对源和目标端的影响。

3.4 DBIO HA方案

DBIO一般应用于实时在线的数据同步,无需 有须要保证在各种故障下还须要快速检测故障并恢复,保证同步流程的正常运维。没法原因分析分析分析造成同步异常的故障有那此呢?分别为:源端DB异常、目标端系统异常以及DBIO服务线程运行运行异常。

首先,介绍一下数据库系统并须要的高可用方案。以MySQL 的一主多从集群中主库故障为例,来看MySQL并须要如可实现failover。人们 歌词 歌词 在每台服务器上须要启动另另一个agent线程运行运行,它会监控在这台服务器上的多个mysql实例的情況,并与master集群保持心跳。某个MySQL主库故障时,agent会监控到该信息,Master集群中的leader节点会对你这名 mysql集群进行多路检测,以确认该mysql主库人太好故障,如果会选泽出为宜的从库来提升为主库。新主库的选泽策略是,与原master同机房,且具有最新的binlog和relaylog。一旦某个从库提升为主库,其它从库都须要从新主库apply差异的binlog,如果master会将原故障主库上的域名重新绑定到新MySQL 主库上并更新CMDB的信息,完成MySQL failover过程。为了除理HA Master的单点故障,人们 歌词 歌词 启动了多个HA Master组成raft group来实现HA Master的高可用。

现在看DBIO如可应对源端系统的failover。源端系统failover期间,DBIO肯定会触发连接异常,经无需 伦重试仍失败时,则从CMDB查询到最新的主库,并根据如果同步的最新时间点,找到从新主库上同步的起始位置后现在开始了了英文同步。原因分析分析分析开启了gtid,则根据gtid来选泽从新主库同步的起始位点。

对于目标端故障,人们 歌词 歌词 也是累似 的方案。区别是,源端是通过DB的IP和端口来获取数据,目标端通过域名访问数据库。数据库团队发布的SDK,对数据库failover的异常除理做了封装。无需 有,目标端的failover在DBIO这端基本不须要做那此。

没法,DBIO并须要原因分析分析分析故障,是为什么我么我么除理的呢?你这名 比较简单,也是otter原生就支持的。它通过zookeeper来监控各个worker节点否是在线,原因分析分析分析有worker节点异常,manager会将dead worker上的同步流迁移到备用worker上。从线上数据库和DBIO的failover耗时统计看,基本上故障在没法1分钟内还须要自动检测并恢复正常。

3.5 MySQL间双向同步方案

数据库间双向同步须要重点除理的是如可除理数据回环,即从A同步到B的数据,没法再从B同步回A,但会 你这名 数据就会在另另一个DB间相互不停的写入。

人们 歌词 歌词 的除理方案是,在通过DBIO写入目标MySQL时,对同步的数据打上标记。但会 在DBIO的Select读数据时检查你这名 标记,丢弃回环数据。如上图示例,3个数据库分别负责同另另一个业务不相交的数据写入,但会 通过DBIO来做相互同步,最终每个DB都存储有全量数据。人们 歌词 歌词 看从mysql2到mysql3的DBIO同步。对于3条记录,第第一根记录是mysql2写入的,DBIO未发现标记位,则同步到mysql3。第2条数,上边有标记且是mysql3的标记,与目标端相同,则丢弃。第3条数据,有标记但会 mysql1的标记,不构成回环,则把数据写入mysql3。应用双向同步有另另一个前提条件,无需 另另一个双向同步的DB上没法同一时间对同另另一个key更新,但会 会造成冲突。这就要求业务在应用双向同步时首先须要对数据进行单元化切分。

基于双向同步,人们 歌词 歌词 进一步还须要实现MySQL的异地多活。累似 于前面介绍的双向同步的约束条件,人们 歌词 歌词 还须要把业务单元化数据部署到不同的地域(比如两地三中心),通过DBIO双向同步,从而每个DB须要全版的数据。我本人面,有一点全局数据无法拆分,还须要仍然采用MySQL主从集群或Group Replication集群部署。原因分析分析分析某个Region故障,则还须要把流量切到其它Region。数据库服务团队提供的SDK接入了配置中心,当切换到另外另另一个Region的集群时,修改配置中心的配置。SDK接收到配置变更通知,会逐步断开老连接,并连接到新配置的集群。无需 有SDK在人们 歌词 歌词 的应用开发中占有非常重要的作用。

4. DBIO自服务平台

前面介绍了一点功能和方案,没法如可把你这名 工具变的易用也非常重要。人们 歌词 歌词 开发了另另一个基于Web的自服务平台,业务还须要提交同步流申请、查看同步情況、订阅告警、并可对工作流进行启停或配置修改等操作。如可把那此错综复杂的运维和告警除理自动化,就依赖后台的工作流引擎。

当接收到另另一个运维工单或告警时,会把它和如果定义好的另另一个工作流任务关联。你这名 工作流任务无需 除理你这名 工单或告警的一系列脚本。工作流引擎生成工作流任务的配置信息,并提交执行任务。除理脚本提前保位于gitlab上,工作流任务执行引擎从gitlab下载脚本,并根据工作流的顺序来执行那此脚本。

上图示例的是DBIO服务部署工作流,在执行须要读取工单信息和CMDB信息,生成同步任务的配置,并选泽同步任务的执行集群和worker节点,配置生成后就还须要启动同步任务了。为了保证服务的高可用,DBIO的集群是跨IDC部署的,无需 单个IDC故障,不影响可用性。在进行同步流任务调度时,根据worker节点的资源利用率以及与原和目标端系统的延时来选泽为宜的worker。

5. DBIO在爱奇艺的应用

DBIO原因分析分析分析在爱奇艺稳定运行2年多,有千条实时同步流,百万行/秒的吞吐量,延时在50ms左右。各种目标端对比看,MySQL间的同步需求最多,主要用于DB功能拆分。另外MQ方面,如果主无需 AMQ,但原因分析分析分析它扩展性及容错性差,逐步被RocketMQ所替代。

DBIO常见应用场景

首先是用于模块间的消息通知。在用DBIO如果,业务须要写DB成功后再发送MQ,通知其它模块。现在业务只须要直接写MySQL,消息通知交由DBIO,一起MQ的消费端也可用于实时数据分析。

第二种场景是DB功能拆分。对于另另一个业务的基础库,原因分析分析分析须要支持多表事务,无需 有没法在另另一个MySQL中存储所有数据。但会 ,你这名 业务的多个子系统原因分析分析分析只须要主次数据。原因分析分析分析那此子系统直接读基础库,一方面原因分析分析分析会造成影响,另外另另一个方面无需 方便我本人扩展进行个性化的表定义。你这名 场景下,还须要使用DBIO来做功能拆分,即每个子系统只同步须要的数据。无需 业务开发会更加灵活。

另外另另一个场景无需 多库映射到另另一个库上,比如多表合并成另另一个宽表、将多个库中的表汇总到另另一个库以及实时归档等。

当然,还有M到N的同步映射,一般应用于分库分表改变了映射规则、分库扩容或数据迁移等场景。

还有并须要应用场景是在分表上实时构建反向索引。比如业务希望基于用户查询对应的红包信息,也须要根据红包查询用户信息。此时业务还须要只写用户表(基于用户id分表),DBIO读取用户表变更信息,并把数据重新写入到红包表(基于红包id分表)中。

6. 展望

人太好DBIO原因分析分析分析比较稳定,但一点问题报告 还没法全版或优雅地除理。比如源端DDL操作如可优雅的同步到目标端,如可高效地校验同步数据的一致性等。一起,人们 歌词 歌词 也正在把业务常见的使用方案进行封装,变成通用易用的平台能力,更好地为各业务线服务。

我的分享就到这里,谢谢人们 歌词 歌词 !

本文由

ITPUB

发布在

ITPUB

,转载此文请保持文章全版性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/07/19/2453/