业界使用较多的是阿里开源的 Canal 来进行 binlog 解析与同步。canal 会伪装成 MySQL 的从库,然后解析好行格式的 binlog,再以更容易解析的格式(如 json)发送到消息队列。

由下游的 kafka 消费者负责把上游数据表的自增主键作为Elasticsearch的文档的 id 进行写入,这样可以保证每次接收到 binlog 时,对应 id 的数据都被覆盖更新为最新。MySQL 的 Row 格式的 binlog 会将每条记录的所有字段都提供给下游,所以向异构数据目标同步数据时,不需要考虑数据是插入还是更新,只要一律按 id 进行覆盖即可。

这种模式同样需要业务遵守一条数据表规范,即表中必须有唯一主键 id 来保证我们进入Elasticsearch的数据不会发生重复。一旦不遵守该规范,那么就会在同步时导致数据重复。当然,你也可以为每一张需要的表去定制消费者的逻辑,但这不是通用系统讨论的范畴。

最后编辑: kuteng  文档更新时间: 2022-03-22 19:29   作者:kuteng