企业官网建设流程全解析

想把MySQL的数据实时同步到Redis、Elasticsearch或者消息队列里去，又不想在业务代码里写一堆双写逻辑，更不想为了同步数据去解析那些乱七八糟的binlog格式，那Canal基本是绕不开的一个组件。这是阿里巴巴开源的一套基于MySQL binlog的增量订阅与消费组件，原理上就是把自己伪装成MySQL的slave节点，靠主从复制协议去接收binlog事件，然后解析成结构化数据再推给你想要的地方。这篇文章我会完整记录一次Canal的搭建过程：从MySQL的binlog准备、Canal Server的部署、实例配置，到客户端怎么消费增量数据，最后再把实际踩过的坑和排查方法一并整理出来，希望可以给正在调研或者打算上手Canal的人提供一套能直接照着做的方案。

1. Canal为什么要存在，以及它的核心定位

1.1 从数据同步的痛点说起

业务系统发展到一定阶段，数据往往不会只待在一个MySQL实例里。订单数据要同步到搜索引擎做全文检索，商品数据要同步到Redis做热点缓存，运营要拉实时报表，风控要盯着交易流水，这些场景都需要"数据库一发生变化，下游系统立刻感知到变化"的能力。

但直接去MySQL里做轮询，效率太低，业务也不一定扛得住频繁的扫描查询。业务代码里做双写，侵入性又太强，耦合度极高，一旦主流程失败，数据很容易出现不一致。而且很多老系统根本不可能为了同步需求去改代码。

Canal的核心思路就是绕开业务系统，直接从数据库的日志层面拿数据。它通过模拟MySQL主从复制里slave节点的交互协议，假装自己是一个从库去连接主库，主库正常产生binlog，Canal接收binlog之后做解析，最终再把解析好的数据变更事件交给下游消费。这个过程对业务系统是完全透明的，下游系统不需要关心上游业务怎么写的，只要订阅Canal的消息就行。

1.2 Canal在链路里的位置

从架构上看，Canal处于"数据源"和"数据消费端"之间。数据源这一侧，它只适配MySQL，支持的版本从MySQL 5.6、5.7、8.0到MariaDB都可以，前提是开启了binlog并且使用ROW模式。消费端那一侧，Canal提供了多种对接方式：直接走TCP协议给Java客户端消费，或者对接Kafka、RocketMQ这类消息中间件，也可以输出到日志文件做离线分析。

用一句话来形容Canal在数据链路里的角色：它是一个非常称职的"搬运工"。它不负责决定数据搬到哪去，也不负责下游怎么加工，它只保证把MySQL的binlog变更事件完整、准确、及时地搬运到消费端。这种清晰的边界划分，让Canal在实际项目里非常好落地——谁消费、消费后干什么，全由业务系统自己决定。

1.3 选Canal而不选其他方案的理由

市面上做数据库增量同步的组件不止Canal一个，比如Debezium、Maxwell，还有阿里内部的DTS。我选Canal主要看重三点。

第一，它对MySQL binlog的解析非常成熟。Canal从2014年左右开始对外开源，在阿里巴巴内部经过了大量生产环境的锤炼，对binlog的格式兼容、DDL解析、主从切换处理都做得比较完善。第二，它的部署形态足够轻量。一个Java进程，一份配置文件改一改就能跑起来，不需要依赖外部存储，不像Debezium那样通常还要配合Kafka Connect框架一起使用。第三，它的消费方式灵活，既支持TCP直连也支持消息队列，很多中小团队最需要的就是这种"少一点中间环节"的方案。

2. 搭建Canal之前，先把MySQL这头的基础打牢

2.1 启动增量数据的第一步：打开binlog

Canal能不能工作，前提条件是MySQL必须开启binlog，而且日志格式必须设置成ROW。这个配置属于MySQL的必选项，写在my.cnf或者my.ini里。

[mysqld] log-bin=mysql-bin binlog_format=ROW binlog_row_image=FULL server-id=1

这里逐个解释一下这几个参数的作用。log-bin=mysql-bin是开启binlog并设置日志文件的前缀，后面的序号由MySQL自动管理。binlog_format=ROW表示让MySQL记录"每一行数据是怎么变的"，只有ROW模式才能拿到完整的变更前后值，这也是Canal解析的数据基础。binlog_row_image=FULL确保每行变更都记录全部字段的前后值，如果设置成MINIMAL，某些情况下只有被修改的字段有值，增量数据就不完整了。server-id必须设置，而且不能和复制拓扑里的其他节点冲突，Canal作为伪从库连接时也会用到它。

改完之后重启MySQL，然后执行：

SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format';

看到结果分别是ON和ROW，就说明binlog已经正常开启了。

2.2 为Canal单独创建一个同步账号

Canal要伪装成从库去拉取binlog，所以它需要一个数据库账号，这个账号不需要业务表的任何读写权限，但必须赋予复制相关的权限。我习惯单独创建账号，不跟业务账号混用，这样以后排查问题也清晰。

CREATE USER 'canal'@'%' IDENTIFIED BY 'canal_passwd'; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%'; FLUSH PRIVILEGES;

SELECT权限是Canal在一些场景下需要回查表结构用的，REPLICATION SLAVE和REPLICATION CLIENT分别是拉取binlog和查看主库状态所需的权限。注意控制好账号的网段限制，生产环境最好把%换成实际部署Canal机器的IP。

2.3 确认Canal要监控哪张表

Canal在解析binlog时，默认会订阅整个实例下所有库所有表的变化，但实际生产里我们很少需要全实例的数据，通常只关心某一两个业务库，甚至只关心某几张表。这种过滤可以在Canal的实例配置文件里做，不需要去MySQL端设置，后面我会详细讲过滤规则的写法。

这里要强调一个细节：binlog是实例级的，只要MySQL开启了ROW模式的binlog，这个实例下所有库的变更都会被记录。Canal拿到这些日志后，再根据自己的配置决定哪些数据需要下发、哪些可以丢掉。所以从数据安全角度考虑，binlog会带来一定的磁盘空间增长，开启之前要预估好增长速度，尤其是做表结构变更、大批量update的时候，ROW模式产生的binlog体积会明显变大。

2.4 消费端基础设施的选择

Canal解析出来的增量数据，最终要交给下游。下游用哪套方式消费，决定了我需要在搭建前准备什么基础设施。

如果业务是Java技术栈，下游需要的是同步接口调用，可以直接用Canal自带的TCP模式，客户端通过CanalConnector连接Canal Server，Push模式消费增量消息。这种模式最简单，不需要额外引入消息队列。但如果下游有多个系统都要消费同一份增量数据，或者想利用消息队列的重试、堆积能力，那Kafka或者RocketMQ会更合适。我在实际项目中大多数情况走Kafka，因为公司已有的消息链路基本都是Kafka，接入成本低，而且Canal对Kafka的适配做得很好，支持自动创建topic、分区顺序保证这些关键能力。

版本选择方面，我推荐用1.1.x系列，比如1.1.7。这个版本对MySQL 8.0的支持比较稳定，也支持了自定义时间戳、同步进度回调等功能，小版本迭代过程中的坑相对更少。

3. Canal Server的部署和配置

3.1 准备好运行环境

Canal Server本身是一个Java应用，官方提供了解压即用的发行包，也提供了Docker镜像。我优先推荐用发行包部署，部署过程中可以看到完整的日志输出，出问题也更容易定位。运行环境需要JDK 1.8及以上，我一般用OpenJDK 8，内存至少给2G，因为Canal在解析大事务、大批量binlog时会有比较大的内存占用。

下载的时候要注意选择canal.deployer-1.1.7.tar.gz，不要下成canal.adapter或者canal.admin，admin是Web管理台，adapter是配合做异构同步的适配器，我们这里只需要最核心的deployer。

解压之后目录结构大概是这样的：

canal.deployer-1.1.7/ ├── bin ├── conf │ ├── canal.properties │ ├── logback.xml │ ├── spring │ │ └── file-instance.xml │ └── example │ └── instance.properties └── lib

conf目录下的canal.properties是Canal Server的全局配置，example目录下的instance.properties是具体某个数据采集实例的配置。Canal Server可以同时运行多个instance，每个instance对应一个MySQL数据源。

3.2 canal.properties：Server级别的关键配置

先看canal.properties，用编辑器打开后，重点需要关心三类配置。

第一类是服务端口和模式。默认情况下Canal会同时开启两个端口，canal.port=11111是TCP消费端口，客户端通过这个端口连接；canal.admin.port=11110是管理端口。如果走Kafka模式，canal.serverMode=Kafka，这时候TCP端口就不具备实际消费意义了。

第二类是注册中心相关的配置。1.1.x版本的Canal把instance的配置信息抽象成了MetaManager，不管是不是集群模式，都需要指定注册中心的实现类。如果只是单机部署，用默认的MemoryMetaManager就行；如果需要多机共享配置，可以放在ZooKeeper里。

第三类是消费端对接配置。走Kafka模式时，需要告诉Canal Kafka的地址、topic的命名规则、分区数等。这些配置有的写在全局，有的可以在instance里覆盖。

下面是一个走Kafka模式的最小化配置：

canal.serverMode = kafka canal.port = 11111 canal.zkServers = canal.instance.global.spring.xml = classpath:spring/default-instance.xml canal.mq.servers = 127.0.0.1:9092 canal.mq.producerGroup = canal_group canal.mq.flatMessage = true

canal.mq.flatMessage = true这部分要注意，它决定了消息体的编码格式。true的时候Canal会把解析出的数据转成扁平化的JSON字符串，生产消费都很直观，适合大多数场景；false的时候会走protobuf序列化格式，体积更小但消费端需要额外做反序列化，除非对性能特别敏感，否则我建议保持true。

3.3 instance.properties：采集实例的完整配置

instance.properties是整个Canal配置里最需要小心对待的文件，它决定了Canal从哪个MySQL实例采集数据、用什么账号登录、过滤哪些表、从什么位点开始消费。

# MySQL地址 canal.instance.master.address = 127.0.0.1:3306 # binlog日志位点 canal.instance.master.journal.name = canal.instance.master.position = canal.instance.master.timestamp = # 数据库账号 canal.instance.dbUsername = canal canal.instance.dbPassword = canal_passwd # 过滤规则 canal.instance.filter.regex = test\\.user.* canal.instance.filter.black.regex = # 表结构缓存 canal.instance.parser.support.ddl = true

master.address是MySQL主库的地址和端口，这里要注意Canal连接的是主库还是从库。如果只是想采集数据，连接从库也可以，毕竟从库同样接收binlog并以相同的格式写入本地文件。但是如果从库存在复制延迟，那Canal拿到的变更就会延后。我的习惯是：同步业务要求实时性高就直连主库，只做备份或者实时性不敏感的再考虑从库。

master.position是位点配置，如果这里留空，Canal启动后会从MySQL当前最新的binlog位点开始消费。但实际生产环境往往会遇到"存量数据已经存在，只希望采集从部署时刻之后的增量"的场景，这种场景留空就足够了。如果遇到"Canal之前挂掉了，需要从某个之前消费到的位置继续"的场景，就要手动指定journal.name和position，这两个值可以从MySQL执行SHOW MASTER STATUS拿到。

过滤规则canal.instance.filter.regex的语法是Schema名加表名，中间用\\.分隔，支持通配符。多张表用逗号分隔，比如：

canal.instance.filter.regex = test\\.user, order\\..*, goods\\.sku

表示监听test库下的user表、order库下的所有表、goods库下的sku表。如果只想要一张表，一定要写清楚完整路径，否则过滤太宽会把不需要的表数据也拉进来。

3.4 启动Canal Server

配置完成后，就可以启动部署了。启动命令在bin目录下，Linux环境执行：

sh bin/startup.sh

启动过程会创建一个后台守护进程，进程日志默认写在logs/canal/canal.log里，每个instance的日志写在logs/example/example.log里。启动完第一步不是急着看数据有没有推送，而是先确认两件事。第一看canal.log里有没有报错，正常启动会打印Canal启动完成、端口监听的记录。第二看example.log里有没有出现"success to load binlog position"之类的信息，这说明Canal已经成功找到位点、开始伪装成从库拉取binlog了。

如果启动后日志里出现连接超时、认证失败，基本就是MySQL地址、账号权限或者网络不通的问题，直接用客户端工具连一下MySQL验证即可。

4. 客户端接入：把增量数据真正用起来

4.1 TCP模式下的Java客户端写法和消息结构

Canal最容易上手的使用方式是TCP直连，适合增量数据量不大、下游逻辑不复杂的Java应用。

CanalConnector connector = CanalConnectors.newSingleConnector( new InetSocketAddress("127.0.0.1", 11111), "example", "", ""); connector.connect(); connector.subscribe("test\\\\.user.*"); while (running) { Message message = connector.getWithoutAck(100, 1000); long batchId = message.getId(); if (batchId == -1 || message.getEntries().isEmpty()) { Thread.sleep(1000); continue; } for (CanalEntry.Entry entry : message.getEntries()) { if (entry.getEntryType() == CanalEntry.EntryType.ROWDATA) { CanalEntry.RowChange rowChange = CanalEntry.RowChange.parseFrom(entry.getStoreValue()); System.out.printf("table:%s, event:%s%n", entry.getHeader().getTableName(), rowChange.getEventType()); } } connector.ack(batchId); } connector.disconnect();

这段代码里的核心流程是connect建立连接、subscribe订阅感兴趣的表、循环调用getWithoutAck批量获取数据，处理完后再调用ack确认消费。getWithoutAck的第二个参数是超时时间，意思是最多阻塞多久返回一批数据，这样循环里不至于空转太频繁。

这里必须强调ack和rollback的用法。如果一批数据处理到一半失败了，不要调用ack，应该调用connector.rollback(batchId)，Canal会把这一批数据重新投递。这保证了消息的"至少一次"语义，也就是说，消费端要做好幂等处理，因为同一个事件在异常重试场景下可能会收到两遍。

消息结构里最关键的类是CanalEntry.RowChange，它包含了事件类型、表名，以及变更前后每一列的值。列的数据放在RowData里，beforeColumns是修改前的快照，afterColumns是修改后的快照，通过遍历这两组列再按列名拼装，就能还原出完整的数据变更。

4.2 消息格式的两种选择

前面提到flatMessage设为true时，Kafka里的消息体就是一个扁平的JSON字符串。这是我首推的方式，因为消费端完全不需要引入Canal的客户端依赖，任何语言都能消费。消息体长这个样：

{ "data": [ { "id": 102, "name": "测试商品", "price": 19.9 } ], "database": "shop", "es": 1710146807000, "id": 6, "isDdl": false, "old": [ { "price": 9.9 } ], "pkNames": ["id"], "sql": "", "table": "product", "ts": 1710146809000, "type": "UPDATE" }

字段含义比较直观：type是事件类型，database和table指明来源，data是当前数据，old是变更前的旧值，pkNames是主键字段列表，es和ts分别表示事件发生时间和Canal处理时间。

消费端拿到这条消息，判断type是INSERT、UPDATE还是DELETE，再结合主键去更新Redis里的缓存或者调用搜索引擎的更新接口，一套简易的实时同步就通了。

4.3 Kafka模式下从零开始消费

走Kafka模式时，Canal Server启动过程中会自动在建好的topic目录下创建分区，并开始推送消息。消费端只需要按标准的Kafka消费组来订阅那个topic。

@Component public class CanalKafkaConsumer { @KafkaListener(topics = "example_product", groupId = "canal-demo") public void onMessage(String message) { JSONObject json = JSON.parseObject(message); String type = json.getString("type"); JSONArray data = json.getJSONArray("data"); if ("INSERT".equals(type) || "UPDATE".equals(type)) { for (int i = 0; i < data.size(); i++) { JSONObject row = data.getJSONObject(i); String key = "product:" + row.getString("id"); redisTemplate.opsForValue().set(key, row.toJSONString()); } } else if ("DELETE".equals(type)) { for (int i = 0; i < data.size(); i++) { JSONObject row = data.getJSONObject(i); String key = "product:" + row.getString("id"); redisTemplate.delete(key); } } } }

这里有几个容易忽视的点。Canal投递到Kafka时，是按pkNames里的字段做分区key的，所以同一行数据的变化都会进同一个分区，消费端读取时天然能保证单行数据的顺序。如果有跨行的事务需求，比如同一个事务里改了多张表，Kafka模式下这些条目虽然带着相同的事务ID，但投递到不同分区后无法保证读取顺序，这种场景就需要在消费端自己根据事务ID做聚合，不过大多数同步场景不会涉及这么苛刻的要求。

另外记得，Kafka消费组里的消费者数量最好不要超过topic的分区数，否则多出来的消费者会一直处于空闲状态。Canal创建topic时默认分区数是canal.mq.partitions参数指定的值，如果消费TPS要求高，把这个值调大一些就可以了。

4.4 通用同步抽象：一套写好的消费模板

看多了同步场景之后，你会发现不管下游是Redis、ES还是别的存储，消费逻辑都可以抽象成一个模板：解析消息类型，取出主键，取出业务字段，执行相应的更新动作。我自己在项目里习惯把消费模板做成一个统一的接口，每个同步目标只实现自己的处理器。

比如定义一个SyncHandler接口，包含onInsert、onUpdate、onDelete三个方法，每个下游系统的适配器实现这些方法。这样当需要新增一个同步目标时，不需要改Canal的接入代码，只需要增加一个新的Handler实现类。这种设计看起来多写了几个类，但长期维护的收益非常大，尤其是Canal存量表很多、下游系统更多的时候，一套模板能避免大量重复代码。

5. 生产环境里最容易踩的那些坑

5.1 binlog模式不对导致解析报错

经常遇到的情况是MySQL已经跑了一段时间，binlog_format还是默认的STATEMENT或者MIXED模式，Canal启动后会报类似canal parse error或者解析出的数据与预期不符。排查方法就是回MySQL去看当前binlog格式，如果格式不是ROW，单独改binlog_format=ROW还不够，需要让新配置对所有后续连接都生效，并且确认Canal连接的会话用的确实是ROW。改完配置文件后，重启MySQL服务，再确认一遍当前值。

这里还要注意，即使binlog_format改成了ROW，之前已经生成的binlog文件依然是旧格式，Canal如果从旧的位点开始消费，依然可能解析失败。所以切换格式之后，最好是清空Canal的消费位点，让它从当前最新的binlog开始，而不是从旧位点追。

5.2 位点丢失和数据重复

Canal的位点管理存在内存里，也支持配置持久化。如果Canal进程突然宕机，重启后如果用的是默认位点管理，它可能会从内存记录的最后位点继续；但如果配置的是从当前最新位点消费，那就有可能在宕机期间漏掉一部分数据。

解决思路有两个方向。一是在Canal端开启位点定时持久化，把位点信息写到文件中，这样重启后能从文件恢复；二是从消费端兜底，因为Canal给出的是至少一次的消费语义，消费端只要保证处理逻辑幂等，即使偶发重复数据也不会造成大问题。我在实际生产里是两种同时做：Canal端开启持久化，消费端每个处理逻辑都设计成按主键幂等。

5.3 大事务导致的内存压力

ROW模式下，一个事务里update了一百万行，binlog就会有一百万行的变更记录。Canal拿到这个大事务时，会先解析并暂存在内存里，再批量投递到下游。如果事务特别大，Canal JVM的堆内存设置不够，会出现明显的Full GC甚至OOM。

对这种场景，常规手段是调大Canal的JVM内存，JVM参数在bin/startup.sh里通过JAVA_OPTS指定。此外，尽量不要在业务高峰期做超大批量的update或delete操作，从源头控制binlog的增长速度。如果历史数据有大量变更要做，建议拆批执行，每批几千行，既减轻MySQL的压力也减轻Canal的负担。

5.4 DDL变更对同步链路的影响

Canal默认会把DDL语句也发布到消费端，比如ALTER TABLE、CREATE TABLE等。在flatMessage模式下，DDL消息里isDdl字段是true，data字段为空，sql字段会带着完整的DDL语句。如果消费端没有对DDL做处理，按正常数据消息的逻辑去解析就会出错或者空指针。

我处理DDL的原则很简单：如果下游是Redis这类缓存，DDL消息直接忽略掉，因为缓存结构是独立的，业务代码自己控制结构变更；如果下游是ES这类需要定期对齐数据库表结构的系统，DDL消息需要走一个告警或者手工处理的通道，避免数据库表结构改了、ES mapping没跟上导致后续数据写入失败。

5.5 主从切换后的位点适配

MySQL做高可用切换后，原来的主库变成了从库，新的主库上Canal之前消费到的binlog文件名和位点可能对不上，导致Canal拿到新主库上不存在的位点信息。此时最稳妥的处理是让Canal重新从新主库的最新位点开始消费，代价是切换期间产生的增量数据会丢失。

对增量同步链路来说，"切换期间的少量丢失"在有些场景可以接受，但有些场景不行。如果业务对完整性要求极高，建议在MySQL高可用切换前，先把Canal进程停掉，等主从切换完成、新主库稳定后，再配置新主库地址和最新位点，重新启动Canal。这样丢失窗口只出现在Canal停止到新主库就绪之间的时间段。

6. 一次完整的实战复盘：从建库到Redis双写缓存

6.1 业务背景和整体目标

之前有一个电商项目，商品表存在MySQL里，redis里存放商品详情缓存。最初的做法是业务代码里修改商品时同步更新Redis缓存，看起来简单，但后来加了多个修改入口之后发现总有漏掉的地方，缓存和数据库经常不一致。于是决定引入Canal做最终的兜底同步：任何表数据变更，最终都会通过Canal同步到Redis，所有业务方不需要再关心缓存更新，只管写数据库。

6.2 表结构和链路配置

商品表shop.product，核心字段包括id、name、price、stock、status。目标：把这张表的实时变化同步进Redis，key设计为product:{id}，value为商品JSON。

MySQL侧确认binlog开启且是ROW模式，创建canal账号。Canal Server配置一个instance，filter设置成shop\\.product，消费模式走Kafka，topic命名为canal-product-topic，flatMessage开启。消费程序是Spring Boot应用，监听Kafka消息，根据type更新Redis。

6.3 实际运行效果和观察

启动后，我在数据库做了一次update操作，把某个商品价格从19.9改成29.9，大概几百毫秒内Redis里的商品缓存就变成了新值。连续做了insert、update、delete三组测试，Redis里的数据都跟着正确变化。确认链路通之后，再观察topic的消息上报，确认每个操作都对应一条消息，消息里的数据都完整。

这套链路上线后的收益很明显：业务方删掉了几处手动更新缓存的代码，减少了业务逻辑和缓存逻辑的耦合；数据变化后，不管是从后台系统改的、定时任务改的、还是运营手工在数据库改的，只要写进MySQL，缓存最终都会同步。这就是增量订阅组件的价值所在。

6.4 回顾搭建过程中的决策

回看这个项目，有几个决策值得记录。为什么会先把消息打进Kafka而不是直接TCP给消费程序？因为考虑到以后可能不止一个下游系统需要这些变更，Kafka做成一个独立的数据管道，未来接ES、接数仓都不用改上游。为什么flatMessage用true而不是protobuf？因为消费端和CanalServer不是同一套版本也没关系，拿JSON自己解析更灵活。这些决策本身没有绝对的对错，关键是要符合自己的业务预期。

7. 消费端的进阶技巧和设计建议

7.1 幂等设计怎么做最省心

Canal的消费语义决定了数据可能重复，所以消费端一定要做幂等。我的做法是给每条处理逻辑都定义一个业务主键，更新Redis时直接用这个主键设值，天然幂等；更新数据库时先查再更或者用ON DUPLICATE KEY UPDATE。总之，不要假设每条消息只会来一次。

7.2 压测时关注哪些指标

搭建完成后，最好做一轮简单的压测来评估链路能力。需要关注三个指标：一是Canal Server的吞吐量，单位时间内处理了多少binlog事件；二是Kafka消费端Lag，确认消费能力有没有成为瓶颈；三是同步端到端延迟，从数据库落库到下游消费完成的时延。这三个指标都能在Canal日志、Kafka监控和消费程序的日志里找到。

7.3 通用同步框架的扩展路径

Canal本身只做增量订阅这一件事，但如果想构建一套完整的异构数据同步平台，还需要补齐几个模块：元数据管理、同步任务配置、监控告警、全量迁移工具。Canal社区的开源方案里常搭配Canal Adapter做异构同步，比如把数据同步到ES、HBase等，但我更建议按需组合：简单的场景用Canal加Kafka就够了，复杂场景再考虑引入Adapter。

8. 写在最后：个人实操经验小结

Canal给我的感觉一直是一个"部署简单但细节很多"的组件。部署本身半小时就能跑通，但真正决定链路稳不稳的，全在对位点、数据格式、幂等和异常处理这几个细节的把握上。这里分享几点我在实际项目里验证过的建议：MySQL的binlog格式一定提前确认是ROW，Canal账号权限给到位，先做小范围表测试、连通后再扩展范围；消费端务必设计好幂等，宁可做得保守一些；消息格式优先选flatMessage，运维和调试都省心；测试阶段养成定期查看canal.log和instance日志的习惯，很多问题是慢慢积累而不是突然爆发的。

对于刚接触Canal的人，我的建议是先从一个小而完整的场景入手，比如只同步一张商品表到Redis，把整条链路跑通、把消息格式看明白，再逐步扩展到更多表和下游系统。这样即使遇到问题，排查范围也是可控的。增量订阅这件事做得好，能让业务系统省掉大量重复代码，也让数据一致性有了一个兜底保障；做得不好，反而会引入新的故障点。所以每一条配置、每一个消费逻辑，都值得你在上线前多想一步。