实时数据传输服务DBIO架构设计与实践

1、爱奇艺实时数据传输服务DBIO架构设计与实践技术创新 变革未来DBIO是什么？基于otter开发的数据迁移、变更订阅与实时同步服务IO InsideOut / InputOutput源DBlogloglog目标 系统Select（插件）获取数据变更Extract（插件）数据过滤Transform（插件）数据转换Load（插件）结果输出“伪装” 成Slave， 提取数据变更日志（CanalEntry）Insert Update Delete 源端5 种数据库：MySQL、 TiDB、MongoDB、Redis、 Couchbase全量+增量适配源端Failover 同步服务服务Failover自

2、动部署自服务：监控、告警、运 维自动化 目标端11 种目标系统：ActiveMQ、RocketMQ、Kafka、MySQL、TiDB、MongoDB、Redis、Couchbase、ElasticSearch、Kudu、HBaseMySQL分库分表单向+双向同步适配目标端FailoverWorker节点Manager节点配置推送 控制命令状态、统计 数据更新ZookeeperHA/同步位点源端支持更多数据库：TiDBDBIO实时获取并解析TiDB binlog至中间格式从Kafka获取数据后，解析为DBIO格式， 接入DBIO的传输通道TiDB binlog解析（ ProtocolBuffer

3、 ）格式转换（CanalEntry）Zookeeper（记录消费Kafka offset）SETL格式匹配问题：一对多转换；header/key/column/row等的转换；I/U/D的不同处理 字段匹配问题：bit(byte转换整形)/整形(根据MySQL字段类型处理溢出等问题)延迟时间计算：TSOexecutetime的转换源端支持更多数据库：其他DBIO伪装为源DB的slave，获取并解析Redis、MongoDB、Couchbase的log至中间格式CouchbaseRedisMongoDBPSYNC runid offsetBGSAVE全同步Transmit RDB部分同步back

4、logReplicator 同步控制器ConnectionCnxnReaderRESP协议解码RdbSinkAofSinkdbname.collname hash_id hashns1ns2oplogs_id hashActive vBucketDisk Write QueueDISKDCP QueueDisk snapshotPoint-in-time snapshotDCP ClientStream RequestMutation解码器流控、断点重试、特定分片、 特定时间、全量、实时中间 数据 格式支持更多目标端系统修改Load模块，使之支持更多目标端支持的数据格式不统一同步结果的确认方案

5、不统一异常的处理方法不统一API使用方法不统一保证重复操作幂等内置向MySQL分库分表同步组件向分库分表同步外接分库分表 中间件内置分库分表 模块优点：代码改造小缺点：重复SQL解析，同步延迟和吞吐量受影响；更多依赖，带来稳定性问题从Binlog解析出来的字段信息+插件化的分库分表规则支持常见的分库分表规则：range/hash/list/crc文本形式的分库分表规则，代码侵入性低 插件化：界面中配置，操作灵活，便于运维性能影响小MySQL ProxyDBIO（load）ShardingSphere内置向MySQL分库分表同步组件连接池换为HikariCP， 吞吐量提升15%内置分库分表组件比

6、外接组件吞吐量提升60%分表数越多，性能越低MySQL全量数据同步资源限制流量限制逻辑复杂 内存资源有限计算资源有限写数据QPS过高会导致目标端集群故障读写数据QPS不一致会导致内存不足(OOM)/资源浪费并发：(1)多表同时同步数据; (2)单表数据并行写入目标端终态：(1)提取数据完成; (2) load数据完成健壮性：单条数据同步失败，(1)不影响整体同步进度; (2) 不 影响同批次其它数据同步难点流式提 取数据内存使用可控读取速度可控限流源端限流：令牌目标端负载能力负反馈，影响源端提取数据的流量流程控 制器同步流程控制： Extract+Load异常信息处理： 重试与记录MySQL全

7、量数据同步流量 控制流程控制DBIO HA方案Region-XAZ1MasterAgentMySQL(从库)AgentMySQL(主库)AZ2Agent MySQL(从库)多路故障检测自动选新DB Master保证数据一致性HA Master自身高可用保证CMDB数据准确Raft GroupMasterMaster捕获DB连接异常查询CMDB获取最新DB Master IP+Port根据timestamp/GTID定位新Master起 始位点源DBIO端目标端通过域名访问Failover策略：捕获异常+重试 （封装在SDK中）涉及到的高可用问题源DB HA目标DB HAIO自身的HAMySQL

8、间双向同步方案Binlog event增加特定操作BEGINTABLE_MAPWRITE_ROWSTABLE_MAPWRITE_ROWSCOMMITMySQL 1(全量数据)MySQL 2(全量数据)MySQL 3(全量数据)写：user_id % 3 = 0 的数据写：user_id % 3 = 1 的数据写：user_id % 3 = 2 的数据user_id % 3 =0user_id % 3 =2user_id % 3 = 0&1user_id % 3 = 1&2前提条件：业务数据单元化 + 冲突交由业务处理Entry1Entry2continuehas check info & ch

9、eck FAILED discardEntry3has check info & check OKcontinueno check infoSelectEntry1Entry3add check infoadd check infoLoad利用双向同步实现MySQL异地多活数据拆分：单元化数据（异地多活）、全局数据（同城HA）单元化数据：每个Region部署一套MySQL集群，Region间通过DBIO双向同步，保证每个Region都可读写全局数据：利用MySQL 同城HA保证高可用SDK：对业务屏蔽后端数据库访问细节，实现透明故障切换/运维R&WSDK透明分库分表/读写分离/DB Failo

10、verMySQL 2(全量)MySQL 3(全量)W：user_id % 3 = 1 R：ALLW：user_id % 3 = 2 R：ALLW：user_id % 3 =0 R：ALLMySQL 1(全量)双向DBIO双向DBIORedisRedisRedisDBIO实时缓存更新MySQLMasterSlave1Region_1Region_2Region_3 业务单元 化数据Slave2 全局数据M-SM-S 缓存数据Zookeeper自服务平台工作流引擎+脚本 运维自助/告警自愈集群：同地域跨IDC部署，避免单IDC故障调度：根据规则自动关联集群，选择内存/CPU利用率最小且跨IDC的双

11、节点进行部署，节点故障重新调度DBIO ClusterManagerWokerWoWkeorkerWokerZookeeperWorkerAZ1WokerWoWkeorkerWokerWorkerAZ2ManagerWokerWoWkeorkerWokerZookeeperWorkerAZ3Zookeeper ClusterRegion-X关联集群工作节点 推荐根据目标 端选择部 署方式账号密码 等敏感信 息存储构建配置 信息在ZK等写 入配置更新 CMDB信息服务部署工作流从CMDB获取配置 信息工作流引擎运维工单/ 告警配置与工作 流的映射提交工作流任务执行工作流自服务平台DBIO在爱奇艺

12、的应用DBIO已在爱奇艺稳定运行2年多，有千条实时同步流，吞吐量百万行/秒MySQL间同步需求最强烈主要应用场景为：DB功能拆分RMQ逐步取代ActiveMQ数据 变更 通知汇总 各端 数据实时归档DB功能 拆分应用 场景在线 统计实时 构建 索引实时 缓存 更新数据 迁移MySQLRocketMQKafkaActiveMQElasticSearchKudu MongoDBCouchbaseTiDBRedisHbase各目标端占比DBIO常见应用场景DBDBIOM Q模块间的消息通知实时数据分析DBDBIODBDBTable1 Table2 Table3DBTable1Table3Table2分库：拆分为多个小DB，对应不同应用场景写读读读DBDBTable1Table2DBIODBTablex多表合并为一个宽表将多个库中的表汇总到一个库DBIODB写Tbl_Uid_