如何高效实现 MySQL 与 elasticsearch 的数据同步

分手后的思念是犯贱 2023-09-24 23:54 48阅读 0赞

##  ##

MySQL 自身简单、高效、可靠，是又拍云内部使用最广泛的数据库。但是当数据量达到一定程度的时候，对整个 MySQL 的操作会变得非常迟缓。而公司内部 robin/logs 表的数据量已经达到 800w，后续又有全文检索的需求。这个需求直接在 MySQL 上实施是难以做到的。

### 原数据库的同步问题 ###

由于传统的 mysql 数据库并不擅长海量数据的检索，当数据量到达一定规模时（估算单表两千万左右），查询和插入的耗时会明显增加。同样，当需要对这些数据进行模糊查询或是数据分析时，MySQL作为事务型关系数据库很难提供良好的性能支持。使用适合的数据库来实现模糊查询是解决这个问题的关键。

但是，切换数据库会迎来两个问题，一是已有的服务对现在的 MySQL 重度依赖，二是 MySQL 的事务能力和软件生态仍然不可替代，直接迁移数据库的成本过大。我们综合考虑了下，决定同时使用多个数据库的方案，不同的数据库应用于不同的使用场景。而在支持模糊查询功能的数据库中，elasticsearch 自然是首选的查询数据库。这样后续对业务需求的切换也会非常灵活。

那具体该如何实现呢？在又拍云以往的项目中，也有遇到相似的问题。之前采用的方法是在业务中编写代码，然后同步到 elasticsearch 中。具体是这样实施的：每个系统编写特定的代码，修改 MySQL 数据库后，再将更新的数据直接推送到需要同步的数据库中，或推送到队列由消费程序来写入到数据库中。

但这个方案有一些明显的缺点：

*  系统高耦合，侵入式代码，使得业务逻辑复杂度增加
 *  方案不通用，每一套同步都需要额外定制，不仅增加业务处理时间，还会提升软件复复杂度
 *  工作量和复杂度增加

在业务中编写同步方案，虽然在项目早期比较方便，但随着数据量和系统的发展壮大，往往最后会成为业务的大痛点。

### 解决思路及方案 ###

#### 调整架构 ####

既然以往的方案有明显的缺点，那我们如何来解决它呢？优秀的解决方案往往是 “通过架构来解决问题“，那么能不能通过架构的思想来解决问题呢？

答案是可以的。我们可以将程序伪装成 “从数据库”，主库的增量变化会传递到从库，那这个伪装成 “从数据库” 的程序就能实时获取到数据变化，然后将增量的变化推送到消息队列 MQ，后续消费者消耗 MQ 的数据，然后经过处理之后再推送到各自需要的数据库。

这个架构的核心是通过监听 MySQL 的 binlog 来同步增量数据，通过基于 query 的查询旧表来同步旧数据，这就是本文要讲的一种异构数据库同步的实践。

#### 改进数据库 ####

经过深度的调研，成功得到了一套异构数据库同步方案，并且成功将公司生产环境下的 robin/logs 的表同步到了 elasticsearch 上。

首先对 MySQL 开启 binlog，但是由于 maxwell 需要的 binlog\_format=row 原本的生产环境的数据库不宜修改。这里请教了海杨前辈，他提供了”从库联级“的思路，在从库中监听 binlog 绕过了操作生产环境重启主库的操作，大大降低了系统风险。

后续操作比较顺利，启动 maxwell 监听从库变化，然后将增量变化推送到 kafka ，最后配置 logstash 消费 kafka中的数据变化事件信息，将结果推送到 elasticsearch。配置 logstash需要结合表结构，这是整套方案实施的重点。

这套方案使用到了kafka、maxwell、logstash、elasticsearch。其中 elasticsearch 与 kafka已经在生产环境中有部署，所以无需单独部署维护。而 logstash 与 maxwell 只需要修改配置文件和启动命令即可快速上线。整套方案的意义不仅在于成本低，而且可以大规模使用，公司内有 MySQL 同步到其它数据库的需求时，都可以上任。

#### 成果展示前后对比 ####

使用该方案同步和业务实现同步的对比

![6b7e3f56527591a0defcef7f68755309.png][]

写入到 elasticsearch 性能对比

[6b7e3f56527591a0defcef7f68755309.png]: https://img-blog.csdnimg.cn/img_convert/6b7e3f56527591a0defcef7f68755309.png