---

一、canal概念

canal是用java開發(fā)的基于數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱&消費的中間件。目前，canal主要支持了MySQL的binlog解析，解析完成后才利用canal client 用來處理獲得的相關(guān)數(shù)據(jù)。（數(shù)據(jù)庫同步需要阿里的otter中間件，基于canal）

二、canal使用場景

（1）中間件的使用——用于監(jiān)聽獲取變更數(shù)據(jù)
阿里otter（阿里用于進行異地數(shù)據(jù)庫之間的同步框架）中間件的一部分，這是原始場景
圖片來源對線JAVA面試

（2）更新緩存
如果有大量的請求發(fā)送到mysql的話，mysql查詢速度慢，QPS上不去，光查mysql可能會癱瘓，那就可以在前面加個緩存，這個緩存有2個主要的問題。一是緩存沒有怎么辦，二是數(shù)據(jù)不一致怎么辦。對于第一個問題查緩存沒有就差mysql，mysql再往緩存中寫一份。對于第二個問題，如果數(shù)據(jù)庫修改了，那就采用異步的方式進行修改，啟動一個canal服務(wù)，監(jiān)控mysql，只要一有變化就同步緩存，這樣mysql和緩存就能達到最終的一致性。
（3）抓取業(yè)務(wù)數(shù)據(jù)新增變化表，用于制作拉鏈表：做拉鏈表是需要有增加時間和修改時間的，需要數(shù)據(jù)今天新增和變化的數(shù)據(jù)，如果時間不全就沒辦法知道哪些是修改的?？梢酝ㄟ^canal把變化的抽到自己的表里，以后數(shù)據(jù)就從這個表出。
（4）取業(yè)務(wù)表的新增變化數(shù)據(jù)，用于制作實時統(tǒng)計

四、Canal工作原理

• canal 模擬 MySQL slave 的交互協(xié)議，偽裝自己為 MySQL slave ，向 MySQL master 發(fā)送dump 協(xié)議。
• MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal )。
• canal 解析 binary log 對象(原始為 byte 流)。

Mysql主從復制原理

MySQL 的主從復制依賴于 binlog ，也就是記錄 MySQL 上的所有變化并以二進制形式保存在磁盤上。復制的過程就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐稀?/p>

這個過程一般是異步的，也就是主庫上執(zhí)行事務(wù)操作的線程不會等待復制 binlog 的線程同步完成。
MySQL 集群的主從復制過程梳理成 3 個階段：

• 寫入 Binlog：主庫寫 binlog 日志，提交事務(wù)，并更新本地存儲數(shù)據(jù)。
• 同步 Binlog：把 binlog 復制到所有從庫上，每個從庫把 binlog 寫到暫存日志中。
• 回放 Binlog：回放 binlog，并更新存儲引擎中的數(shù)據(jù)。

具體詳細過程如下：

• MySQL 主庫在收到客戶端提交事務(wù)的請求之后，會先寫入 binlog，再提交事務(wù)，更新存儲引擎中的數(shù)據(jù)，事務(wù)提交完成后，返回給客戶端“操作成功”的響應(yīng)。
• 從庫會創(chuàng)建一個專門的 I/O 線程，連接主庫的 log dump 線程，來接收主庫的 binlog 日志，再把 binlog 信息寫入 relay log 的中繼日志里，再返回給主庫“復制成功”的響應(yīng)。
• 從庫會創(chuàng)建一個用于回放 binlog 的線程，去讀 relay log 中繼日志，然后回放 binlog 更新存儲引擎中的數(shù)據(jù)，最終實現(xiàn)主從的數(shù)據(jù)一致性。

在完成主從復制之后，你就可以在寫數(shù)據(jù)時只寫主庫，在讀數(shù)據(jù)時只讀從庫，這樣即使寫請求會鎖表或者鎖記錄，也不會影響讀請求的執(zhí)行。

binlog中的二進制日志

mysql的二進制日志記錄了所有的DDL和DML（除了數(shù)據(jù)查詢語句），以事件的形式進行記錄，包含語句執(zhí)行消耗的時間，mysql的二進制日志是事務(wù)安全型的。
??開啟二進制日志大概會有1%的性能損壞。二進制日志有2個主要的使用場景：①mysql的主備復制②數(shù)據(jù)恢復，通過使用mysqlbinlog工具來恢復數(shù)據(jù)（用這個做恢復是備選方案，主方案還是定期快照，定期執(zhí)行腳本導數(shù)據(jù)，其實就是把當前所有數(shù)據(jù)導成insert，這個量少）
??二進制日志包括2類文件：①二進制日志索引文件（后綴為.index）用于記錄所有的二進制文件②二進制日志文件（后綴為.00000*）記錄數(shù)據(jù)庫所有的DDL和DML（除了數(shù)據(jù)查詢語句）

binlog格式選擇

如果只考慮主從復制的話可以用mixed，一般情況下使用statement，遇到幾種特殊情況使用row，同步的話有SQL就行，因為手里有數(shù)據(jù)，前提是有數(shù)據(jù)才能執(zhí)行這個SQL。在大數(shù)據(jù)場景下我們抽取數(shù)據(jù)是用于統(tǒng)計分析，分析的數(shù)據(jù)，如果用statement抽了SQL手里也沒數(shù)據(jù)，不知道執(zhí)行修改哪些，因為沒有數(shù)據(jù)，所以沒辦法分析，所以適合用row，清清楚楚的表明了每一行是什么樣。

Canal消費方式

Canal在偽裝成為目標MySQL的一個Slave節(jié)點后，獲取到來自主節(jié)點的BinaryLog日志內(nèi)容。那么作為BinaryLog消費者該如何使用canal監(jiān)聽得到的內(nèi)容呢。Canal為我們提供了兩種類型的方式，直接消費和投遞。直接消費即使用Canal配套提供的客戶端程序，即時消費Canal的監(jiān)聽內(nèi)容。投遞是指配置指定的MQ類型以及對應(yīng)信息，Canal將會按照BinaryLog的條目投遞到指定的MQ下，再交由MQ為各種消費形式提供數(shù)據(jù)消費。

應(yīng)用實踐

• 監(jiān)聽字段更新

使用Canal對指定的指標表進行監(jiān)聽，對指標表的更新數(shù)據(jù)Binlog進行解析，然后以日志形式記錄。針對每一條數(shù)據(jù)內(nèi)容能夠識別到具體的指標，把當前更新的數(shù)據(jù)信息記錄到庫表中。再按照對應(yīng)的指標更新要求，感知更新日志表的數(shù)據(jù)庫，就能夠確保及時知道指標的更新頻次是否符合預期，指標數(shù)據(jù)每次更新的數(shù)據(jù)內(nèi)容，做到更新頻次可監(jiān)控，更新數(shù)據(jù)變動可追溯。

• 數(shù)據(jù)同步實時化
  為了使數(shù)據(jù)能夠進行實時同步，決定使用Canal接入到外部數(shù)據(jù)庫，然后把Canal監(jiān)聽的BinaryLog接入到新建設(shè)的MySQL庫中，使得兩邊的數(shù)據(jù)庫數(shù)據(jù)同步延遲僅有秒級差異。Canal的接入也使得每日執(zhí)行的同步任務(wù)得以取消，減少了額外的系統(tǒng)維護工作。而且BinaryLog的監(jiān)聽推送對外部數(shù)據(jù)庫性能來說影響較少。

• 增量數(shù)據(jù)投遞消費
  此外，Canal投遞消費能力能夠拓展數(shù)據(jù)增量改動的體現(xiàn)形式。Canal把感知到的數(shù)據(jù)庫變動內(nèi)容投遞到指定的MQ Topic，為后續(xù)的消費途徑提供多樣性。如：Canal訂閱指定數(shù)據(jù)表的變動數(shù)據(jù)投遞到Datahub中，投遞的內(nèi)容就如上面的數(shù)據(jù)結(jié)構(gòu)展示。允許借助Blink計算平臺對數(shù)據(jù)進行感知整合，實現(xiàn)業(yè)務(wù)場景的下聚合統(tǒng)計等實時計算訴求；也能夠開放Datahub的Topic訂閱權(quán)限，把增量數(shù)據(jù)的變動開發(fā)到指定使用者，提供實時數(shù)據(jù)變動推送。
  

總結(jié)

這個cannal與美團中的DTS比較類似，業(yè)務(wù)需求中可能監(jiān)聽表的插入、更新、刪除的操作，然后發(fā)送mafka消息。

參考：
第一個

第二個