這是學習筆記的第 2190篇文章
讀完需要
分鐘
速讀僅需7分鐘
關於Maxwell和Canal的選型和規劃，之前在團隊內部也討論過幾次，從功能和長期的支持，定製方面，似乎哪個方面都不是很好比較，畢竟根據每個企業的特點，都有難以取捨的痛。
一般說要比較，基本都會拿出這幅圖來（數據帶有主觀特點，僅供參考）
我們在這個基礎上做些補充。
首先對於這個工具的定位，我們如果是主要基於數據流轉來作為虛擬從庫這樣一個組件，其實選擇Maxwell和Canal的差別會比較明顯。
Maxwell的定位基本上一句話就能說清楚，MySQL+Kafka，如果是基於MySQL和Kafka組合的技術棧，Maxwell無疑是一種可直接上手的工具，基本不需要複雜的配置即可跑通一個demo,快速開始測試,換句話說Maxwell部署很簡單，上手簡單，跑通一個完整的測試全然沒有問題，對於缺乏基礎建設，短時間內需要快速迭代的項目和公司比較合適。
Canal的部署相對來說要複雜許多，對於開發側的要求較高，有兩個值得一提的參考點，一個是bootstrap,對於數據初始化來說，這是一個缺失，和Canal這個工具本身的定位有關，第二個是數據落地，得自己寫客戶端，當然除此之外，在服務高可用，文檔，數據分區，自帶圖形管理工具方面，Canal確實有自身的優勢，而且據說產品內部版本已經對接了商業數據庫側。對於大中型的項目，具有團隊開發優勢的項目和公司來說，可以考慮，或者可以作為自造輪子的參考。
這幾天看了下兩個開源項目相關的代碼，有了更進一層的認識。GitHub的流行度是一個風向標，
從這個流行度來看，兩個項目的量級確實差別挺大，一方面阿里有自身的開源號召力，Maxwell在這個數據面前略顯遜色。
不過從代碼層面來看，逐步理解了這個差異，首先關於MySQL協議的Java實現，這個整個工具的核心部分，在Canal中都是自下而上都實現了，而Maxwell中翻了一圈代碼，竟然沒有，發現是在另外一個開源項目mysql-binlog-connector-java中，這個項目的協議實現很精巧，對於理解協議層的一些細節很有幫助。
當然從更細一層來說，Canal是模擬MySQL Slave，主動從Master端拉取日誌數據。而mysql-binlog-connector是一個解析庫，它有兩種模式：BinaryLogFileReader日誌讀取模式，和BinaryLogClient客戶端訪問模式，在實現方式上更加靈活，而且BinaryLogFileReader這個部分的實現算是一個殺手級特性，如果規劃了binlog集市，在這個基礎之上簡直如虎添翼。
Maxwell還有什麼細節，它基於C3P0連接池，所以在Slave端會看到有幾個複製相關的會話，在測試框架部分採用了TestNG的開源項目，在數據落地部分，支持的目標端非常豐富，Redis，Kafka，Kinesis，在數據接入層面的功能非常完善，目前看沒有後端的功能支持。
Canal的實現是前後端組合，還包含一個子項目是平臺化管理入口，它對接的後端更多是基於自身的技術棧體系，把整個鏈路能夠打通。
對於我們當前的狀態來說，我覺得接入Maxwell能夠跑通整個數據鏈路，而且至少在Virtual Slave這一個技術棧上面來說，它是相對技術獨立，可以做一些相關的定製工作的，從絕大多數公司的情況來說也是如此，畢竟數據庫到大數據的數據流建設相對是隔離的，彼此上下游的建設能夠互相映襯，如果目標足夠統一，集中優勢，選擇Canal才是一種長期的策略。
去IOE or Not?
拉里·佩奇（Larry Page）的偉大歸來
《吊打面試官》系列-Redis基礎
唯一ID生成算法剖析，看看這篇就夠了
關於大數據運維能力的一些思考
DBA菜鳥的進化簡史：不忘初心，記工作中踩過的三個坑
-
美女主持直播,被突發意外打斷!灣區網友卻高喊: 我懂!超甜
