---

一、canal概念

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

二、canal使用場景

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

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

四、Canal工作原理

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

Mysql主從復(fù)制原理

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

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

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

具體詳細(xì)過程如下：

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

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

binlog中的二進(jìn)制日志

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

binlog格式選擇

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

Canal消費(fèi)方式

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

應(yīng)用實(shí)踐

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

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

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

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

總結(jié)

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

參考：
第一個(gè)

第二個(gè)