我們在通過Canal把MySQL的Binlog數(shù)據(jù)發(fā)送到MQ(kafak/rocketmq)時(shí)扇单，需要關(guān)注mq的順序性問題。
Binlog本身是有序的践盼，寫入到mq之后如何保障順序肄程，我們需要關(guān)注以下三點(diǎn)：
- canal目前支持kafka和rocketmq鲜侥，本質(zhì)上都是基于本地文件的方式來支持分區(qū)級別的順序消息，也就是binlog寫入mq是可以有一定的順序性保障，這個(gè)保障級別取決于用戶的一些參數(shù)選擇
- canal支持的mq數(shù)據(jù)集中路由方式：單topic單分區(qū)互墓，單topic多分區(qū)豆挽，多topic單分區(qū)膛檀，多topic多分區(qū)
2.1 canal.mq.dynamicTopic,主要控制是否是單topic還是多topic，針對命中條件的表可以發(fā)到表名對應(yīng)的topic花鹅，庫名對應(yīng)的topic，默認(rèn)的topic
2.2 canal.mq.partitionsNum,canal.mq.PartitionHash,主要控制是否多分區(qū)以及分區(qū)的partition路由計(jì)算之景，針對命中條件的可以做到按表級分區(qū)，pk級分區(qū)等 - canal的消費(fèi)順序性，主要取決于描述2中的路由選擇刻帚，舉例說明：
3.1 單topic單分區(qū)，可以嚴(yán)格保證和binlog一樣的順序性崇众，缺點(diǎn)就是性能比較慢幔睬，單分區(qū)的性能寫入大概在2-3k的tps
3.2 多topic單分區(qū)，可以保證表級別的順序性赦抖，一張表或者一個(gè)庫的所有數(shù)據(jù)都寫入到一個(gè)topic的單分區(qū)中摹芙，可以保證有序性宛瞄，但針對熱點(diǎn)表也會(huì)存在寫入分區(qū)的性能問題
3.3 單topic，多topic的多分區(qū)匆帚，如果用戶選擇的是指定table的方式颜矿，那和3.2一樣，保障的是表級別的順序性(存在熱點(diǎn)表寫入分區(qū)的性能問題)柄瑰，如果用戶選擇的是指定pk hash的方式巡语，那只能保障的是一個(gè)pk的多次binlog順序性 ** pk hash的方式需要業(yè)務(wù)權(quán)衡翎蹈，這里性能會(huì)最好，但如果業(yè)務(wù)上有pk變更或者對多pk數(shù)據(jù)有順序性依賴男公，就會(huì)產(chǎn)生業(yè)務(wù)處理錯(cuò)亂的情況. 如果有pk變更荤堪，pk變更前和變更后的值會(huì)落在不同的分區(qū)里，業(yè)務(wù)消費(fèi)就會(huì)有先后順序的問題，需要注意
