爺青回，canal 1.1.6來了，幾個(gè)重要特性和bug修復(fù)
剛剛在群里看到消息說，時(shí)隔一年，canal 1.1.6正式release了，趕緊上去看看有什么新特性。
（居然才發(fā)布了6個(gè)小時(shí)，前排圍觀）
1、什么是canal
canal [k?'n?l]，譯意為水道/管道/溝渠，主要用途是基于 MySQL 數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù) 訂閱 和 消費(fèi)。應(yīng)該是阿里云DTS（Data Transfer Service）的開源版本。
如果想了解更多，可以上github上看官方文檔，或者我之前寫過的系列基于canal 1.1.4版本的入門文檔。
2、重要新特性
我們現(xiàn)在生產(chǎn)用的還是1.1.4版本，用得還算穩(wěn)定，沒有什么特別大的bug。
這次，趁著升級(jí)了兩個(gè)版本，看看1.1.5和1.1.6版本有什么新特性可以值得升級(jí)引入。
2.1 MQ發(fā)送優(yōu)化
重點(diǎn)優(yōu)化MQ發(fā)送的性能，單topic最高峰值可支持3~8萬的rps，接近數(shù)量級(jí)上的性能提升
這是1.1.5中的重要特性優(yōu)化。
為什么canal需要搭配MQ使用，甚至重點(diǎn)優(yōu)化MQ的投遞性能呢？
主要原因是 canal + MQ 可以打造強(qiáng)大的異構(gòu)存儲(chǔ)體系。
canal訂閱binlog后有兩種模式，一種是直接投遞到一種介質(zhì)，如mysql，一種是投遞到MQ然后自定義消費(fèi)。
如果采用投遞到MQ的模式，那么我們就可以利用MQ進(jìn)行一份消息多端消費(fèi)（避免重復(fù)拉取binlog對(duì)MySQL造成影響），用于構(gòu)建二級(jí)索引ES或者構(gòu)建緩存Redis等等。
另一方面，投遞mq以后，對(duì)于消息的回溯、監(jiān)控都能提供更好的途徑。
總的來說，canal這個(gè)特性優(yōu)化給 canal + MQ 的模式帶來了更加強(qiáng)大的支持。
2.2 MQ發(fā)送特性支持
新增rabbitmQ的MQ發(fā)送支持 #2156
支持不同topic設(shè)置不同的分區(qū)數(shù) #2173
rocketMQ新增tag屬性的定義 #3438
參數(shù)配置支持env環(huán)境變量 #3450
這是1.1.5中的一個(gè)小優(yōu)化，但是我覺得非常重要。
比如rocketMQ新增tag屬性的定義。實(shí)際上在我們的測(cè)試環(huán)境，就非常需要這個(gè)特性。
我們使用rocketMQ的tag做路由，如果業(yè)務(wù)方自行生產(chǎn)和消費(fèi)，可以完全根據(jù)tag進(jìn)行路由區(qū)分。而從canal訂閱的數(shù)據(jù)庫變更，1.1.4版本無法直接給消息打tag，業(yè)務(wù)消費(fèi)就無法通過tag進(jìn)行路由。
現(xiàn)在這個(gè)特性的優(yōu)化，正好可以解決這個(gè)問題。
2.3 新增Puslar MQ支持
這是1.1.6中的一個(gè)小優(yōu)化，還是非常與時(shí)俱進(jìn)的。
目前的云原生消息隊(duì)列Puslar MQ，憑借存儲(chǔ)和計(jì)算分離的架構(gòu)在云原生體系下如日中天，而canal就在最新版本支持了對(duì)Puslar MQ的投遞，手動(dòng)點(diǎn)贊。
3、重要bug修復(fù)
3.1?修復(fù)gtid模式下位點(diǎn)持久不更新的問題
這是1.1.5中修復(fù)的bug。
GTID又叫全局事務(wù)ID（Global Transaction ID），是一個(gè)已提交事務(wù)的編號(hào)，并且是一個(gè)全局唯一的編號(hào)。MySQL5.6版本之后在主從復(fù)制類型上新增了GTID復(fù)制。
為什么要引入這個(gè)東西呢？
GTID使用master_auto_position=1代替了基于binlog和position號(hào)的主從復(fù)制搭建方式，更便于主從復(fù)制的搭建。
GTID可以知道事務(wù)在最開始是在哪個(gè)實(shí)例上提交的。
GTID方便實(shí)現(xiàn)主從之間的failover，再也不用不斷地去找position和binlog 了。
為什么我特別關(guān)注到這個(gè)bug的修復(fù)呢？
因?yàn)槲以?020年對(duì)canal 1.1.4進(jìn)行poc的時(shí)候，就發(fā)現(xiàn)這個(gè)bug了，當(dāng)時(shí)還吐槽了一波，233333。
一晃兩年過去了，沒想到在1.1.5中已經(jīng)修復(fù)了，手動(dòng)點(diǎn)贊。
3.2?修復(fù)RDB同步下的關(guān)鍵字引起的同步報(bào)錯(cuò)
這是1.1.6中修復(fù)的bug。
對(duì)于這個(gè)bug，也是有點(diǎn)記憶猶新。
當(dāng)時(shí)在莫干山度假，突然早上八點(diǎn)收到線上警報(bào)，發(fā)現(xiàn)數(shù)據(jù)同步出現(xiàn)異常。
好在隨身帶了電腦（程序員出遠(yuǎn)門必備，sigh~），經(jīng)過排查后發(fā)現(xiàn)，就是一個(gè)表結(jié)構(gòu)變更引入的關(guān)鍵字導(dǎo)致了同步異常。
往事不堪回首。。。
4、總結(jié)
這里簡單介紹了幾個(gè)對(duì)我們生產(chǎn)中比較重要的優(yōu)化和修復(fù)，具體更多內(nèi)容大家可以直接去github上看release note。
總的來說，1.1.5和1.1.6都做了非常多的bug修復(fù)和特性優(yōu)化，還是非常值得升級(jí)的。
往期熱門筆記合集推薦：
原創(chuàng)：阿丸筆記（微信公眾號(hào)：aone_note），歡迎?分享，轉(zhuǎn)載請(qǐng)保留出處。
沒有留言功能的悲傷，掃描下方二維碼「加我」聊些有的沒的吧～