爺青回，canal 1.1.6來了，幾個重要特性和bug修復
剛剛在群里看到消息說，時隔一年，canal 1.1.6正式release了，趕緊上去看看有什麼新特性。
（居然才發佈了6個小時，前排圍觀）
1、什麼是canal
canal [kə’næl]，譯意為水道/管道/溝渠，主要用途是基於 MySQL 數據庫增量日誌解析，提供增量數據 訂閱 和 消費。應該是阿里雲DTS（Data Transfer Service）的開源版本。
如果想了解更多，可以上github上看官方文檔，或者我之前寫過的系列基於canal 1.1.4版本的入門文檔。
2、重要新特性
我們現在生產用的還是1.1.4版本，用得還算穩定，沒有什麼特別大的bug。
這次，趁着升級了兩個版本，看看1.1.5和1.1.6版本有什麼新特性可以值得升級引入。
2.1 MQ發送優化
重點優化MQ發送的性能，單topic最高峰值可支持3~8萬的rps，接近數量級上的性能提升
這是1.1.5中的重要特性優化。
為什麼canal需要搭配MQ使用，甚至重點優化MQ的投遞性能呢？
主要原因是 canal + MQ 可以打造強大的異構存儲體系。
canal訂閱binlog後有兩種模式，一種是直接投遞到一種介質，如mysql，一種是投遞到MQ然後自定義消費。
如果採用投遞到MQ的模式，那麼我們就可以利用MQ進行一份消息多端消費（避免重複拉取binlog對MySQL造成影響），用於構建二級索引ES或者構建緩存Redis等等。
另一方面，投遞mq以後，對於消息的回溯、監控都能提供更好的途徑。
總的來說，canal這個特性優化給 canal + MQ 的模式帶來了更加強大的支持。
2.2 MQ發送特性支持
新增rabbitmQ的MQ發送支持 #2156
支持不同topic設置不同的分區數 #2173
rocketMQ新增tag屬性的定義 #3438
參數配置支持env環境變量 #3450
這是1.1.5中的一個小優化，但是我覺得非常重要。
比如rocketMQ新增tag屬性的定義。實際上在我們的測試環境，就非常需要這個特性。
我們使用rocketMQ的tag做路由，如果業務方自行生產和消費，可以完全根據tag進行路由區分。而從canal訂閱的數據庫變更，1.1.4版本無法直接給消息打tag，業務消費就無法通過tag進行路由。
現在這個特性的優化，正好可以解決這個問題。
2.3 新增Puslar MQ支持
這是1.1.6中的一個小優化，還是非常與時俱進的。
目前的雲原生消息隊列Puslar MQ，憑藉存儲和計算分離的架構在雲原生體系下如日中天，而canal就在最新版本支持了對Puslar MQ的投遞，手動點贊。
3、重要bug修復
3.1 修復gtid模式下位點持久不更新的問題
這是1.1.5中修復的bug。
GTID又叫全局事務ID（Global Transaction ID），是一個已提交事務的編號，並且是一個全局唯一的編號。MySQL5.6版本之後在主從複製類型上新增了GTID複製。
為什麼要引入這個東西呢？
- GTID使用master_auto_position=1代替了基於binlog和position號的主從複製搭建方式，更便於主從複製的搭建。
- GTID可以知道事務在最開始是在哪個實例上提交的。
- GTID方便實現主從之間的failover，再也不用不斷地去找position和binlog 了。
為什麼我特別關注到這個bug的修復呢？
因為我在2020年對canal 1.1.4進行poc的時候，就發現這個bug了，當時還吐槽了一波，233333。
一晃兩年過去了，沒想到在1.1.5中已經修復了，手動點贊。
3.2 修復RDB同步下的關鍵字引起的同步報錯
這是1.1.6中修復的bug。
對於這個bug，也是有點記憶猶新。
當時在莫干山度假，突然早上八點收到線上警報，發現數據同步出現異常。
好在隨身帶了電腦（程序員出遠門必備，sigh~），經過排查後發現，就是一個表結構變更引入的關鍵字導致了同步異常。
往事不堪回首。。。
4、總結
這裡簡單介紹了幾個對我們生產中比較重要的優化和修復，具體更多內容大家可以直接去github上看release note。
總的來說，1.1.5和1.1.6都做了非常多的bug修復和特性優化，還是非常值得升級的。
都看到最後了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜索「阿丸筆記 」第一時間閱讀，回復【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回復【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）
