DB与ES混合应用之数据实时同步

一时失言乱红尘 2023-05-22 06:35 9阅读 0赞

**一、技术背景**

DB与ES本质上是属于不同应用领域的数据库产品，混合应用在一起主要面临2个问题 ：

*  同步实时性，数据在DB更新之后，需要多久才能更新到Elasticsearch，多久的时间是应用系统可以接受的范围，一般需要控制在1s以内，如果是分钟以上，那这就属于离线同步。
 *  数据一致性，数据频繁在DB变更修改，更新到Elasticsearch之后如何保证数据与DB一致，在容许的时间范围内应用系统查询的数据有效的，可接受的，如果变更出现覆盖等，那数据是无效的，应用系统是不可接受的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70][]

在数据同步方面，主要有3种同步模式

*  推送模式，数据源将变更数据推送到目标源，如RabbitMQ产品，服务端会主动MQ发送到客户端。
 *  拉取模式，目标源定时去数据源拉取变更数据，如Mysql数据库的数据主从同步机制，Slave会去Master拉取变更数据。
 *  推拉结合，数据源与目标源之间，既有推送方式，也有拉取方式，此种模式一般会借助于中间媒介实现，如基于Kafka产品的日志应用，数据源（采集端）会将日志数据发送到Kafka集群，目标源会定期的从Kafka拉取数据更新。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 1][]

**二、技术方案**

从技术层面看，DB同步到ES有好多种方式

*  同步双写，更新DB时同步更新ES。此技术方案最简单，附带问题最多，数据冲突，数据覆盖，数据丢失，处处是坑，谨慎选择。
 *  异步双写，更新DB之后，记录一条MQ，MQ通知消费端，消费端反向查询DB数据，最后更新到ES。此技术方案与业务系统耦合严重，需要更加业务需求独立编写，且每个业务都需要专门编写相关程序，非常不利于快速响应需求。
 *  CDC，全称Change Data Capture，变更数据捕捉，从数据库内部捕捉变更数据，将变更数据推送到中间程序中，中间程序逻辑实现同步推送到ES。CDC机制速度极快，数据精准，且与应用程序耦合少，可抽象脱离业务系统，适合大规模使用。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 2][]

CDC机制原有设计是为了同类型数据库之间数据同步，应用在主从同步高可用方面，所以同类型数据库之间数据同步非常容易实现，数据库厂商本身天然支持，经过多年实战验证高效可靠。相反，在异构数据库之间实现数据同步是比较复杂的，数据链路长，中间涉及到的技术点特别多，且每一步都非常关键，下面就以本人所在公司采用的技术栈讲述如何实现，以及一些技术关键点。

**三、案例**

Mysql同步到ES

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 3][]

数据从Mysql同步到Elasticsearch主要涉及到以下几个技术关键点

*  Binlog机制
 *  Canal中间件
 *  Kakfa中间件
 *  同步应用程序（业务型开发成中间件）

**3.1 Binlog机制**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 4][]

Binlog是Mysql自带功能机制，设计之初是为了数据库之间主从同步

*  Master主库，启动Binlog机制，将变更数据写入Binlog文件
 *  Slave从库，从Master主库拉取binlon数据，回放Binlog，更新从库数据
 *  启用Binlog注意以下几点
 *  Master主库一般会有多台Slave订阅，且Master主库要支持业务系统实时变更操作，服务器资源会有瓶颈
 *  需要同步的数据表一定要有主键

**3.2 Canal中间件**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 5][]

Canal是Mysql的中间件产品，专门应用在数据同步

*  伪装Slave从库，
 *  拉取Binlog数据，
 *  回放Binlog数据，
 *  解析Binlog数据为Json，报文记录了新旧数据，数据库数据表，更新方式

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 6][]

*  输出数据，并保证变更顺序，输出目的源支持很多，常规的一般输出到kafka

配置cannl注意以下几点：

*  Canal基于Jvm运行，数据处理能力不如Mysql，Canal需要配置集群模式。一组Canal集群不能支持太多的事数据库实例。
 *  若是数据库做了水平的分库分表 ，原有Canal是不能识别为一类数据源，需要稍微修改部分代码
 *  建议Canal订阅的Slave从机，因为Master是业务主库，主库承担的业务系统职责太多
 *  Binlog日志模式建议启动Gtid，Canal订阅的数据库如果出现故障，需要基于此切换到其他数据库。
 *  数据输出到Kafka，若数据库是做了分库分表的，需要修改Canal部分代码。
 *  设置Kafka分区键相同，保障相同数据变更顺序。

**3.3 Kafka中间件**

使用Kafka作为中间缓存，主要基于以下几个方面考虑

*  分区特性，Kafka支持分区，并发性能好，数据吞吐能力超过mysql，性能不会成为瓶颈
 *  分区顺序存储，Kafka数据存储是有顺序的，设置好主键，保障Binlog变更顺序
 *  消费顺序，客户端消费Kafk数据，会基于Offset，按顺序消费，保障Binlog变更顺序
 *  消费组，严格意义上讲，Kafka并非熟悉消息队列，应该算消息流，我们在上一篇文中讨论数据模型映射需求，一个数据表可能会映射到多个索引，这就需要设置不同的消费组，保障多个消费组之间不冲突覆盖，同样的变更数据有多次重复消费

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 7][]

**3.4 同步程序**

同步程序当前基于Java自主开发，当前的主流同步工具不能很好支持自定义需求，主要包括两大程序  
同步任务调度程序

*  同步调度配置，配置同步任务，配置同步映射关系，DB到ES的映射，Kafka到ES的映射
 *  同步调度分配，同步任务操作，启动、停止、重新设置；同步任务分配，指定并行度等。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 8][]

同步任务执行程序

*  执行任务，将数据从Kafka经过映射写入到Elasticsearch中，主要由4大模块组成
 *  Kafka模块，拉取消费数据，记录消费位置
 *  Mapper模块，执行映射过程，数据表与索引映射，表字段与索引字段映射，生成指定的Json格式数据
 *  Elastic模块，将Mapper生成好的Json数据提交到Elasticsearch中，成功则提交消费记录位置，失败则走另外逻辑
 *  Schedule模块，基于线程级别维度执行同步任务，支持同步任务启动暂停等操作，实时汇总同步任务的指标数据

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 9][]

**3.5 数据同步全过程回顾**

数据从DB更新到ES，中间经过多个环节，同步模式既有推送，也拉取，且多次结合完成。

*  Mysql写入到本地binlog，推送模式
 *  Canal读取binlog写入Kafka，先是拉取模式，后是推送模式
 *  Worker同步程序从Kafka读写数据，经过处理写入到Elasticsearch，先是拉取模式，后是推送模式

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 10][]

**3.6 注意事项**

DB到ES实时同步整体项目链路很长，且涉及技术点较多，任意环境都会导致一些问题，有一些特别注意

*  DB刷数据问题，由于DB是批量更新，后面几个技术节点会出现部分性能瓶颈
 *  DB多表关联深度问题，DB多表直接关联最好的关系是1对1，主要ES映射也可以基于主键关联更新，无需反向查询
 *  ES高级类型限制问题，ES本身支持很多高级数据类型，但这些在同步程序中最好不要使用

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 11][]

**3.7 问题遗留**

项目推进过程中，遇到不少问题，有的已经解决，有的是无法解决，有的会改善解决

*  数据校验，DB数据虽然同步到ES中，但目前是没有有效的方法去校验正确性的，传统的方式校验方式是随机两边查询对比，非常的低效，此处需要探讨更好的数据比对方法，
 *  数据修复，当数据发现不正确时需要自动能够修复，但由于数据校验的低效，数据修复的准确性也有待考量
 *  技术演进，数据同步程序是自主基于Java开发，但做了很多非业务时间工作，程序大量的工作在调度且涉及很传统，考虑引入Flink平台，由平台负责底层资源掉度，上层只需配置同步映射，当前正在测试中。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 12][]

**四、经验总结**

DB到ES数据实时同步，前后经过的时间很长，经过了好几次的技术方案演进，未来还有很大的优化改进空间。  
最终进化到CDC这种方案也是基于已有的经验分享（参考马蜂窝技术博客），设计思路一样，技术实现不一样。  
数据同步整体技术实现中间环节很多，任意技术点都需要了解透彻，否则会出现很多致命事故，需要多人团队协作完成。  
CDC并非新概念，几乎所有数据库产品都支持，如下：

*  Postgresql 有 Logical Decoding
 *  Sqlserver 有 Change data capture 和 Change Tracking
 *  Oralce 有 Redo log和 Oralce Golden Gate
 *  Mongodb 有 Replicate sets
 *  Elasticsearch 有 Translog

若之后遇到类似数据实时同步需求，优先选择CDC技术方案 .

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 13][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70]: /images/20230521/783793aafbb244cb85106c4742964521.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 1]: /images/20230521/5bb12d69783c41039f9ee89f1185c74b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 2]: /images/20230521/aea5f1c2ba0c4f7abbb20d1ca8c9be2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 3]: /images/20230521/ccb4739485b244b8bc4c5c66a457e688.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 4]: /images/20230521/bda3b61946e94c14b28db18d1367d9e9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 5]: /images/20230521/e10f7941f56a42f591f72a80b9a5f326.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 6]: /images/20230521/c14628794ae148a3bcc6a6eb6cfbb3c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 7]: /images/20230521/cb69f758731a4ab6962e61b6b348f51e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 8]: /images/20230521/241fab1bdcb441a9aa2144a539a8b827.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 9]: /images/20230521/54c04861874847afbb1694f62979adc5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 10]: /images/20230521/aae92f23dabc484e8117b4c88faa1ab5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 11]: /images/20230521/d2a1442ab26541c6b48fd30735550b4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 12]: /images/20230521/9ab42a2fa0e94db3bbc0d88a2785e90a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1b3Fpbmdsb25nODUwMTAy_size_16_color_FFFFFF_t_70 13]: /images/20230521/2ea866ea0c4a45aba41492f35cb5878e.png