• • 1. cannal 是什么，能做什么用
    • 1.1 mysql的binlog
    • 1.2 mysql 的主從復制過程
    • 1.3 canal能夠同步數據的原理
  • 2. quick start
  • 3. canal 的設計
    • 3.1 canal的設計理念
    • 3.2 canal的組件有哪些
    • 3.3 instance 包含的組件
    • 3.4 各個組件目前支持的類型
  • 4. canal的工作過程
    • 4.1 啟動時去MySQL 進行dump操作的binlog 位置確定
    • 4.2 數據在dump回來之后進行的歸集(sink)和存儲(store)
    • 4.3 binlog的消費者
  • 5. canal的目錄結構（不包含lib目錄）

1. cannal 是什么，能做什么用

canal 的歷史
??早期，阿里巴巴B2B公司因為存在杭州和美國雙機房部署，存在跨機房同步的業務需求。不過早期的數據庫同步業務，主要是基于trigger的方式獲取增量變更，不過從2010年開始，阿里系公司開始逐步的嘗試基于數據庫的日志解析，獲取增量變更進行同步，由此衍生出了增量訂閱&消費的業務。
??基于數據庫增量日志解析，提供增量數據訂閱&消費，目前主要支持了mysql。

1.1 mysql的binlog

??它記錄了所有的DDL和DML(除了數據查詢語句)語句，以事件形式記錄，還包含語句所執行的消耗的時間。主要用來備份和數據同步。

binlog 有三種模式：STATEMENT、ROW、MIXED

1.STATEMENT 記錄的是執行的sql語句
2.ROW 記錄的是真實的行數據記錄
3.MIXED 記錄的是1+2，優先按照1的模式記錄

舉例來說，下面的sql
update user set age=20

對應STATEMENT模式只有一條記錄，對應ROW模式則有可能有成千上萬條記錄（取決數據庫中的記錄數）。

1.2 mysql 的主從復制過程

Slave 上面的IO線程連接上 Master，并請求從指定日志文件的指定位置(或者從最開始的日志)之后的日志內容;

Master 接收到來自 Slave 的 IO 線程的請求后，通過負責復制的 IO 線程根據請求信息讀取指定日志指定位置之后的日志信息，返回給 Slave 端的 IO 線程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 Binary Log 中的位置;

Slave 的 IO 線程接收到信息后，將接收到的日志內容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的Master端的bin-log的文件名和位置記錄到master- info文件中，以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log的哪個位置開始往后的日志內容，請發給我”

Slave 的 SQL 線程檢測到 Relay Log 中新增加了內容后，會馬上解析該 Log 文件中的內容成為在 Master 端真實執行時候的那些可執行的 Query 語句，并在自身執行這些 Query。這樣，實際上就是在 Master 端和 Slave 端執行了同樣的 Query，所以兩端的數據是完全一樣的。
當然這個過程本質上還是存在一定的延遲的。
mysql的binlog文件長這個樣子。

mysql-bin.003831 mysql-bin.003840 mysql-bin.003849 mysql-bin.003858

1.3 canal能夠同步數據的原理

理解了mysql的主從同步的機制再來看canal就比較清晰了，canal主要是聽過偽裝成mysql從server來向主server拉取數據。

canal模擬mysql slave的交互協議，偽裝自己為mysql slave，向mysql master發送dump協議

mysql master收到dump請求，開始推送binary log給slave(也就是canal)

canal解析binary log對象(原始為byte流)

2. quick start

直接引用 阿里的就不錯，這里是一個阿里的單機版配置。
https://github.com/alibaba/canal/wiki/QuickStart
主要的點就是：

數據庫配置，需要記錄bin_log 需要使用row模式，需要創建用戶給canal使用

canal配置相應的主庫地址，server_id在mysql的集群中不能重復,過濾哪些表使用的正則。

這個是一個單機的canal的搭建，并不是HA的模式。

3. canal 的設計

3.1 canal的設計理念

canal的組件化設計非常好，有點類似于tomcat的設計。使用組合設計，依賴倒置，面向接口的設計。

3.2 canal的組件有哪些

canal server 這個代表了我們部署的一個canal 應用

canal instance 這個代表了一個canal server中的多個 mysql instance ,從這一點說明一個canal server可以搜集多個庫的數據，在canal中叫 destionation。

??每個canal instance 有多個組件構成。在conf/spring/default-instance.xml中配置了這些組件。他其實是使用了spring的容器來進行這些組件管理的。

3.3 instance 包含的組件

這里是一個cannalInstance工作所包含的大組件。截取自 conf/spring/default-instance.xml

<bean id="instance" class="com.alibaba.otter.canal.instance.spring.CanalInstanceWithSpring"><property name="destination" value="${canal.instance.destination}" /><property name="eventParser"><ref local="eventParser" /></property><property name="eventSink"><ref local="eventSink" /></property><property name="eventStore"><ref local="eventStore" /></property><property name="metaManager"><ref local="metaManager" /></property><property name="alarmHandler"><ref local="alarmHandler" /></property></bean>

eventParser 最基本的組件，類似于mysql從庫的dump線程，負責從master中獲取bin_log

eventSink 數據的歸集，使用設置的filter對bin log進行過濾，工作的過程如下。

eventStore 用來存儲filter過濾后的數據，canal目前的數據只在這里存儲，工作流程如下。

metaManager 用來存儲一些原數據，比如消費到的游標，當前活動的server等信息

alarmHandler 報警，這個一般情況下就是錯誤日志，理論上應該是可以定制成郵件等形式，但是目前不支持

3.4 各個組件目前支持的類型

canal采用了spring bean container的方式來組裝一個canal instance ,目的是為了能夠更加靈活。

eventParser 目前只有三種
1.1. MysqlEventParser 用于解析mysql的日志
1.2. GroupEventParser 多個eventParser的集合，理論上是對應了分表的情況，可以通過這個合并到一起
1.3. RdsLocalBinlogEventParser 基于rds的binlog 的復制

eventSink 目前只有EntryEventSink 就是基于mysql的binlog數據對象的處理操作

eventStore 目前只有一種 MemoryEventStoreWithBuffer，內部使用了一個ringbuffer 也就是說canal解析的數據都是存在內存中的，并沒有到zookeeper當中。

metaManager 這個比較多，其實根據元數據存放的位置可以分為三大類，memory,file,zookeeper

??canal通過這些組件的選取可以達到不同使用場景的效果，比如單機的話，一般使用file來存儲metadata就行了,HA的話一般使用zookeeper來存儲metadata。

4. canal的工作過程

4.1 啟動時去MySQL 進行dump操作的binlog 位置確定

??工作的過程。在啟動一個canal instance 的時候，首先啟動一個eventParser 線程來進行數據的dump 當他去master拉取binlog的時候需要binlog的位置，這個位置的確定是按照如下的順序來確定的（這個地方講述的是HA模式哈）。

在啟動的時候判斷是否使用zookeeper，如果是zookeeper,看能否拿到 cursor (也就是binlog的信息)，如果能夠拿到，把這個信息存到內存中（MemoryLogPositionManager）,然后拿這個信息去mysql中dump binlog

通過1拿不到的話(一般是zookeeper當中每一，比如第一次搭建的時候，或者因為某些原因zk中的數據被刪除了)，就去配置文件配置當中的去拿,把這個信息存到內存中（MemoryLogPositionManager）,然后拿這個信息去mysql中dump binlog

通過2依然沒有拿到的話，就去mysql 中執行一個sql show master status 這個語句會顯示當前mysql binlog最后位置的信息，也就是剛寫入的binlog所在的位置信息。把這個信息存到內存中（MemoryLogPositionManager）,然后拿這個信息去mysql中dump binlog。

??后面的eventParser的操作就會以內存中（MemoryLogPositionManager）存儲的binlog位置去master進行dump操作了。
mysql的show master status 操作

mysql> mysql> show master status\G *************************** 1. row *************************** File: mysql-bin.000028 Position: 635762367 Binlog_Do_DB:Binlog_Ignore_DB: Executed_Gtid_Set: 18db0532-6a08-11e8-a13e-52540042a113:1-2784514, 318556ef-4e47-11e6-81b6-52540097a9a8:1-30002, ac5a3780-63ad-11e8-a9ac-52540042a113:1-5, be44d87c-4f25-11e6-a0a8-525400de9ffd:1-156349782 1 row in set (0.00 sec)

4.2 數據在dump回來之后進行的歸集(sink)和存儲(store)

sink操作是可以支撐將多個eventParser的數據進行過濾filter

filter使用的是instance.properties中配置的filter,當然這個filter也可以由canal的client端在進行subscribe的時候進行設置。如果在client端進行了設置，那么服務端配置文件instance.properties的配置都會失效

sink 之后將過濾后的數據存儲到eventStore當中去。
??目前eventStore的實現只有一個MemoryEventStoreWithBuffer,也就是基于內存的ringbuffer,使用這個store有一個特點，這個ringbuffer是基于內存的，大小是有限制的(bufferSize = 16 * 1024 也就是16M)，所以，當canal的客戶端消費比較慢的時候,ringbuffer中存滿了就會阻塞sink操作，那么正讀取mysql binlog的eventParser線程也會受阻。
??這種設計其實也是有道理的。 因為canal的操作是pull 模型，不是producer push的模型，所以他沒必要存儲太多數據，這樣就可以避免了數據存儲和持久化管理的一些問題。使數據管理的復雜度大大降低。

??上面這些整個是canal的parser 線程的工作流程，主要對應的就是將數據從mysql搞下來，做一些基本的歸集和過濾，然后存儲到內存中。

4.3 binlog的消費者

??canal從mysql訂閱了binlog以后主要還是想要給消費者使用。那么binlog是在什么時候被消費呢。這就是另一條主線了。就像咱們做一個toC的系統，管理系統是必須的，用戶使用的app或者web又是一套，eventParser 線程就像是管理系統，往里面錄入基礎數據。canal的client就像是app端一樣，是這些數據的消費方。
??binlog的主要消費者就是canal的client端。使用的協議是基于tcp的google.protobuf,當然tcp的模式是io多路復用，也就是nio。當我們的client發起請求之后，canal的server端就會從eventStore中將數據傳輸給客戶端。根據客戶端的ack機制，將binlog的元數據信息定期同步到zookeeper當中。

差不多主要的操作就是這些吧。

5. canal的目錄結構（不包含lib目錄）

配置父目錄：
在下面可以看到，

canal ├── bin │ ├── canal.pid │ ├── startup.bat │ ├── startup.sh │ └── stop.sh └── conf├── canal.properties├── gamer ---目錄├── ww_social ---目錄├── wother ---目錄├── nihao ---目錄├── liveim ---目錄├── logback.xml├── spring ---目錄├── ym ---目錄└── xrm_ppp ---目錄

這里是全部展開的目錄

canal ├── bin │ ├── canal.pid │ ├── startup.bat │ ├── startup.sh │ └── stop.sh └── conf├── canal.properties├── game_center│ └── instance.properties├── ww_social│ ├── h2.mv.db│ ├── h2.trace.db│ └── instance.properties├── wwother│ ├── h2.mv.db│ └── instance.properties├── nihao│ ├── h2.mv.db│ ├── h2.trace.db│ └── instance.properties├── movie│ ├── h2.mv.db│ └── instance.properties├── logback.xml├── spring│ ├── default-instance.xml│ ├── file-instance.xml│ ├── group-instance.xml│ ├── local-instance.xml│ ├── memory-instance.xml│ └── tsdb│ ├── h2-tsdb.xml│ ├── mysql-tsdb.xml│ ├── sql│ └── sql-map└── ym└── instance.properties

總結

以上是生活随笔為你收集整理的canal原理的一些学习-1（canal的一些原理性介绍）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。