mysqldatareader获取整行数据给datarow_数据同步系统重构实践

作者介绍

王鹏，2017 年至今加入去哪儿机票事业部服务平台，主要负责机票后服务相关业务，以及服务平台数据同步服务和基础索引服务的重构升级。

背景

在互联网时代，每天都会产生海量的数据，去哪儿网成立至今，积累了海量的用户出行数据，每一次旅行机票记录，酒店记录，门票记录等等，这些数据都存储到数据库中，现在流行的 Mysql 数据库，一般情况下单表容量在 1kw 以下是最佳状态，如果将所有的历史记录都存储到 DB 中，那么每张表的大小将超过 10 亿级，根据不同维度的查询将是一个梦魇，比如通过订单号查询，根据用户加状态查询等等，数据库将不堪重负，慢查询可能导致整个库不可提供服务。常用的解决方案是把这些数据存储到一个备用的数据库或者异构的数据结构中，来提升我们的查询效率。数据同步系统就是做这件事的，将数据从一个数据源导入另外一个数据源，提供同构或者异构、低延迟的的数据的同步，提供高可用的数据同步服务，并且保证数据最终一致性。

数据同步的开源方案

1.Databus

Databus 是一个低延迟、可靠的、支持事务的、保持一致性的数据同步系统。Databus 通过挖掘数据库日志的方式，将数据库变更实时、可靠的从数据库拉取出来，业务可以通过定制化 client 实时获取变更并进行其他业务逻辑。

几个特点：

• 来源独立：Databus 支持多种数据来源的变更抓取，包括 Oracle 和 MySQL。

• 可扩展、高度可用：Databus 能扩展到支持数千消费者和事务数据来源，同时保持高度可用性。

• 事务按序提交：Databus 能保持来源数据库中的事务完整性，并按照事务分组和来源的提交顺序交付变更事件。

• 低延迟、支持多种订阅机制：数据源变更完成后，Databus 能在毫秒级内将事务提交给消费者。同时，消费者使用 Databus 中的服务器端过滤功能，可以只获取自己需要的特定数据。

• 无限回溯：对消费者支持无限回溯能力，例如当消费者需要产生数据的完整拷贝时，它不会对数据库产生任何额外负担。当消费者的数据大大落后于来源数据库时，也可以使用该功能。

2.Canal

Canal 是阿里巴巴的一个开源项目，基于 java 实现，通过模拟成为 Mysql 的 slave 的方式，监听 Mysql 的 binlog 日志来获取数据，binlog 设置为 row 模式以后，不仅能获取到执行的每一个增删改的脚本，同时还能获取到修改前和修改后的数据，基于这个特性，canal 就能高性能的获取到 Mysql 数据数据的变更。

几个特点 ：

• 来源只支持 Mysql。
• 扩展性，Canal 可以将数据发送到 Kafka，或者 MQ 中这样可以由开发者自定义如何分配数据。
• 低延迟，ms 级别的延迟同步，满足接近实时系统的同步需求。
• 事务性，支持通过不同方式解析和订阅 MySQL binlog，例如通过 GTID。
• 支持回溯，取决于 binglog 存储的时间，可以反查位点进行重新同步。

对比	Canal	Databus
支持来源	Mysql	Mysql Oracle
扩展性	发消息通用消息接口	多消费者支持
延迟	低	低
事务性	支持	支持
支持回溯	支持调整位点	支持
复杂度	相对简单	复杂

通过对比可以发现，Canal 和 Databus 在主体功能方面并没有太大区别，因为在当前的环境下不存在 Oracle 数据库同步的问题，所以我们选型选择了 Canal 作为数据同步的一个技术解决方案，另外相对于 Databus 的配置和部署实施 Canal 也是相对简单的。

老系统的历史问题

老系统的问题很多，如何重构？

核心流程：

1. DB 产生的 Binlog 通过 Canal 传输到 Databus(内部自研的，与开源同名)中，Databus 又分为生产者和消费者两个大的模块。Binlog 的接受者即 Databus 的生产者，这个模块的主要作用是解析 Binlog 数据并且转化为一个通用的数据结构 DataRow。当然Databus也可以接受其他类型的数据源，比如公司的 QMQ、Kafka 等数据源。

2. 转化的 DataRow 通过 Kafka 发送到消费者，消费者模块主要是进行聚合操作，这些数据传递给异步的数据存储系统，比如 ES、Hive 等等。

3. 存储系统现在选择的是 ES 作为最终的存储介质，ES 本身具有分布式，高可用，存储海量数据并且提供快速查询。并且提供主备两个集群支持高可用和负载均衡。

4. 整体的配置以及调度由 ZK 完成，包括 Canal 的主备，Databus 的生产者和消费者的上下线，以及索引的元数据管理都是在 ZK 中配置管理。

5. 查询服务，Qgalaxy 这个系统主要是提供了业务线查询的 API，统一的管理业务线的查询，每个业务线或者应用接入访问 ES 集群都需要通过这个服务，统一的进行鉴权，流量的切换以及限流。

通过架构的简化图

1. Databus 的生产者是单点的，非高可用的。这是非常严重的问题，如果存在某台机器宕机的情况，则某些索引的同步服务将暂停，导致故障。消费者端写入到某些 Kafka 或者 ES 的数据都是写死的，没有做成配置的，每次新增索引都要进行开发。切换不同的测试环境也十分麻烦。

2. Canal 的版本过低，老系统使用的是 1.0.19，开源版本已经更新到