测试环境

测试方式

1. 混合的DML场景测试 (模拟业务场景，小事务)
   • 混合2张表的insert、update、delete，包含最大10个bantch的insert、单条update和随机单条delete
2. batch insert场景 (模拟批量场景，大事务)

MQ服务配置层面基本采用默认参数，比如:

1. kafka https://kafka.apache.org/quickstart
2. RocketMQ https://rocketmq.apache.org/docs/quick-start/

Canal的Perf性能数据监控

1. prothemues，https://github.com/alibaba/canal/wiki/Prometheus-QuickStart
2. linux主机监控，比如dstat/top等，关注网络包和cpu利用率

测试总结

性能数据

1. 混合DML场景，同步效率在15k ~ 30k rps (每秒的事务数大概在5k~10k的tps，一个事务会包含至少3条binlog)
2. batch操作场景，同步效率在50k ~ 60k rps
3. rocketmq相比于kafka，大概有30%的性能提升
4. 非flatMessage模式相比于flatMessage模式，大概有30%~60%的性能提升 (调整了默认参数为flatMessage=false)

优化思路

canal-server发送MQ消息，为了保障binlog顺序性考虑，会有串行的代码路径，需要尽可能减少串行路径上的代价，比如序列化、分区散列、flatMessage对象转化等

代码优化点：

1. 针对不开启flatMessage，默认设置canal.instance.memory.rawEntry=true，确保在发送kafka消息阶段不需要做bytes序列化。针对单队列的情况，可以有50%的性能提升
2. 针对开启flatMessage，引入多线程进行protobuf对象的转化到flat对象的过程，减少串行路径，提升会比较明显，可以有近10倍
3. 针对多topic的发送，引入多线程发送机制，减少串行路径，随着topic数量分布可以有倍数上的提升
4. 减少kafka发送端的flush频率，一个getBatchSize在最后进行一次flush阻塞 (之前在flatMessage上每条消息都做了flush)

小tips:

1. 单topic单分区 > 多topic单分区，kafka模式下估计是大batch拆分为了小batch，同时有了proto对象的反序列化开销
2. flatMessage模式，性能普遍比不开启flatMessage模式慢，主要就是proto对象的反序列化开销和小batch的发送成本，后续可以通过更多的topic+分区追回

优化参数

影响性能的几个参数：

1. canal.instance.memory.rawEntry = true (表示是否需要提前做序列化，非flatMessage场景需要设置为true)
2. canal.mq.flatMessage = false (false代表二进制协议，true代表使用json格式，二进制协议有更好的性能)
3. canal.mq.dynamicTopic (动态topic配置定义，可以针对不同表设置不同的topic，在flatMessage模式下可以提升并行效率)
4. canal.mq.partitionsNum/canal.mq.partitionHash (分区配置，对写入性能有反作用，不过可以提升消费端的吞吐)

测试数据

测试的对比项：

1. flatMessage 开启 vs 不开启 (是否涉及数据个是转换，会有一定的转换成本和网络放大问题)
2. 单topic vs 多topic (不同表路由到不同的topic)
3. 单分区 vs 多分区 (表的不同记录路由到不同分区)

名词解读：

1. rps，canal store里消费entry的数量，会包含事务的begin/end事件 + DML事件
2. tps，事务为单位的消费速度

   优化前 (1.1.4版本)

混合DML场景测试

优化后 (1.1.5版本)

Kafka + 混合DML场景测试

Kafka + 单表的batch insert场景测试

RocketMQ + 混合DML场景测试

RocketMQ + 单表的batch insert场景测试