canal 工作原理

• canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
• MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
• canal 解析 binary log 对象(原始为 byte 流)

基于日志增量订阅和消费的业务包括

• 数据库镜像
• 数据库实时备份
• 索引构建和实时维护(拆分异构索引、倒排索引等)
• 业务 cache 刷新
• 带业务逻辑的增量数据处理

我们实际业务中，常用于缓存层数据实时更新， 以往的方式 ：

1. 手动删除和更新缓存， 高并发下会造成脏数据。 

2. 消息队列方式，延时双删。 这会造成中间有间隔时间数据不一致， 另外对代码有侵入性。(也就是说需要主动的推送消息队列，订阅方去消费双删，这个是和业务无关的代码)

开始： 

1. mysql 服务器需要开发binlog 功能

如果是之前做过了主从复制，那么binLog是已经开启了的。参考

03-架构2023版-centos+docker部署mysql(主从复制版)

如果没有开启过的，就在my.cnf 中增加以下配置。 然后重启mysql

[mysqld]
log-bin=mysql-bin # 开启