📚 课程目录第4章 Canal高级特性

4、Canal高级特性：Canal HA、Canal集群、Canal性能调优

这一章，我们聊聊Canal在生产环境里真正能打的东西。说白了，前面几章你学会了怎么搭一个单机Canal，怎么解析Binlog，但到了线上，单点故障怎么办？流量大了扛不住怎么办？嗯，这就是今天要解决的三个核心问题：高可用、集群扩展、性能调优。

我个人习惯把这三件事放在一起讲，因为它们在架构上是联动的。你不可能只做HA不管性能，也不可能集群搭完发现跑得比单机还慢。好，我们一个一个来。

4.1 Canal HA：别让单点搞垮你的数据管道

Canal HA，说白了就是让Canal实例挂了以后能自动切换，保证Binlog消费不中断。我见过不少团队，Canal跑在单机上，运维同学半夜被叫起来重启——说实话，这种体验一次就够了。

核心思路：Canal HA依赖ZooKeeper做分布式协调。多个Canal实例注册到同一个ZK路径下，ZK选主，只有Master干活，Standby standby。Master挂了，ZK自动把Standby提升为Master。

具体怎么做？我直接给你看配置要点：

# canal.properties
canal.zkServers = 192.168.1.10:2181,192.168.1.11:2181,192.168.1.12:2181

# instance.properties
canal.instance.mysql.slaveId = 1234
# 注意：同一个instance的所有Canal节点，slaveId必须不同

这里有个坑，我曾经踩过：slaveId不能重复。如果你两个Canal实例配了同一个slaveId去连MySQL，MySQL会认为是一个Slave在重复注册，直接踢掉一个。嗯，我当时排查了半天，最后发现是配置模板没改。

避坑指南：我曾经在测试环境配HA，ZK连上了，但死活切不过去。后来发现是Canal的instance目录权限问题——Standby节点没有写权限，导致无法创建position文件。记住：HA模式下，所有节点对position存储目录必须有读写权限。

HA的切换流程，我画了张图，你看一眼就明白了：

4.2 Canal集群：横向扩展，扛住百万级Binlog

单机Canal能扛多少？我实测过，一台8C16G的机器，解析MySQL Binlog大概能到 2~3万 TPS。再往上，CPU和网络就成了瓶颈。这时候就需要集群了。

Canal集群不是简单的多实例跑同一个instance——那样会重复消费。Canal的集群模式是分instance的：每个Canal节点负责不同的instance，或者同一个instance的不同分片。

我的经验：集群规模不是越大越好。我见过有人搭了20个节点的Canal集群，结果ZK的选举压力比Binlog解析压力还大。一般来说，3~5个节点足够覆盖大部分场景。

集群部署的架构，我习惯这样分：

节点角色	职责	推荐配置
Admin节点	管理集群元数据，分发配置	2C4G，1~2台
Server节点	实际解析Binlog，推送数据	8C16G，3~5台
ZK节点	协调选举，存储position	4C8G，3台

集群模式下，Canal Admin会统一管理所有Server节点的配置。你想想看，如果每个节点手动改配置，20个节点改一轮，手都酸了。Admin提供了Web界面，改一次，全集群生效。

# canal_admin 配置示例
# application.yml
server:
  port: 8089

canal:
  admin:
    user: admin
    passwd: 123456
  zookeeper:
    hosts: 192.168.1.10:2181,192.168.1.11:2181,192.168.1.12:2181

注意：集群模式下，所有Server节点的系统时间必须同步。我曾经因为NTP没配好，两个节点时间差了30秒，结果ZK选举一直震荡，Master频繁切换。嗯，后来加了chronyd同步，问题解决。

4.3 Canal性能调优：把每一分CPU都用在刀刃上

性能调优这块，我踩过的坑最多。说白了，Canal的性能瓶颈通常不在解析本身，而在网络IO和内存GC。你想想看，Binlog解析是CPU密集型的，但如果你网络带宽不够，或者JVM频繁Full GC，再快的CPU也白搭。

我整理了一份调优清单，你照着检查一遍，基本能解决90%的性能问题：

调整JVM堆内存：建议给Canal分配至少4GB堆内存，-Xms和-Xmx设成一样，避免动态扩容。
优化GC策略：使用G1GC，-XX:+UseG1GC -XX:MaxGCPauseMillis=100。我实测过，G1比CMS的停顿时间更可控。
调整Canal内存缓冲区：canal.instance.memory.buffer.size 默认16384，如果Binlog事件量大，可以翻倍到32768。
控制batch大小：canal.instance.batch.size 建议设为 1024~2048，太大容易OOM，太小吞吐上不去。
开启Netty内存池：canal.server.netty.buffer.pooled = true，减少内存分配开销。

核心参数速查表：

参数名	默认值	推荐值	说明
canal.instance.memory.buffer.size	16384	32768	内存缓冲区大小，单位是事件数
canal.instance.batch.size	1024	2048	每次从MySQL拉取的Binlog事件数
canal.instance.filter.druid.ddl	true	true	过滤DDL语句，减少解析压力
canal.server.netty.buffer.pooled	false	true	开启Netty内存池
canal.instance.tsdb.enable	true	false	关闭时序数据库，减少写入开销

还有一个容易被忽略的点：Binlog过滤。如果你只需要监听几张表，千万别让Canal解析所有表的Binlog。配置白名单，只关注需要的表，性能能提升30%以上。

# instance.properties
# 只监听 db1.t1 和 db2.t2 两张表
canal.instance.filter.regex = db1\\.t1,db2\\.t2

我的调优心得：性能调优不是一次性的。我建议你在上线前做一次压力测试，用Canal自带的性能监控页面观察TPS和延迟。如果发现延迟持续上升，优先检查网络带宽和GC日志。我曾经遇到一个案例，延迟从10ms飙到500ms，最后发现是MySQL的binlog_row_image设置成了FULL，导致Binlog体积暴增。改成MINIMAL后，延迟立刻降回20ms。

最后，送你一张Canal性能调优的全景图，方便你对照排查：

好了，这一章的内容就这些。HA保证你不挂，集群保证你能扛，调优保证你跑得快。这三件事做好了，Canal在生产环境里基本就稳了。