共计 1144 个字符，预计需要花费 3 分钟才能阅读完成。
同步 MySQL 数据至 Elasticsearch/Redis/MQ 等的五种形式
在理论利用中，咱们常常须要把 MySQL 的数据同步至其它数据源，也就是在对 MySQL 的数据进行了新增、批改、删除等操作后，把该数据相干的业务逻辑变更也利用到其它数据源，例如：
- MySQL -> Elasticsearch，同步 ES 的索引
- MySQL -> Redis，刷新缓存
- MySQL -> MQ (如 Kafka 等)，投递音讯
本文总结了五种数据同步的形式。
1. 业务层同步
因为对 MySQL 数据的操作也是在业务层实现的，所以在业务层同步操作另外的数据源也是很天然的，比拟常见的做法就是在 ORM 的 hooks 钩子里编写相干同步代码。
这种形式的毛病是，当服务越来越多时，同步的局部可能会过于扩散从而导致难以更新迭代，例如对 ES 索引进行不兼容迁徙时就可能会牵一发而动全身。
2. 中间件同步
当利用架构演变为微服务时，各个服务里可能不再间接调用 MySQL，而是通过一层 middleware 中间件，这时候就能够在中间件操作 MySQL 的同时同步其它数据源。
这种形式须要中间件去适配，具备肯定复杂度。
3. 定时工作依据 updated_at 字段同步
在 MySQL 的表构造里设置非凡的字段，如 updated_at（数据的更新工夫），依据此字段，由定时工作去查问理论变更的数据，从而实现数据的增量更新。
这种形式你能够应用开源的 Logstash 去实现。
当然毛病也很显著，就是无奈同步数据的删除操作。
4. 解析 binlog 同步
比方驰名的 canal。
通过伪装成 slave 去解析 MySQL 的 binary log 从而得悉数据的变更。
这是一种业界比拟成熟的计划。
这种形式要求你将 MySQL 的 binlog-format 设置为 ROW 模式。
5. 解析 binlog — mixed / statement 格局
MySQL 的 binlog 有三种格局：
ROW模式，binlog 按行的形式去记录数据的变更；statement模式，binlog 记录的是 SQL 语句；mixed模式时，混合以上两种，记录的可能是 SQL 语句或者ROW模式的每行变更；
某些状况下，可能你的 MySQL binlog 无奈被设置为 ROW 模式，这种时候，咱们依然能够去对立解析 binlog，从而实现同步，然而这里解析进去的当然还是原始的 SQL 语句或者 ROW 模式的每行变更，这种时候是须要咱们去依据业务解析这些 SQL 或者每行变更，比方利用正则匹配或者 AST 形象语法树等，而后依据解析的后果再进行数据的同步。
这种形式的限度也很显著，一是须要本人适配业务解析 SQL，二是批量更新这种场景可能很难解决，当然如果你的数据都是简略的依据主键进行批改或者删除则能比拟好的实用。
结语
最初列举几个 binlog 解析的开源库：
- canal
- go-mysql
- zongji
