昨天推薦了vivo的架構(gòu)探索中有對canal的簡單介紹，但是我發(fā)現(xiàn)對一些細(xì)節(jié)問題沒有說，這個(gè)就對Canal的討論了

互聯(lián)網(wǎng)應(yīng)用隨著業(yè)務(wù)的發(fā)展，部分單表數(shù)據(jù)體量越來越大，應(yīng)對服務(wù)性能與穩(wěn)定的考慮，有做分庫分表、數(shù)據(jù)遷移的需要，本文介紹了vivo帳號(hào)應(yīng)對以上需求的實(shí)踐。

一、前言

Canal 是阿里巴巴開源項(xiàng)目，關(guān)于什么是 Canal？又能做什么？我會(huì)在后文為大家一一介紹。

在本文您將可以了解到vivo帳號(hào)使用 Canal 解決了什么樣的業(yè)務(wù)痛點(diǎn)，基于此希望對您所在業(yè)務(wù)能有一些啟示。

二、Canal介紹

1. 簡介

Canal [k?'n?l]，譯意為水道/管道/溝渠，主要用途是基于 MySQL 數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱和消費(fèi)。

早期阿里巴巴因?yàn)楹贾莺兔绹p機(jī)房部署，存在跨機(jī)房同步的業(yè)務(wù)需求，實(shí)現(xiàn)方式主要是基于業(yè)務(wù) trigger 獲取增量變更。從 2010 年開始，業(yè)務(wù)逐步嘗試數(shù)據(jù)庫日志解析獲取增量變更進(jìn)行同步，由此衍生出了大量的數(shù)據(jù)庫增量訂閱和消費(fèi)業(yè)務(wù)。

2. 工作原理

2.1 MySQL 主備復(fù)制原理

Canal最核心的運(yùn)行機(jī)制就是依賴于MySQL的主備復(fù)制，我們優(yōu)先簡要說明下MySQL主備復(fù)制原理。

MySQL master 將數(shù)據(jù)變更寫入二進(jìn)制日志( binary log, 其中記錄叫做二進(jìn)制日志事件binary log events，可以通過 show binlog events 進(jìn)行查看)。

MySQL slave 將 master 的 binary log events 拷貝到它的中繼日志(relay log)。

MySQL slave 重放 relay log 中事件，將數(shù)據(jù)變更反映它自己的數(shù)據(jù)。

2.2 MySQL Binary Log介紹

MySQL-Binlog是 MySQL 數(shù)據(jù)庫的二進(jìn)制日志，用于記錄用戶對數(shù)據(jù)庫操作的SQL語句（除了數(shù)據(jù)查詢語句）信息。

如果后續(xù)我們需要配置主從數(shù)據(jù)庫，如果我們需要從數(shù)據(jù)庫同步主數(shù)據(jù)庫的內(nèi)容，我們就可以通過 Binlog來進(jìn)行同步。

2.3 Canal 工作原理

Canal 模擬MySQL slave的交互協(xié)議，偽裝自己為MySQL slave，向MySQL master發(fā)送dump協(xié)議。

MySQL master收到dump請求，開始推送binary log給slave（也就是Canal）。

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

Canal 把解析后的 binary log 以特定格式的進(jìn)行推送，供下游消費(fèi)。

2.4 Canal 整體架構(gòu)

說明：

• server 代表一個(gè)canal運(yùn)行實(shí)例，對應(yīng)于一個(gè)jvm
• instance 對應(yīng)于一個(gè)數(shù)據(jù)隊(duì)列 （1個(gè)server對應(yīng)1..n個(gè)instance)

instance模塊：

• EventParser?(數(shù)據(jù)源接入，模擬slave協(xié)議和master進(jìn)行交互，協(xié)議解析)
  與數(shù)據(jù)庫交互模擬從庫，發(fā)送dump binlog請求，接收binlog進(jìn)行協(xié)議解析并做數(shù)據(jù)封裝，并將數(shù)據(jù)傳遞至下層EventSink進(jìn)行存儲(chǔ)，記錄binlog同步位置。
• EventSink?(Parser和Store鏈接器，進(jìn)行數(shù)據(jù)過濾，加工，分發(fā)的工作)
  數(shù)據(jù)過濾、數(shù)據(jù)歸并、數(shù)據(jù)加工、數(shù)據(jù)路由存儲(chǔ)。
• EventStore?(數(shù)據(jù)存儲(chǔ))
  管理數(shù)據(jù)對象存儲(chǔ)，包括新binlog對象的寫入管理、對象訂閱的位置管理、對象消費(fèi)成功的回執(zhí)位置管理。
• MetaManager?(增量訂閱&消費(fèi)信息管理器)負(fù)責(zé)binlog對象整體的發(fā)布訂閱管理器，類似于MQ。

2.5 Canal 數(shù)據(jù)格式

下面我們來一起看下Canal內(nèi)部封裝的 Binlog對象格式，更好的理解 Canal。

Canal能夠同步 DCL、 DML、 DDL。

業(yè)務(wù)通常關(guān)心 INSERT、 UPDATE、 DELETE引起的數(shù)據(jù)變更。

EntryProtocol.proto

EntryHeaderlogfileName [binlog文件名]logfileOffset [binlog position]executeTime [binlog里記錄變更發(fā)生的時(shí)間戳]schemaName [數(shù)據(jù)庫實(shí)例]tableName [表名]eventType [insert/update/delete類型]entryType [事務(wù)頭BEGIN/事務(wù)尾END/數(shù)據(jù)ROWDATA]storeValue [byte數(shù)據(jù),可展開，對應(yīng)的類型為RowChange]RowChangeisDdl [是否是ddl變更操作，比如create table/drop table]sql [具體的ddl sql]rowDatas [具體insert/update/delete的變更數(shù)據(jù)，可為多條，1個(gè)binlog event事件可對應(yīng)多條變更，比如批處理]beforeColumns [Column類型的數(shù)組]afterColumns [Column類型的數(shù)組]Columnindex [column序號(hào)]sqlType [jdbc type]name [column name]isKey [是否為主鍵]updated [是否發(fā)生過變更]isNull [值是否為null]value [具體的內(nèi)容，注意為文本]

（滑動(dòng)可查看）

2.6 Canal 示例 demo

下面我們通過實(shí)際代碼邏輯的判斷，查看 Binlog解析成Canal 對象的數(shù)據(jù)模型，加深理解

• insert 語句

• delete語句

• update語句

2.7 Canal HA 機(jī)制

線上服務(wù)的穩(wěn)定性極為重要，Canal是支持HA的，其實(shí)現(xiàn)機(jī)制也是依賴Zookeeper來實(shí)現(xiàn)的，與HDFS的HA類似。

Canal的HA分為兩部分，Canal server和Canal client分別有對應(yīng)的HA實(shí)現(xiàn)。

• Canal Server：為了減少對mysql dump的請求，不同server上的instance要求同一時(shí)間只能有一個(gè)處于running，其他的處于standby狀態(tài)。

• Canal Client：為了保證有序性，一份instance同一時(shí)間只能由一個(gè)canal client進(jìn)行g(shù)et/ack/rollback操作，否則客戶端接收無法保證有序。

依賴Zookeeper的特性（本文不著重講解zookeeper特性，請?jiān)诰W(wǎng)絡(luò)上查找對應(yīng)資料）：

• Watcher機(jī)制
• EPHEMERAL節(jié)點(diǎn)(和session生命周期綁定)

大致步驟：

Canal server要啟動(dòng)某個(gè)canal instance時(shí)都先向zookeeper進(jìn)行一次嘗試啟動(dòng)判斷 (實(shí)現(xiàn)：創(chuàng)建EPHEMERAL節(jié)點(diǎn)，誰創(chuàng)建成功就允許誰啟動(dòng))。

創(chuàng)建 ZooKeeper節(jié)點(diǎn)成功后，對應(yīng)的Canal server就啟動(dòng)對應(yīng)的Canal instance，沒有創(chuàng)建成功的Canal instance就會(huì)處于standby狀態(tài)。

一旦ZooKeeper發(fā)現(xiàn)Canal server A創(chuàng)建的節(jié)點(diǎn)消失后，立即通知其他的Canal server再次進(jìn)行步驟1的操作，重新選出一個(gè)Canal server啟動(dòng)instance。

Canal client每次進(jìn)行connect時(shí)，會(huì)首先向ZooKeeper詢問當(dāng)前是誰啟動(dòng)了Canal instance，然后和其建立鏈接，一旦鏈接不可用，會(huì)重新嘗試connect。

2.8 Canal 使用場景

上面介紹了Canal 的原理與運(yùn)行機(jī)制，下面我們從實(shí)際場景來看，Canal 能夠?yàn)槲覀儤I(yè)務(wù)場景解決什么樣的問題。

2.8.1 不停服遷移

業(yè)務(wù)在發(fā)展初期，為了快速支撐業(yè)務(wù)發(fā)展，很多數(shù)據(jù)存儲(chǔ)設(shè)計(jì)較為粗放，比如用戶表、訂單表可能都會(huì)設(shè)計(jì)為單表，此時(shí)常規(guī)手段會(huì)采用分庫分表來解決容量和性能問題。

但數(shù)據(jù)遷移會(huì)面臨最大的問題：線上業(yè)務(wù)需要正常運(yùn)行，如果數(shù)據(jù)在遷移過程中有變更，如何保證數(shù)據(jù)一致性是最大的挑戰(zhàn)。

基于Canal，通過訂閱數(shù)據(jù)庫的 Binlog，可以很好地解決這一問題。

可詳見下方vivo帳號(hào)的不停機(jī)遷移實(shí)踐。

2.8.2 緩存刷新

互聯(lián)網(wǎng)業(yè)務(wù)數(shù)據(jù)源不僅僅為數(shù)據(jù)庫，比如 Redis 在互聯(lián)網(wǎng)業(yè)務(wù)較為常用，在數(shù)據(jù)變更時(shí)需要刷新緩存，常規(guī)手段是在業(yè)務(wù)邏輯代碼中手動(dòng)刷新。

基于Canal，通過訂閱指定表數(shù)據(jù)的Binlog，可以異步解耦刷新緩存。

2.8.3 任務(wù)下發(fā)

另一種常見應(yīng)用場景是“下發(fā)任務(wù)”，當(dāng)數(shù)據(jù)變更時(shí)需要通知其他依賴系統(tǒng)。

其原理是任務(wù)系統(tǒng)監(jiān)聽數(shù)據(jù)庫變更，然后將變更的數(shù)據(jù)寫入MQ/Kafka進(jìn)行任務(wù)下發(fā)。

比如帳號(hào)注銷時(shí)下游業(yè)務(wù)方需要訂單此通知，為用戶刪除業(yè)務(wù)數(shù)據(jù)，或者做數(shù)據(jù)歸檔等。

基于Canal可以保證數(shù)據(jù)下發(fā)的精確性，同時(shí)業(yè)務(wù)系統(tǒng)中不會(huì)散落著各種下發(fā)MQ的代碼，從而實(shí)現(xiàn)了下發(fā)歸集，如下圖所示：

2.8.4 數(shù)據(jù)異構(gòu)

在大型網(wǎng)站架構(gòu)中，數(shù)據(jù)庫都會(huì)采用分庫分表來解決容量和性能問題，但分庫分表之后帶來的新問題。

比如不同維度的查詢或者聚合查詢，此時(shí)就會(huì)非常棘手。一般我們會(huì)通過數(shù)據(jù)異構(gòu)機(jī)制來解決此問題。

所謂的數(shù)據(jù)異構(gòu)，那就是將需要join查詢的多表按照某一個(gè)維度又聚合在一個(gè)DB中。

基于Canal可以實(shí)現(xiàn)數(shù)據(jù)異構(gòu)，如下圖示意：

3、Canal 的安裝及使用

Canal的詳細(xì)安裝、配置與使用，請查閱官方文檔 >> 鏈接

三、帳號(hào)實(shí)踐

1、實(shí)踐一：分庫分表

1.1 需求

• 難點(diǎn)：

表數(shù)據(jù)量大，單表3億多。

常規(guī)定時(shí)任務(wù)遷移全量數(shù)據(jù)，時(shí)間長且對業(yè)務(wù)有損。

• 核心訴求：

不停機(jī)遷移，最大化保證業(yè)務(wù)不受影響

“給在公路上跑著的車換輪胎”

1.2 遷移方案

1.3 遷移過程

整體過程大致如下：

• 分析帳號(hào)現(xiàn)有痛點(diǎn)

• 單表數(shù)據(jù)量過大：帳號(hào)單表3億+
• 用戶唯一標(biāo)識(shí)過多
• 業(yè)務(wù)劃分不合理

• 確定分庫分表方案

• 存量數(shù)據(jù)遷移方案

使用傳統(tǒng)的定時(shí)任務(wù)遷移，時(shí)長過長，且遷移過程中為了保證數(shù)據(jù)一致性，需要停機(jī)維護(hù)，對用戶影響較大。

確定使用canal進(jìn)行遷移，對canal做充分調(diào)研與評估，與中間件及DBA共同確定，可支持全量、以及增量同步。

• 遷移過程通過開關(guān)進(jìn)行控制，單表模式 → 雙寫模式 → 分表模式。
• 數(shù)據(jù)遷移周期長，遷移過程中遇到部分未能預(yù)估到的問題，進(jìn)行了多次遷移。
• 遷移完成后，正式切換至雙寫模式，即單表及分表同樣寫入數(shù)據(jù)，此時(shí)數(shù)據(jù)讀取仍然在單表模式下讀取數(shù)據(jù)，Canal仍然訂閱原有單表，進(jìn)行數(shù)據(jù)變更。
• 運(yùn)行兩周后線上未產(chǎn)生新問題，正式切至分表模式，此時(shí)原有單表不再寫入數(shù)據(jù)，即單表不會(huì)再有新的Binlog產(chǎn)生，切換后線上出現(xiàn)了部分問題，即時(shí)跟進(jìn)處理，“有驚無險(xiǎn)”。

2、實(shí)踐二：跨國數(shù)據(jù)遷移

2.1 需求

在vivo海外業(yè)務(wù)開展初期，海外部分國家的數(shù)據(jù)存儲(chǔ)在中立國新加坡機(jī)房，但隨著海外國家法律合規(guī)要求越來越嚴(yán)格，特別是歐盟地區(qū)的GDPR合規(guī)要求，vivo帳號(hào)應(yīng)對合規(guī)要求，做了比較多的合規(guī)改造工作。

部分非歐盟地區(qū)的國家合規(guī)要求隨之變化，舉例澳洲當(dāng)?shù)匾鬂M足GDPR合規(guī)要求，原有存儲(chǔ)在新加坡機(jī)房的澳洲用戶數(shù)據(jù)需要遷移至歐盟機(jī)房，整體遷移復(fù)雜度增加，其中涉及到的難點(diǎn)有：

• 不停機(jī)遷移，已出貨的手機(jī)用戶需要能正常訪問帳號(hào)服務(wù)。
• 數(shù)據(jù)一致性，用戶變更數(shù)據(jù)一致性需要保證。
• 業(yè)務(wù)方影響，不能影響現(xiàn)網(wǎng)業(yè)務(wù)方正常使用帳號(hào)服務(wù)。

2.2 遷移方案

2.3 遷移過程

• 在新加坡機(jī)房搭建備庫，主從同步 Binlog。
• 搭建 Canal 的server及client端，同步訂閱消費(fèi)Ｂinlog。
• client端基于訂閱的Ｂinlog進(jìn)行解析，將數(shù)據(jù)加密傳輸至歐盟GDPR機(jī)房。
• 歐盟應(yīng)用數(shù)據(jù)解析傳輸?shù)臄?shù)據(jù)，落地存儲(chǔ)。
• 數(shù)據(jù)同步完成后運(yùn)維同事協(xié)助將上層域名的DNS解析轉(zhuǎn)發(fā)至歐盟機(jī)房，完成數(shù)據(jù)切換。
• 觀察新加坡機(jī)房Canal服務(wù)運(yùn)行情況，沒有異常后停止Canal服務(wù)。
• 通過業(yè)務(wù)方，帳號(hào)側(cè)完成切換。
• 待業(yè)務(wù)方同步切換完成后，將新加坡機(jī)房的數(shù)據(jù)清除。

3、經(jīng)驗(yàn)總結(jié)

1.1 數(shù)據(jù)序列化

Canal底層使用protobuf作為數(shù)據(jù)數(shù)據(jù)列化的方式，Canal-client在訂閱到變更數(shù)據(jù)時(shí)，為null的數(shù)據(jù)會(huì)自動(dòng)轉(zhuǎn)換為空字符串，在ORM側(cè)數(shù)據(jù)更新時(shí)，因判斷邏輯不一致，導(dǎo)致最終表中數(shù)據(jù)更新為空字符串。

3.2 數(shù)據(jù)一致性

帳號(hào)本次線上Canal-client只有單節(jié)點(diǎn)，但在數(shù)據(jù)遷移過程中，因業(yè)務(wù)特性，導(dǎo)致數(shù)據(jù)出現(xiàn)了不一致的現(xiàn)象，示例大致如下：

• 用戶換綁手機(jī)號(hào)A。
• Canal此時(shí)在還未訂閱到此 Binlog position。
• 用戶又換綁手機(jī)號(hào)B。
• 在對應(yīng)時(shí)刻，Canal消費(fèi)到更新手機(jī)號(hào)A的Binlog，導(dǎo)致用戶新?lián)Q綁的手機(jī)號(hào)做了覆蓋。

3.3 數(shù)據(jù)庫主從延時(shí)

出于數(shù)據(jù)一致性地考慮（結(jié)合帳號(hào)業(yè)務(wù)數(shù)據(jù)未達(dá)到需要分庫的必要性），帳號(hào)分表在同一數(shù)據(jù)庫進(jìn)行，即遷移過程中分表數(shù)據(jù)不斷地進(jìn)行寫入，加大數(shù)據(jù)庫負(fù)載的同時(shí)造成了從庫讀取延時(shí)。

解決方案：增加速率控制，基于業(yè)務(wù)的實(shí)際情況，配置不同的策略，例如白天業(yè)務(wù)量大，可以適當(dāng)降低寫入速度，夜間業(yè)務(wù)量小，可以適當(dāng)提升寫入速度。

3.4 監(jiān)控告警

在整體數(shù)據(jù)遷移過程中，vivo帳號(hào)在client端增加了實(shí)時(shí)同步數(shù)據(jù)的簡易監(jiān)控手段，即基于業(yè)務(wù)表基于內(nèi)存做計(jì)數(shù)。

整體監(jiān)控粒度較粗，包括以上數(shù)據(jù)不一致性，在數(shù)據(jù)同步完成后，未能發(fā)現(xiàn)異常，導(dǎo)致切換至分表模式下出現(xiàn)了業(yè)務(wù)問題，好在邏輯數(shù)據(jù)可以通過補(bǔ)償?shù)绕渌侄螐浹a(bǔ)，且對線上數(shù)據(jù)影響較小。

四、拓展思考

1、現(xiàn)有問題分析

以上是基于 Canal現(xiàn)有架構(gòu)畫出的簡易圖，雖然基于HA整體高可用，但細(xì)究后還是會(huì)發(fā)現(xiàn)一些隱患，其中標(biāo)記紅色X的節(jié)點(diǎn)，可以視為可能出現(xiàn)的故障點(diǎn)。

2、通用組件復(fù)用

基于以上可能出現(xiàn)的問題點(diǎn)，我們可以嘗試做上圖中的優(yōu)化。

3、延展應(yīng)用-多數(shù)據(jù)中心同步

在互聯(lián)網(wǎng)行業(yè)，大家對“異地多活”已經(jīng)耳熟能詳，而數(shù)據(jù)同步是異地多活的基礎(chǔ)，所有具備數(shù)據(jù)存儲(chǔ)能力的組件如：數(shù)據(jù)庫、緩存、MQ等，數(shù)據(jù)都可以進(jìn)行同步，形成一個(gè)龐大而復(fù)雜的數(shù)據(jù)同步拓?fù)?#xff0c;相互備份對方的數(shù)據(jù)，才能做到真正意義上"異地多活”。

本邏輯不在本次討論范圍內(nèi)，大家可以參閱以下文章內(nèi)容，筆者個(gè)人認(rèn)為講解較為詳細(xì)

http://www.tianshouzhi.com/api/tutorials/canal/404

五、參考資料

• https://github.com/alibaba/canal
• https://github.com/alibaba/otter

來自：vivo的技術(shù)團(tuán)隊(duì)

原鏈接：
https://mp.weixin.qq.com/s/X1OFhjpHZSuIMr5PmxXBRQ

總結(jié)

以上是生活随笔為你收集整理的Canal组件简介与vivo账号实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。