canal启动失败主因是mysql未开binlog或binlog_format非row，须确认log-bin启用、server-id为非零整数、用户具replication slave/client权限，并通过show variables验证log_bin=on且binlog_format=row。
Canal 启动失败：MySQL binlog 未开启或格式不对
Canal 连不上 MySQL，canal.instance.master.address 配置正确但日志报 ERROR c.a.o.c.c.i.CanalInstanceWithSpring - start CannalInstance 或反复重连，大概率是 MySQL 没开 binlog，或格式不是 ROW。
必须确认三件事：
-
my.cnf中已启用log-bin，且server-id是非零整数（如server-id = 1） -
binlog_format = ROW——STATEMENT或MIXED会导致 Canal 解析不出具体字段变更 - MySQL 用户需有
REPLICATION SLAVE和REPLICATION CLIENT权限，不能只给SELECT
验证方式：登录 MySQL 执行 SHOW VARIABLES LIKE 'log_bin'; 和 SHOW VARIABLES LIKE 'binlog_format';，两个都必须返回 ON 和 ROW。
Canal Client 消费时缓存未更新：监听表名/库名大小写或通配符不匹配
Canal Server 日志显示正常拉取 binlog，但业务侧 Redis 没变化，常见原因是 canal.instance.filter.regex 配置错误。
这个正则控制 Canal 推送哪些表的变更，它**区分大小写**，且必须完整匹配「库名.表名」格式。例如：
- 想监听
user_db.users表，要写user_db\.users（注意点号转义） - 监听多个库的用户表：
user_db\.users|order_db\.orders - 写成
user_db.users（没转义点）或users（缺库名）都会静默丢弃事件
另外，MySQL 8.0 默认库名、表名小写存储，但若建表时用了反引号或大小混用（如 `User_DB`.`Users`），正则也得严格对应，否则 Canal 不会推送。
缓存击穿：Canal 更新后读请求仍查到空缓存
Canal 把新数据写进 Redis 了，但前端请求一上来还是穿透到 DB，说明缓存没真正“热”起来 —— 这不是 Canal 的问题，而是读路径没兜住。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
典型场景：用户刚注册（Canal 监听到 INSERT），Redis 写入成功；但紧接着并发查该用户，却因缓存 key 还没加载或被误删，导致大量请求打到 DB。
解决方法不是让 Canal 做更多事，而是补两层防护：
- 在业务读逻辑中加
SETNX+ 过期时间：查缓存为空时，先用SETNX user:123 "loading" EX 3占位，只放行一个线程去查 DB 并回填，其余等待 2–3 秒再重试 - 对高频 key（如首页 banner、用户基础信息）做「空值缓存」：DB 查无结果也写入
user:999 null并设短过期（如 60s），避免重复穿透 - Canal 自身不处理读，所以不要指望它预热缓存；预热动作得由业务主动触发（比如后台发消息通知客户端批量加载）
延迟与乱序：UPDATE 和 DELETE 事件在 Canal 中顺序错乱
Canal 基于 binlog position 顺序消费，但如果你用的是多线程 Canal Client 或下游用了 Kafka/RocketMQ 分区，就可能把同一行记录的 UPDATE 和后续 DELETE 拆到不同线程/分区处理，导致 Redis 先删后更，最终缓存残留旧值。
关键约束只有两个：
- 单个表的变更事件，必须由同一个线程消费（即 Canal Client 不开多线程解析，或 Kafka 按
table_name + primary_key做分区键） - Canal Server 的
canal.instance.memory.buffer.size不能太小（默认 16384），否则 buffer 满了会丢弃旧事件，造成跳变
如果业务对顺序极其敏感（如金融账户余额），建议关闭 Canal 的 batch 模式，设 canal.instance.memory.batch.mode = MEMSIZE 并调大 buffer，宁可慢一点，也不能乱。
Canal 本身不提供强一致保证，它只是把 binlog 变更“尽可能快”地推过去；真正决定一致性的，是你的过滤规则是否精确、消费线程是否保序、以及读路径有没有防击穿设计。这三个地方漏掉任何一个，都可能让“最终一致”变成“迟迟不一致”。
