MySQL同步到ES的方案选型

本文参考:

• https://www.bilibili.com/video/BV13hvZeaErr/?vd_source=b7e4d17fd13ffa91c4da6d37c08a6c7c

最近在重构某个老系统，其大部分查询逻辑都是做在 MySQL 存储层上的，当面临一些复杂的过滤逻辑以及分页逻辑时，都需要后端工程师根据前端传参做一些定制逻辑，后端项目上线发布的人力成本较大，并且大部分过滤逻辑都是在后端代码内部做的，代码可读性与复用性都不高。同时随着时间的迁移，数据库的数据量越来越多，核心首页接口的耗时碰到了瓶颈。为了项目未来的发展，于是决定将原项目重构，进行读写异构分离建设，写入 MySQL，查询走 ES。于是调研了一下 MySQL 数据写入 ES 的一些方式，简要分析各个方案的优缺点。

主要包含以下 4 种方案：

1. 同步双写
2. 异步双写
3. 另起应用 SQL 查询写入
4. Binlog 实时同步

1. 同步双写

数据写入 MySQL 的同时，通过编程逻辑将相同逻辑写入 ES

优点

1. 实时性

   数据变更能直连写入 ES，近乎保证了 ES 的实时性

2. 简单性
   实现起来比较简单，不需要引入额外的组件，也不需要复杂的逻辑

缺点

1. 性能影响

   应用内部每次写入 MySQL 同时写入 ES，会对两个系统同时产生影响

2. 数据一致性风险

   如果双写失败，比方说写入 MySQL 以后应用宕机未写入 ES，两者数据不一致

3. 系统耦合

​ 每个写入操作都需要双写逻辑，增加了业务的复杂性和维护难度

4. 集群容灾差

   如果要实现多集群容灾写入，相同的写入逻辑需要往每个集群都做一次

实现方式

分别调用 MySQL 和 ES 的 Client SDK 双写即可

2. 异步双写

利用消息队列异步处理数据写入操作

优点

1. 性能提升

   MQ 异步处理，减少了接口同步等待的时间

2. 容错性
   消息队列有持久化和重试机制，提高了 ES 数据同步的可靠性

3. 集群容灾水平高
   MQ 消息可以被不同集群的 ES 消费者组监听

缺点

1. 数据延迟

   异步处理数据延迟较高

2. 系统复杂度

   需要引入消息队列和额外的消费逻辑，增加了系统的复杂度

3. 数据一致性风险

   虽然消息队列具有持久化机制，可以重试保证最终一致，但是当应用写入 MySQL 但是还未将消息投递到消息队列时，仍然具有一致性的风险

实现方式

1. 首先需要接入消息队列，在应用代码中编写生产者逻辑
2. ES 侧也需要有消费者的逻辑

3. 另起应用 SQL 查询写入

通过定时任务或者单独起一个应用，去查询数据库中的某个时间段内的记录，并作转换逻辑同步至 ES

优点

1. 性能提升

   也是异步处理，减少了接口同步等待的时间

2. 无侵入性
   不需要修改原有的业务逻辑，原系统对此无感知

缺点

1. 时效性差
   定时任务或者应用 RPC 拉取仍然存在延迟

2. 性能压力
   查询某一时间段数据会对原来的数据库产生额外的查询压力

3. 集群容灾差

   如果要实现多集群容灾写入，相同的写入逻辑需要往每个集群都做一次

实现方式

1. 维护时间戳字段，方便每次查询出新时间段的记录
2. 定时任务/应用代码逻辑单独上线

4. Binlog 实时同步

利用 MySQL 的 Binlog 日志，通过消息队列消费变化来同步至 ES

优点

1. 性能提升

   也是异步处理，减少了接口同步等待的时间

2. 无侵入性
   不需要修改原有的业务逻辑，原系统对此无感知

3. 数据一致性
   MySQL Binlog 可以精准捕捉到数据库的所有变更

4. 容错性
   通常搭配 MQ 使用，在网络波动下仍然能够重试，保证数据的最终一致；并且 MQ 还具有一定的削峰作用，对 ES 写入较友好

缺点

1. 系统复杂度
   需要维护 Binlog 日志监听和消息队列系统，增加了系统的复杂度
2. 延迟问题
   “准实时”同步，但是其中涉及到不同组件间的网络传输较多，相比于直连写入 ES 延迟较大

实现方式

1. MySQL Binlog 日志开启
2. Binlog 监听器配置
3. 消息队列集成，确保 Binlog 变更能够发送到消息队列中
4. 消费者逻辑开发，从消息队列中读取 Binlog 并转换成 ES 可以理解的格式

5. 应用场景

• 在公司内部通常都采用第4种解决方案，通常都有内部的平台使用，实现存量数据和增量数据的迁移，前面两种方式还需要修改原有的逻辑代码。

• 如果追求时效性的话，可以增加冗余写入链路，比方说直连写入 + 异步写入，保证一致性的同时增强时效性，但是注意处理 ES 的冲突解决策略，通常两条相同记录的写入采用的是替换 Replace 策略。