目錄前言canal介紹canal工作原理mysql配置canal架構canal-ha架構canal應用場景總結前言

前兩篇文章老顧介紹了基於binlog日誌，同步多機房的mysql；推薦使用canal元件；今天老顧就來介紹一下canal基本原理，以及一些常用的使用場景。

canal介紹

Canal是阿里開源的一款基於Mysql資料庫binlog的增量訂閱和消費元件，透過它可以訂閱資料庫的binlog日誌，然後進行一些資料消費，如資料映象、資料異構、資料索引、快取更新等。相對於訊息佇列，透過這種機制可以實現資料的有序化和一致性。

github地址：https://github.com/alibaba/canal

完整wiki地址：https://github.com/alibaba/canal/wiki

Canal工作原理

原理很簡單：

Canal模擬MySQL的slave的互動協議，偽裝成mysql slave，並將轉發協議傳送到MySQL Master伺服器。MySQL Master接收到儲存請求並開始將二進位制日誌推送到slave（即canal）。Canal將二進位制日誌物件解析為自己的資料型別（原始位元組流）

如圖所示：

mysql配置

基於binlog則需要開啟mysql的binlog日誌

（1）檢視當前mysql是否開啟binlog模式。

SHOW VARIABLES LIKE '%log_bin%'

（2）修改/etc/my.cnf 需要開啟binlog模式。

[mysqld]log-bin=mysql-binbinlog-format=ROWserver_id=1

修改完成之後，重啟mysqld的服務。

(3) 進入mysql

mysql -h localhost -u root -p

(4) 建立賬號 用於測試使用

使用root賬號建立使用者並授予許可權

create user canal@'%' IDENTIFIED by 'canal';GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT,SUPER ON *.* TO 'canal'@'%';FLUSH PRIVILEGES;

Canal架構

server代表一個canal執行例項，對應於一個jvm

instance對應於一個數據佇列

instance模組：

eventParser (資料來源接入，模擬slave協議和master進行互動，協議解析)eventSink (Parser和Store連結器，進行資料過濾，加工，分發的工作)eventStore (資料儲存)metaManager (增量訂閱&消費資訊管理器)Canal-HA機制

canal是支援HA的，其實現機制是依賴zookeeper來實現的，用到的特性有watcher和EPHEMERAL節點(和session生命週期繫結)，與HDFS的HA類似。

canal的ha分為兩部分，canal server和canal client分別有對應的ha實現

canal server: 為了減少對mysql dump的請求，不同server上的instance(不同server上的相同instance)要求同一時間只能有一個處於running，其他的處於standby狀態(standby是instance的狀態)。canal client: 為了保證有序性，一份instance同一時間只能由一個canal client進行get/ack/rollback操作，否則客戶端接收無法保證有序。

server ha的架構圖如下：

大致步驟：

canal server要啟動某個canal instance時都先向zookeeper_進行一次嘗試啟動判斷_(實現：建立EPHEMERAL節點，誰建立成功就允許誰啟動)建立zookeeper節點成功後，對應的canal server就啟動對應的canal instance，沒有建立成功的canal instance就會處於standby狀態。一旦zookeeper發現canal server A建立的instance節點消失後，立即通知其他的canal server再次進行步驟1的操作，重新選出一個canal server啟動instance。canal client每次進行connect時，會首先向zookeeper詢問當前是誰啟動了canal instance，然後和其建立連結，一旦連結不可用，會重新嘗試connect。

Canal Client的方式和canal server方式類似，也是利用zookeeper的搶佔EPHEMERAL節點的方式進行控制.

Canal應用場景1、同步快取redis/全文搜尋ES

canal一個常見應用場景是同步快取/全文搜尋，當資料庫變更後透過binlog進行快取/ES的增量更新。當快取/ES更新出現問題時，應該回退binlog到過去某個位置進行重新同步，並提供全量重新整理快取/ES的方法，如下圖所示。

之前的老顧有篇文章中介紹了快取與資料庫一致性的問題，有一個方案就是binlog日誌；小夥伴們可以去看看

2、下發任務

另一種常見應用場景是下發任務，當資料變更時需要通知其他依賴系統。其原理是任務系統監聽資料庫變更，然後將變更的資料寫入MQ/kafka進行任務下發，比如商品資料變更後需要通知商品詳情頁、列表頁、搜尋頁等先關係統。這種方式可以保證資料下發的精確性，透過MQ傳送訊息通知變更快取是無法做到這一點的，而且業務系統中不會散落著各種下發MQ的程式碼，從而實現了下發歸集，如下圖所示。

3、資料異構

在大型網站架構中，DB都會採用分庫分表來解決容量和效能問題，但分庫分表之後帶來的新問題。比如不同維度的查詢或者聚合查詢，此時就會非常棘手。一般我們會透過資料異構機制來解決此問題。

所謂的資料異構，那就是將需要join查詢的多表按照某一個維度又聚合在一個DB中。讓你去查詢。canal就是實現資料異構的手段之一。

用canal來訂閱binlog，可異構系統

4、冗餘欄位

在微服務設計中，每個服務都會對應資料庫以及表；雖然微服務很強大，增加很多系統靈活性；但是也增加了複雜度；如：資料庫和表的獨立分離，導致有些join查詢不便。我們常用的方法就是設計表字段的冗餘。

但是冗餘方案，會有一些問題

上面2張表，位於不同的微服務，即不同的資料庫。為了方便在查詢order訂單的時候，顯示下單使用者的真實姓名；就在order表中對使用者truename進行了冗餘設計。但是如果user的服務對user的truename進行更新修改；那麼就導致了order表中的truename與user的truename不一致。

上面的場景在我們實際開發過程是非常常見的。當然為了解決這個問題，用binlog方式就非常簡單了；利用canal元件即可解決。

總結

老顧今天介紹了基於binlog的canal的基本原理，以及使用場景。當然不限於以上的使用場景，只要跟mysql的binlog有關都可以。下篇文章老顧會重點講解canal的使用方法。

---End---

老顧的微服務閘道器分享課程，請大家多多支援

推薦閱讀

大廠如何基於binlog解決多機房同步mysql資料（一）？

可用於大型應用的微服務生態灰度釋出如何實現？

一線大廠級別公共Redis叢集監控，細化到每個專案例項

Sharding-jdbc的實戰入門之水平分表（一）

Sharding-Jdbc之水平分庫和讀寫分離（二）

a、dubbo如何處理業務異常，這個一定要知道哦！

b、企業級SpringBoot應用多個子專案配置檔案規劃、多環境支援（一）

c、企業級SpringBoot應用多個子專案配置檔案規劃、多環境支援（二）

d、企業級SpringBoot應用多個子專案配置檔案之配置中心（三）

e、利用阿里開源工具進行排查線上CPU居高問題

f、阿里二面：如何快速排查死鎖？如何避免死鎖？

g、微服務分散式架構中，如何實現日誌鏈路跟蹤？

h、閘道器如何聚合各個微服務的介面文件？

i、Kubernetes之POD、容器之間的網路通訊

j、K8S中的Service的存在理由

k、企業微服務專案如何進入K8S的全過程

l、阿里開源專案Sentinel限流、降級的統一處理

m、大廠二面：Redis的分散式布隆過濾器是什麼原理？

1、基於RocketMq的SpringCloud Stream框架實戰入門

2、如何搭建訊息中介軟體應用框架之SpringCloud Stream

3、面試必備：閘道器異常了怎麼辦？如何做全域性異常處理？

4、Gateway網關係列(二)：SpringCloud Gateway入門實戰，路由規則

5、Gateway網關係列開篇：SpringCloud的官方閘道器Gateway介紹

6、API閘道器在微服務架構中的應用，這一篇就夠了

7、學習Lambda表示式看這篇就夠了，不會讓你失望的哦（續篇）

8、Lambda用在哪裡？幾種場景？

9、為什麼會出現Lambda表示式，你知道嗎？

10、不說“分散式事務”理論，直接上大廠阿里的解決方案，絕對實用

11、女程式設計師問到這個問題，讓我思考了半天，Mysql的“三高”架構

12、大廠二面：CAP原則為什麼只能滿足其中兩項？而不能同時滿足

13、阿里P7二面：聊聊零複製的原理

14、秒殺系統的核心點都在這裡，快來取

15、你瞭解如何利用token方式實現分散式Session嗎？

16、Mysql索引結構演變，為什麼最終會是那個結構呢？讓你一看就懂

17、一場比賽涉及到的知識，用通俗易通的方式介紹併發協調

18、企業實戰Redis全方面思考，你思考了嗎？

19、面試題：Thread的start和run的區別

20、面試題：什麼是CAS？CAS的作用以及缺點

21、如何訪問redis中的海量資料？避免事故產生

22、如何解決Redis熱點問題？以及如何發現熱點？

23、如何設計API介面，實現統一格式返回？

24、你真的知道在生產環境下如何部署tomcat嗎？

25、分享一線網際網路大廠分散式唯一ID設計 之 snowflake方案

26、分享大廠分散式唯一ID設計方案，快來圍觀

27、你想了解一線大廠的分散式唯一ID生成方案嗎？

28、你知道如何處理大資料量嗎？(資料拆分篇)

29、如何永不遷移資料和避免熱點? 根據伺服器指標分配資料量(揭秘篇)

30、你知道怎麼分庫分表嗎？如何做到永不遷移資料和避免熱點嗎？

31、你瞭解大型網站的頁面靜態化嗎？

32、你知道如何更新快取嗎？如何保證快取和資料庫雙寫一致性？

33、你知道怎麼解決DB讀寫分離，導致資料不一致問題嗎？

34、DB讀寫分離情況下，如何解決快取和資料庫不一致性問題？

35、你真的知道怎麼使用快取嗎？

36、如何利用鎖，防止快取擊穿？重構思想的重要性

37、海量訂單產生的業務高峰期，如何避免訊息的重複消費？

38、你知道如何保障生產端100%訊息投遞成功嗎？

39、微服務下的分散式session該如何管理？

40、阿里二面：filter、interceptor、aspect應如何選擇？很多人中招

41、網際網路架構重要組員CDN，很多高階開發都沒有實操過，來看這裡

42、阿里二面：CDN快取控制原理，看看能不能難住你

43、SpringCloud Alibaba之Nacos多環境多專案管理

44、SpringCloud Alibaba系列之Nacos配置中心玩法

45、SpringCloud Alibaba之Nacos註冊中心

46、SpringCloud Plus版本之SpringCloud Alibaba

47、SpringCloud Alibaba之Nacos叢集、持久化

48、SpringCloud Alibaba之Nacos共享配置、灰度配置

49、SpringCloud Alibaba之Sentinel工作原理

50、SpringCloud Alibaba之Sentinel流控管理

51、SpringCloud Alibaba之Sentinel降級管理

52、SpringCloud Alibaba之Sentinel熱點引數限流

53、SpringCloud Alibaba之Sentinel的API實戰