binlog以及Canal的知識有哪些

本篇文章給大家分享的是有關(guān)binlog以及Canal的知識有哪些，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

背景

不知道是否你還在為下面的問題而困擾：

• 當(dāng)你使用了redis或者其他中間件做緩存的時候，經(jīng)常發(fā)現(xiàn)緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致，只能通過定時任務(wù)或者緩存過期的方式去做一些限制。

• 當(dāng)你使用了ES做搜索工具，使用雙寫的那一套方法，還在為ES和數(shù)據(jù)庫不是一個事務(wù)而擔(dān)憂。

• 當(dāng)你需要遷移數(shù)據(jù)的時候，也還在使用雙寫的方法，如果是同一個數(shù)據(jù)庫的還好，如果是不同數(shù)據(jù)庫就不能保證事務(wù)，那么數(shù)據(jù)一致性也是個問題，就會寫很多的修復(fù)Job和檢查Job。

這些問題相信在很多同學(xué)的業(yè)務(wù)當(dāng)中應(yīng)該都遇到過，也可能因為這些問題常常增加了很多的工作量或者導(dǎo)致一些數(shù)據(jù)不一致的故障。那么我們怎么才能比較簡單的解決這些問題呢？

我們想一想這個問題的本質(zhì)是什么呢？就是需要保證我們的數(shù)據(jù)不論在redis還是在es都要和我們的mysql一致，本質(zhì)上是數(shù)據(jù)的復(fù)制。一想到數(shù)據(jù)的復(fù)制，熟悉Mysql的朋友就會說到：Mysql的主備不也是數(shù)據(jù)復(fù)制嗎？如果我們模仿Mysql的主備復(fù)制，那我們數(shù)據(jù)同步那么就會很容易了。

Mysql主從

既然我們可以模仿Mysql的主從復(fù)制來完成我們的需求，那么我們需要先了解一下mysql主從的原理，如下圖所示：

• Stpe 1: 作為master的mysql需要在每個事務(wù)更新數(shù)據(jù)完成之前，將該操作記錄串行地寫入到binlog文件中，存儲在本地磁盤中。

• Step 2: 在我們的salve服務(wù)器中開啟一個I/O Thread，它會不斷的從binlog中讀取如果讀取。如果進度已經(jīng)跟上了master，就進入睡眠狀態(tài)并等待master產(chǎn)生新的事件。所有讀取的數(shù)據(jù)都會寫到Relay log（中繼日志）中。

• Step 3：SQL Thread會讀取中繼日志，并順序執(zhí)行該日志中的SQL事件，從而與主數(shù)據(jù)庫中的數(shù)據(jù)保持一致。

在主從復(fù)制中過程中，其中最為重要的就是binlog，從庫會根據(jù)binlog的信息從而來復(fù)制出一份主庫的數(shù)據(jù)。

如果我們能在業(yè)務(wù)代碼中拿到binlog，通過binlog的數(shù)據(jù)，復(fù)制到redis或者es中，那我們就完全不用擔(dān)心數(shù)據(jù)的一致性的問題了。

binlog

binlog(Binary Log)顧名思義就是Mysql中二進制的日志，記錄了Mysql對數(shù)據(jù)庫執(zhí)行更改的所有操作。binlog也是server層產(chǎn)生的日志和我們的存儲引擎沒有關(guān)系，不論你使用哪種存儲引擎，都可以使用我們的binlog。

binlog格式

在binlog中有三種格式，分別是：Statement，Row, Mixed三種，可以通過show variables like 'binlog_format'進行查看當(dāng)前數(shù)據(jù)庫的binlog格式,如下圖所示就是一個Row格式的binlog：

Statement

Statement也就是語句類型，他會記錄每一條修改數(shù)據(jù)的Sql到binlog中。

• 優(yōu)點：空間占比是最小的，不會記錄沒有修改的字段。相比其他模式減少了很多的日志亮，提高I/O性能。

• 缺點：異構(gòu)系統(tǒng)不方便使用，比如redis緩存復(fù)制的時候，很難模擬mysql的從操作，需要數(shù)據(jù)重查一次。并且slave也會有問題，比如使用一些UUID函數(shù)，slave重放的時候并不能保證兩邊是一致的。 我們可以查看下Statement的日志內(nèi)容到底是什么？我們這里可以輸入命令：show master status;查看我們當(dāng)前master正在使用的binlog，如下圖：

然后再使用命令show binlog events in 'mysql-bin.000003', 查看這個日志中的內(nèi)容是什么： 我們可以發(fā)現(xiàn)我們所有的操作都會在一個完整的事務(wù)中進行,如果事務(wù)沒有提交是不會出現(xiàn)在我們的binlog當(dāng)中的，這個大家可以下來進行實驗一下，我們在數(shù)據(jù)庫中的更新原始sql都會被完全的記錄下來。

Row

Row模式和Statement不同，他會記錄每一行被修改后的所有的數(shù)據(jù)：

• 優(yōu)點：異構(gòu)系統(tǒng)也能比較方便的同步數(shù)據(jù)，并且不會出現(xiàn)UUID函數(shù)的那種問題，無論什么情況都能被復(fù)制。

• 缺點：數(shù)據(jù)量比較多，比如update語句，他還會記錄更新前的每一個字段和更新后的每一個字段。造成日志量比較大，對I/O有一定的影響。

同樣的我們也查看一下其中的內(nèi)容：

在show binlog events in 'mysql-bin.000004'命令中，我們發(fā)現(xiàn)在事務(wù)中是查看不了我們具體的數(shù)據(jù)的，這個時候就需要我們工具幫忙了mysqlbinlog，他也在mysql的bin目錄下我們直接調(diào)用就好了，輸入命令/usr/local/mysql/bin/mysqlbinlog --base64-output=decode-rows -v mysql-bin.000004，我們可以看見：

這里展示的是一個update語句，他不僅顯示了原始值，也展示了修改后的值。

這里要注意的是binlog_row_image用于決定row是否會記錄原始值，默認是FULL代表會記錄，也就是我們上面的這種情況，還有個參數(shù)是minimal，代表只記錄更新后的值。

Mixed

在mixed模式下，MySQL默認仍然采用statement格式進行記錄，但是一旦它判斷可能會有數(shù)據(jù)不一致的情況(UUID函數(shù))發(fā)生，則會采用row格式來記錄。

我們目前默認使用的是Row模式，在Row模式下可以比較方便的將數(shù)據(jù)異構(gòu)，其實Row模式對I/O影響在業(yè)務(wù)當(dāng)中來說感知并不是特別明顯。

Canal

當(dāng)我們知道binlog是什么之后，我們就需要怎么去使用這個binlog。binlog的同步工具常見的有：databus,canal,maxwell,阿里云dts等等，在這里我們就不比較他們各自的優(yōu)劣點了，重點去介紹canal。

canal(github地址：https://github.com/alibaba/canal)，譯意為水道/管道/溝渠，主要用途是基于 MySQL 數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱和消費

早期阿里巴巴因為杭州和美國雙機房部署，存在跨機房同步的業(yè)務(wù)需求，實現(xiàn)方式主要是基于業(yè)務(wù) trigger 獲取增量變更。從 2010 年開始，業(yè)務(wù)逐步嘗試數(shù)據(jù)庫日志解析獲取增量變更進行同步，由此衍生出了大量的數(shù)據(jù)庫增量訂閱和消費業(yè)務(wù)。后面在阿里云中逐漸演化稱DTS項目。

canal大體原理也是模仿mysql的slave，從master上不斷的去拉取binlog，然后將binlog可以投放到不同的地方，比如我們常見的消息隊列：kafka,rocketmq等等。當(dāng)然在阿里云的付費dts上面也是可以直接同步到redis，es或者其他的一些存儲介質(zhì)當(dāng)中。

canal的簡單使用可以查看quickStart：https://github.com/alibaba/canal/wiki/QuickStart ，這里不做過多的介紹。接下來主要是更多的介紹canal的整體架構(gòu)，以及實現(xiàn)的原理等等。

Canal整體架構(gòu)

CanalServer:一個Jvm就可以理解成一個CanalServer,如果是集群模式的Canal的話 那么就會有多個CanalServer。

CanalInstance: 可以理解為一個作業(yè)為一個Instance,比如有一個把A庫的binlog同步到A消息隊列，B庫的binlog同步到B的消息隊列，那么這就是兩個不同的Instance，至于哪個Instance在哪個CanalServer上跑，需要看誰先在ZK搶占到臨時節(jié)點，如果分配得足夠均勻得話，可以在集群模式下緩解很多壓力。

CanalParser: 用于拉取mysql-binlog，并進行解析。

EventSink: 將解析的數(shù)據(jù)進行處理加工（過濾，合并等）。

CanalEventStore: 這個有點類似slave中的relay log，用于將日志進行中繼存儲，但是在canal中目前只支持了在內(nèi)存中存儲，目前不支持落盤存儲。

CanalParser，EventSink，CanalEventStore這三個都是屬于Canal中非常重要的組件,他們之間的關(guān)系如下：

CanalParser產(chǎn)生數(shù)據(jù)讓EventSink進行加工，加工后的數(shù)據(jù)會存儲在CanalEventStore中，然后MQ從CanalEventStore中不斷的拉取最新數(shù)據(jù)，然后投遞到MQ。

CanalParser

我們來講講在CanalParser中Canal是如何偽裝成slave去拉數(shù)據(jù)的，在AbstractEventParser.java這個類中有如下步驟：

• Step1: 構(gòu)建一個數(shù)據(jù)庫鏈接，并且生成一個slaveId,用于標(biāo)示自己slave的身份。

• Step2: 獲取數(shù)據(jù)庫的元信息，比如binlogFormat,binRowImage等等。

• Step3: 通過show variables like 'server_id' 命令，獲取我們需要監(jiān)聽binlog服務(wù)的serverId。

• Step4: 獲取這一次需要消費的位置，如果有存儲上一次的就從上一次中獲取，如果沒有的話需要通過show master status命令中獲取到的最新的Position進行消費。

• Step5: 進行dump操作，模擬slave發(fā)送注冊slave請求，以及dump binlog請求，然后用一個死循環(huán)不斷的從binlog中拉取數(shù)據(jù)：

• Step6: 將獲取到的二進制數(shù)據(jù)，根據(jù)mysql binlog協(xié)議轉(zhuǎn)換成logEntry，方便后續(xù)處理。

EventSink

EventSink會將上面獲取到的logEntry來進行加工：

• 過濾：

• 過濾空的事務(wù)

• 過濾心跳

• 自定義過濾

• 記錄，這里使用了Prometheus，來進行數(shù)據(jù)的統(tǒng)計上報。

• 合并，現(xiàn)在有很多分庫分表的業(yè)務(wù)需要，他們的數(shù)據(jù)來源都是從不同的Parser中來的，但是最后都需要匯總到同一個EventStore中。在這個場景需要注意的我們可以需要注意的是會做時間歸并控制，也就是盡量讓每個分庫的數(shù)據(jù)匯總后都是遞增的方式提交，避免出現(xiàn)某個分庫的數(shù)據(jù)比其他的領(lǐng)先或者落后很多。

EventStore

我們先看看EventStore中提供的接口： 可以看見EventStore其實就是一個簡單的存儲，在canal中提供了MemoryEventStoreWithBuffer，在內(nèi)存中進行中轉(zhuǎn)的數(shù)據(jù)，其中的原理是通過RingBuffer（無鎖，高性能隊列）實現(xiàn)的，有關(guān)于RingBuffer的信息可以參考我之前的文章你應(yīng)該知道的Disruptor,在3.1中有對RingBuffer進行詳細講解。

然后CanalMq通過EventStore不斷的獲取數(shù)據(jù)，來進行數(shù)據(jù)發(fā)送。

以上就是binlog以及Canal的知識有哪些，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。