一、性能问题
canal 存在 blocking
从图中可看出。
最高延迟达2.47个小时！！！
binlog的处理带宽速度最高也就8.93MB/s，远低于生成的速度。
dump和slink的blocking也已经达100%了，即存在瓶颈让系统无法正常处理。
TPS(table rows)，最高也就15K左右。
Store的处理也存在积压。
二、原因分析
Store处理存在积压，由于当前使用的是kafka，即可推测binlog消息发送到MQ存在瓶颈。通过监控kafka机器的监控
发现，kakfa机器的带宽和硬盘写入速度，都快达上限了（只有一台kafka）。
dump 和 slink 的 blocking 几乎相等，这说明slink的blocking导致了dump的blocking，即优化的方向还是slink之后的处理（slink和store）。
三、优化配置
Store的处理存在积压，即优化发送kafka的配置 开启压缩，增加批量大小
1 | kafka.compression.type = none → kafka.compression.type = lz4 |
dump线程数调整（当前可用线程数 * 60%）
1 | canal.instance.parser.parallelThreadSize → canal.instance.parser.parallelThreadSize = 5 |
四、优化结果
相同的业务压测TPS情况下，blocking只有20%左右，而且不存在延迟。
自己做的基准测试，binlog处理的带宽可以达到24.8MB/s，TPS(table rows)可以达29.9K（相比优化前，性能翻倍）
五、后续
当前优化后的配置，已经可以解决短时间内（30分钟）千万级交易无延迟（延迟在5秒以内）。
后续，如果量有更高的提升，可能kafka要使用集群。再提高canal机器CPU核数，达到70K，应该是可能的。