我们在通过Canal把MySQL的Binlog数据发送到MQ(kafak/rocketmq)时，需要关注mq的顺序性问题。
Binlog本身是有序的，写入到mq之后如何保障顺序，我们需要关注以下三点：
- canal目前支持kafka和rocketmq，本质上都是基于本地文件的方式来支持分区级别的顺序消息，也就是binlog写入mq是可以有一定的顺序性保障，这个保障级别取决于用户的一些参数选择
- canal支持的mq数据集中路由方式：单topic单分区，单topic多分区，多topic单分区，多topic多分区
2.1 canal.mq.dynamicTopic,主要控制是否是单topic还是多topic，针对命中条件的表可以发到表名对应的topic，库名对应的topic，默认的topic
2.2 canal.mq.partitionsNum,canal.mq.PartitionHash,主要控制是否多分区以及分区的partition路由计算，针对命中条件的可以做到按表级分区，pk级分区等 - canal的消费顺序性，主要取决于描述2中的路由选择，举例说明：
3.1 单topic单分区，可以严格保证和binlog一样的顺序性，缺点就是性能比较慢，单分区的性能写入大概在2-3k的tps
3.2 多topic单分区，可以保证表级别的顺序性，一张表或者一个库的所有数据都写入到一个topic的单分区中，可以保证有序性，但针对热点表也会存在写入分区的性能问题
3.3 单topic，多topic的多分区，如果用户选择的是指定table的方式，那和3.2一样，保障的是表级别的顺序性(存在热点表写入分区的性能问题)，如果用户选择的是指定pk hash的方式，那只能保障的是一个pk的多次binlog顺序性 ** pk hash的方式需要业务权衡，这里性能会最好，但如果业务上有pk变更或者对多pk数据有顺序性依赖，就会产生业务处理错乱的情况. 如果有pk变更，pk变更前和变更后的值会落在不同的分区里，业务消费就会有先后顺序的问题，需要注意
