写这篇的时候我先把标题里的“Cannal”纠正成正规拼写Canal——如果你在搜索引擎里敲“Cannal”大概率会被纠正或者搜出一堆不相关的东西但你真正要找的是阿里巴巴开源的 MySQL binlog 增量订阅组件 Canal。这个组件解决的是一个老生常谈但又非常痛的问题数据库一变下游怎么自动跟着变。我自己第一次认真研究 Canal是因为一个典型的线上事故运营在后台批量改了商品价格用户端看到的却是旧价格缓存里还攒着一堆脏数据。后来把 Canal 接入缓存刷新链路这类问题才算从根上解决。这篇文章我不会只扔给你官方文档里的“快速开始”我会把 Canal 的核心原理、部署选型、客户端接入方式和生产环境里最容易踩的坑按照我实际使用下来的经验完整讲一遍适合正在做数据同步、缓存一致性、搜索索引同步的团队参考。1. 为什么大家都在聊 Canal先搞清楚它解决的是哪类问题聊 Canal 之前先说一个几乎所有后端团队都绕不过去的场景你的核心数据在 MySQL 里但用户请求打到的是 Redis、Elasticsearch 或者某个异构数据库。1.1 业务双写为什么总翻车最朴素的做法是业务代码里写两遍先更新 MySQL再更新 Redis。看起来简单但上了生产就发现全是坑。比如更新顺序问题——你先写库再删缓存结果删缓存那一步失败了缓存里就是旧数据你先删缓存再写库又会有读请求在中间把旧数据重新塞回缓存。于是有人引入“延迟双删”有人用 MQ 重试代码越来越绕最后还是时不时冒出几个数据不一致的工单。更麻烦的是如果下游不止 Redis还有 ES 索引、数仓、报表库你得在每个写操作的地方把数据分发到所有下游。业务代码里塞满同步逻辑改一个字段要动好几个系统。1.2 Canal 的思路完全不同Canal 的核心逻辑是把自己伪装成 MySQL 的一个从库。MySQL 主库有 binlog 日志本来就是要发给从库做同步的Canal 只是模拟了从库的交互协议让主库觉得“又多了一个从库”然后把增量变更源源不断吐出来。下游只需要消费这份变更日志就能知道哪张表的哪一行发生了什么变化。这里有个很关键的点Canal 不侵入业务代码。你不需要在现有工程里改任何一行写操作逻辑只需要开启 MySQL 的 binlog部署一个 Canal Server然后在自己的消费端接收变更事件即可。这个特性让 Canal 成了缓存同步、搜索索引同步、数据异构复制场景里非常顺手的工具。1.3 Canal 和定时扫表、MQ 广播的对比有时候团队会想是不是可以用定时任务扫表或者干脆在代码里发 MQ 来通知下游定时扫表的缺点是你没法精确知道数据从哪一刻开始变的只能拿一个“最后更新时间”去猜延迟取决于轮询频率而且每次扫全表或扫大范围索引对数据库压力不小。业务代码里主动发 MQ 的缺点前面已经说过——侵入性太强还要处理 MQ 发失败和数据库事务不一致的问题。Canal 的优势在于它订阅的是 binlog 本身这本来就是 MySQL 的持久化日志只要主库写成功了binlog 就会存在Canal 就能把它消费出来不会出现“数据库提交了但通知没发出去”的问题。2. Canal 的工作原理拆解它怎么做到“像从库一样”拿数据很多教程会直接让你复制配置文件跑起来但如果不理解 Canal 的架构遇到问题你会完全无从下手。在这里我把 Canal 的内部链路拆开讲清楚。2.1 一条 binlog 从 MySQL 到下游的完整旅程整个过程可以拆成四段MySQL 主库开启 binlog并且格式必须是 ROW。Canal 要看到“哪一行变成了什么值”靠的就是 ROW 格式下记录的完整行数据。Canal Server 里的一个 instance 连接到主库发送COM_REGISTER_SLAVE命令带上自己的 server-id把自己注册成一个从库然后请求 dump binlog。主库推送 binlog 二进制流Canal 的 EventParser 负责解析把二进制解析成结构化的事件对象经过 EventSink 过滤、去重后放入 EventStore一个内存环形队列。下游客户端通过 TCP 协议或者 MQ 模式从 Canal Server 拉取数据拿到事件后自己决定怎么处理。注意最后一段——Canal 自己不消费数据它只负责把变更事件“吐”出来。真正消费数据、把变更写到 Redis 或 ES 里的是你的客户端程序或者 Canal 的另一个组件 Adapter。2.2 instance 是什么为什么一个 Canal Server 可以跑多个 instanceCanal 里有个核心概念叫 instance你可以把它理解成“一个独立的同步任务”。每个 instance 有自己独立的主库地址、订阅表规则、位点信息实例之间互不干扰。比如你有两个数据库集群一个负责订单一个负责商品你就可以在一个 Canal Server 上配置两个 instance分别连接两个 MySQL 主库。也可以把同一个库的同步按业务拆成多个 instance——不过要注意同一个主库的同一个 binlog被多个 instance 重复订阅会产生重复消费一般不建议这么搞除非你有特别明确的场景。2.3 位点管理Canal 靠什么记住自己读到哪了这是 Canal 能实现“断了重连还能续传”的关键。Canal 的位点信息Position可以存在内存里也可以持久化到本地文件或 ZooKeeper。如果你部署了集群模式多个 Canal Server 节点配合 ZooKeeper 做 HA那么位点信息必须放在 ZK 里这样主节点挂了备用节点能拿到位点继续消费。单机模式下存在本地文件就够用但要注意备份文件损坏意味着位点丢失重启之后 Canal 会从 binlog 最新位置开始拉中间那部分的变更就丢了。提示生产环境哪怕只跑单机我也建议你把 Canal 的位点相关文件做定期备份。位点丢失比消费慢更可怕慢可以追丢了就真的丢了。2.4 从 MySQL 主从同步的视角理解 Canal 的约束因为 Canal 本质是一个“模拟从库”所以它天然受 MySQL 主从同步的规则约束。比如你必须给 Canal 配置一个全局唯一的 server-id不能和真实从库重复否则 MySQL 会把旧连接踢掉再比如 Canal 账号必须有REPLICATION SLAVE权限没有这个权限连 dump 请求都会被拒绝。我之前就见过有人把 server-id 配成 1而 MySQL 主库自己的 server-id 正好也是 1结果就是 Canal 连接被反复断开日志里都是 dump 失败。这类问题你如果理解了 Canal 的“从库本质”排查起来就很快。3. 完整部署记录从一个干净的 MySQL 到 Canal 跑起来这部分我按真实的部署顺序写你可以直接照着操作。3.1 检查 MySQL 环境binlog 开关和格式Canal 工作的前提是 MySQL 已经开启 binlog并且使用 ROW 格式。你可以先执行下面两条 SQL 确认SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE binlog_format;如果log_bin是 OFF或者binlog_format不是 ROW需要修改 MySQL 配置并重启。我常用的配置在my.cnf里长这样[mysqld] # 开启 binlog文件名前缀自定 log-binmysql-bin # 必须是 ROW 格式Canal 才能拿到行级变化 binlog-formatROW # 配置一个唯一的 server-id注意不能与任何从库重复 server-id1 # binlog 保留时间建议设得长一点给消费端留出追数据的时间 expire_logs_days7这里有个细节expire_logs_days如果你的下游消费经常有延迟建议保留长一点比如 7 天。我踩过一个大坑就是 binlog 只保留 1 天结果 Canal 客户端因为升级停了 2 天回来之后 Canal 拉不到对应的 binlog直接从最新位置继续中间那两天的增量全都丢了。这也是为什么我说位点和 binlog 保留时间同样重要。3.2 创建 Canal 专用的 MySQL 账号Canal 需要连接主库拉取 binlog但这个账号不需要太多权限按最小化原则给就行CREATE USER canal% IDENTIFIED BY canal; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO canal%; FLUSH PRIVILEGES;SELECT权限是留给 Canal 的 adapter 做“回查”用的REPLICATION SLAVE和REPLICATION CLIENT是拉 binlog 必需的。我见过有人图省事直接给了所有权限当然也能跑但从安全角度不建议。3.3 下载部署 Canal Server我用的版本是 1.1.x 系列到这里下载对应的发行包并解压wget https://github.com/alibaba/canal/releases/download/canal-1.1.6/canal.deployer-1.1.6.tar.gz tar -zxvf canal.deployer-1.1.6.tar.gz -C /usr/local/ cd /usr/local/canal解压后的目录结构里conf/canal.properties是 Server 级配置conf/example/instance.properties是默认实例的配置。注意一个 Server 可以对应多个实例每个实例一个子目录目录名就是 instance 名称。3.4 canal.properties 里最关键的几个参数# Canal Server 对外提供 TCP 服务的端口客户端从这里拉数据 canal.port 11111 # 如果用了集群模式这里配 ZK 地址 canal.zkServers 127.0.0.1:2181 # 当前 Server 上要启动的 instance 列表多个用逗号分隔 canal.destinations example # 默认的 instance 加载模式单机用 spring 即可 canal.instance.global.mode spring单机场景下其实只需要关注canal.port和canal.destinations。canal.destinations决定哪些 instance 目录会被加载如果这里不写默认加载所有子目录但显式列出来更清晰避免误启动。3.5 instance.properties 里的配置逻辑这是整个部署里最需要理解的文件# 你要同步的 MySQL 主库地址 canal.instance.master.address 127.0.0.1:3306 # Canal 连接主库的账号密码 canal.instance.dbUsername canal canal.instance.dbPassword canal # 连接主库时的编码 canal.instance.connectionCharset UTF-8 # 订阅的表规则dbname.tbname支持正则 canal.instance.filter.regex test\\..* # 是否启用 tsdb表结构存储建议开启 canal.instance.tsdb.enable true # 是否使用 GTID 模式 canal.instance.gtidon falsecanal.instance.filter.regex这个过滤规则是个高频踩坑点。它使用的是 Java 正则并且点号.必须转义库名和表名之间用两个反斜杠\\分隔因为整个字符串要先经过 properties 文件转义再经过 Java 正则解析容易多一层或少一层转义。最简单的方式是先用test\..*这种字面量去测不要一上来就写复杂正则。canal.instance.gtidon如果主库开启了 GTID建议设为 true基于 GTID 的位置管理比基于 binlog 文件名加偏移量更可靠主从切换后也不容易丢位点。3.6 启动和验证# 启动 ./bin/startup.sh # 查看日志确认启动成功 tail -f logs/example/example.log如果配置正确日志里会看到类似dump address ...和success to connect的语句。也可以用 mysql 客户端直接连 Canal 的 11111 端口测一下mysql -h127.0.0.1 -P11111 -ucanal -pcanal连着之后执行任意一条 SQL比如SHOW MASTER STATUSCanal 会返回一个假的空结果但至少证明 TCP 服务已经通了。4. 客户端接入的三种姿势我为什么推荐自己写消费端Canal Server 跑起来之后数据怎么拿到手这里有三条路我逐个说清楚因为很多人在这一步浪费了不少时间。4.1 三条路的对比接入方式适合场景优点缺点canal-clientJava 库自己控制消费逻辑同步到 Redis、ES、业务库灵活可以完全控制 ack、并发、处理逻辑要写代码有一定开发量Canal Adapter不想写代码直接同步到 MySQL、ES、Redis 或文件开箱即用配置文件搞定灵活性差复杂的转换逻辑不好实现自研 TCP/RDP 客户端非 Java 技术栈可以对接任意语言需要阅读协议文档开发成本高4.2 canal-client 接入的完整示例我自己的多数场景都是 Java 技术栈所以最常用的是 canal-client。引入依赖dependency groupIdcom.alibaba.otter/groupId artifactIdcanal.client/artifactId version1.1.6/version /dependency然后写一个最简单的消费循环CanalConnector connector CanalConnectors.newSingleConnector( new InetSocketAddress(127.0.0.1, 11111), example, , ); connector.connect(); connector.subscribe(); connector.rollback(); while (true) { // 每次拉取最多 100 条事件不自动 ack Message message connector.getWithoutAck(100); long batchId message.getId(); if (batchId -1 || message.getEntries().isEmpty()) { // 没有数据释放这批 connector.ack(batchId); Thread.sleep(1000); continue; } for (Entry entry : message.getEntries()) { // 只处理行数据变更 if (entry.getEntryType() ! EntryType.ROWDATA) { continue; } RowChange rowChange RowChange.parseFrom(entry.getStoreValue()); EventType eventType rowChange.getEventType(); String tableName entry.getHeader().getTableName(); for (RowData rowData : rowChange.getRowDatasList()) { if (eventType EventType.INSERT) { // rowData.getAfterColumnsList() 就是插入后的行数据 } else if (eventType EventType.UPDATE) { // before 是更新前after 是更新后 } else if (eventType EventType.DELETE) { // rowData.getBeforeColumnsList() 是删除前的行数据 } } } // 这一批全部处理成功再 ack如果中途失败rollback 会重新投递 connector.ack(batchId); }这段代码里有几个细节值得展开getWithoutAck拉到的 batchId 是这批数据的唯一标识。处理完必须ackCanal 才会确认“这批复用了”如果你处理失败可以调rollbackCanal 会把这一批重新发给你。这个机制是 Canal 消费可靠性的核心。我习惯把ack放在整个批次处理结束之后而不是每行处理完就 ack。这样虽然失败会重复消费一整批但至少不会出现“处理到一半崩溃却告诉 Canal 我已经消费完了”的情况。EventType里除了 INSERT、UPDATE、DELETE还有 CREATE、ALTER 等 DDL 事件。生产环境里 DDL 也要监控比如下游 ES 的索引结构也许需要跟着变如果完全忽略 DDL表结构变更后同步链路会悄悄失效。4.3 把变更应用到 Redis 缓存一个真实场景以文章开头那个改价事故为例我写过一个简化版的同步逻辑if (!product.equals(tableName)) { continue; } for (RowData rowData : rowChange.getRowDatasList()) { String productId null; for (Column column : rowData.getAfterColumnsList()) { if (id.equals(column.getName())) { productId column.getValue(); } // 这里你也可以把整行数据拼接成一个 JSON } if (eventType EventType.UPDATE || eventType EventType.DELETE) { // 删除旧缓存 redisTemplate.delete(product:detail: productId); } if (eventType EventType.INSERT || eventType EventType.UPDATE) { // 从 MySQL 回查最新数据再写缓存或者直接用 after 列拼 JSON // 建议回查因为 after 列可能不是完整行数据 } }这种“变更后删缓存读时再回填”的模式比直接把 after 列写进缓存更稳因为 ROW 格式下某些字段可能没有出现在 after 里。另外删除操作可能需要关联删除多个缓存 key比如商品详情、商品列表、购物车里的商品信息这时候你要根据业务情况把相关的 key 都清掉。5. 生产环境里最常踩的坑我对每个坑的理解和处理方式这部分是全文的精华都是我在真实环境里踩过的。按踩坑频次从高到低排。5.1 位点丢失和重复消费Canal 的位点记录在 meta 文件或 ZooKeeper 里而客户端消费时用的是 Canal 的 batchId ack 机制。你以为已经消费完的数据如果因为连接断开而 rollback消费端会再收到一次。所以消费端逻辑必须设计成天然幂等——重复处理同一条变更数据不能产生副作用。比如更新缓存重复 set 是安全的如果是累加计数重复消费就会出问题。另一个位点相关的问题我之前提过服务器磁盘损坏导致 meta 文件丢失Canal 重启后从最新 binlog 开始拉中间的数据就没了。我的应对是把定期备份 meta 目录写进运维计划同时尽量开启 GTID 模式GTID 定位比文件名加 offset 的方式更抗风险。5.2 大事务引发的消费风暴这是我在真实环境里遇到的最危险的场景。一个批量任务在一个事务里更新了几十万条商品记录binlog 里对应的事件数量几十万Canal 会把这几十万条变更连续吐给客户端。如果客户端消费速度跟不上EventStore 积压内存占用飙升还可能把下游 Redis 打满。我的处理方案是双管齐下消费端把同一个事务的更新合并成批量操作比如把几十万条商品 id 攒成一批一次性批量删除对应缓存 key而不是一条一条删除更重要的是和业务方约定批量变更任务在业务代码层面分批提交一个大事务拆成 1000 条一批的小事务对 MySQL 的压力也小很多。5.3 DDL 事件被忽略表结构变了位置对不上Canal 可以感知 DDL但下游的处理逻辑如果忽略它后果很隐蔽。比如上游给一个表加了字段Canal 继续按旧的列名解析行数据下游拿到的字段列表就可能会错位某些值会落到错误的字段里。我的做法是在消费端专门判断EntryType为 DDL 的情况把 DDL 语句落日志并告警甚至自动触发下游表结构的更新。对于动态字段特别多的业务这个处理是必须的。5.4 主从切换导致的连接中断MySQL 发生主从切换后Canal 原来连接的 master 地址可能变成了只读从库或者 VIP 漂移导致地址变化这时 Canal 会频繁报错。如果 Canal Server 配置的是主机名或固定 IP切换后必须尽快更新。这里 GTID 模式的优势就很明显因为 GTID 是全局事务标识即使连接到了新主库Canal 也能根据 GTID 从正确的位点继续拉取。如果你的 MySQL 环境支持我强烈建议把gtidon开启。5.5 时区问题和时间字段的坑Canal 解析时间字段时如果数据库连接字符集和时区设置不对datetime和timestamp类型解析出来可能会有 8 小时的偏差。datetime本身不包含时区信息MySQL 存的是什么解析出来大概率还是什么但timestamp底层是以 UTC 存储的转换结果和连接的时区设置相关。我处理的方式是在 instance.properties 里显式指定connectionCharset并且在消费端统一把时间字段转换为字符串或Instant避免依赖运行环境的默认时区。5.6 性能调优的边界在哪里Canal 性能瓶颈通常不在 Canal Server 本身而在两处一是主库开启 binlog 后的 IO 压力二是客户端消费速度。当然Canal Server 的内存、EventStore 容量也需要根据数据量预估。常见的调优参数如下参数作用我的建议canal.instance.memory.buffer.sizeEventStore 环形队列可缓存的事件条数默认 16384事件量大的事务建议调大到 65536canal.instance.memory.buffer.memunit每条事件的平均内存占用单位默认 1024canal.instance.batch.sizeServer 向客户端推送的单批条数根据消费端处理能力调整我常用 100~500消费端线程数Client 处理消息的并发度先按 CPU 核心数估算再观察积压情况调整调优的思路不是盲目调大参数而是先看瓶颈在哪。如果 EventStore 积压说明消费端跟不上加消费端线程比加内存更有效如果 MySQL 压力大考虑减小订阅范围或对 binlog 做粗粒度过滤。6. 一次凌晨的 binlog 风暴完整排障链路记录最后用一个真实故障案例收尾它几乎把前面提到的坑都串起来了。那天凌晨我收到告警线上缓存命中率直线下降数据库读负载飙升。第一反应是某个营销活动把热 key 打爆了但查看监控发现MySQL 主库的 binlog 写入速率暴涨Canal 的消费延迟从毫秒级飙升到几分钟。顺着这个线索往下查。先看 Canal Server 日志发现 EventStore 的积压数量在快速上升说明 Canal 拉取速度正常但消费端处理不过来。再看消费端发现它是单线程处理消息每个变更事件都会触发一次 Redis 删除操作。这个组合就是灾难。然后去 MySQL 侧确认是哪类变更导致的事件量暴增。通过SHOW MASTER STATUS拿到位点后用mysqlbinlog工具按时间范围解析 binlog定位到一个大事务运营平台的一个批量改价任务在单个事务里更新了 50 多万条商品记录。处理过程分三步先把消费端从单线程改成多线程同时把同一事务内的变更按表分组合并成批量删除 key 的请求Redis 压力立刻降下来。再把 Canal 的batch.size从 100 调到 500减少网络交互次数提升消费吞吐。最后联系运营团队把批量改价任务从一次性全量提交改成 1000 条一批的小事务提交从源头控制 binlog 风暴。那次之后我做了一个复盘结论只要下游是 Redis 这类对突发热点敏感的系统必须提前评估上游批量变更的峰值并且消费端一定要设计成“批量聚合 多线程并发 幂等”的形态不能靠简单的一条条处理撑过高峰期。Canal 本身是一个很稳定的管道暴雷的往往是下游消费逻辑没有为极端情况做好准备。这也是我始终建议团队自己写消费端的原因——虽然 Adapter 开箱即用但当你要做批量合并、幂等控制、异常回放这些保命操作时自己掌控代码会从容得多。