昨天推薦了vivo的架構(gòu)探索中有對(duì)canal的簡(jiǎn)單介紹肪获，但是我發(fā)現(xiàn)對(duì)一些細(xì)節(jié)問題沒有說，這個(gè)就對(duì)Canal的討論了
互聯(lián)網(wǎng)應(yīng)用隨著業(yè)務(wù)的發(fā)展纺且，部分單表數(shù)據(jù)體量越來越大帮坚，應(yīng)對(duì)服務(wù)性能與穩(wěn)定的考慮妻往，有做分庫(kù)分表、數(shù)據(jù)遷移的需要试和，本文介紹了vivo帳號(hào)應(yīng)對(duì)以上需求的實(shí)踐蒲讯。
一疲陕、前言
Canal 是阿里巴巴開源項(xiàng)目府蛇，關(guān)于什么是 Canal？又能做什么裳仆？我會(huì)在后文為大家一一介紹溉箕。
在本文您將可以了解到vivo帳號(hào)使用 Canal 解決了什么樣的業(yè)務(wù)痛點(diǎn)晦墙，基于此希望對(duì)您所在業(yè)務(wù)能有一些啟示。
二肴茄、Canal介紹
1. 簡(jiǎn)介
Canal [k?'n?l]晌畅，譯意為水道/管道/溝渠，主要用途是基于 MySQL 數(shù)據(jù)庫(kù)增量日志解析寡痰，提供增量數(shù)據(jù)訂閱和消費(fèi)抗楔。
早期阿里巴巴因?yàn)楹贾莺兔绹?guó)雙機(jī)房部署，存在跨機(jī)房同步的業(yè)務(wù)需求拦坠，實(shí)現(xiàn)方式主要是基于業(yè)務(wù) trigger 獲取增量變更连躏。從 2010 年開始，業(yè)務(wù)逐步嘗試數(shù)據(jù)庫(kù)日志解析獲取增量變更進(jìn)行同步贞滨，由此衍生出了大量的數(shù)據(jù)庫(kù)增量訂閱和消費(fèi)業(yè)務(wù)入热。
2. 工作原理
2.1 MySQL 主備復(fù)制原理
Canal最核心的運(yùn)行機(jī)制就是依賴于MySQL的主備復(fù)制，我們優(yōu)先簡(jiǎn)要說明下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ù)庫(kù)的二進(jìn)制日志，用于記錄用戶對(duì)數(shù)據(jù)庫(kù)操作的SQL語句（除了數(shù)據(jù)查詢語句）信息事甜。
如果后續(xù)我們需要配置主從數(shù)據(jù)庫(kù)忙芒，如果我們需要從數(shù)據(jù)庫(kù)同步主數(shù)據(jù)庫(kù)的內(nèi)容，我們就可以通過 Binlog來進(jìn)行同步讳侨。
2.3 Canal 工作原理
Canal 模擬MySQL slave的交互協(xié)議，偽裝自己為MySQL slave奏属，向MySQL master發(fā)送dump協(xié)議跨跨。
MySQL master收到dump請(qǐng)求，開始推送binary log給slave（也就是Canal）囱皿。
Canal 解析 binary log 對(duì)象(原始為byte流)勇婴。
Canal 把解析后的 binary log 以特定格式的進(jìn)行推送，供下游消費(fèi)嘱腥。
2.4 Canal 整體架構(gòu)
說明：
- server 代表一個(gè)canal運(yùn)行實(shí)例耕渴，對(duì)應(yīng)于一個(gè)jvm
- instance 對(duì)應(yīng)于一個(gè)數(shù)據(jù)隊(duì)列 （1個(gè)server對(duì)應(yīng)1..n個(gè)instance)
instance模塊：
- **EventParser **(數(shù)據(jù)源接入，模擬slave協(xié)議和master進(jìn)行交互齿兔，協(xié)議解析)
與數(shù)據(jù)庫(kù)交互模擬從庫(kù)橱脸，發(fā)送dump binlog請(qǐng)求，接收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ù)對(duì)象存儲(chǔ)花颗，包括新binlog對(duì)象的寫入管理、對(duì)象訂閱的位置管理惠拭、對(duì)象消費(fèi)成功的回執(zhí)位置管理捎稚。 - **MetaManager **(增量訂閱&消費(fèi)信息管理器)負(fù)責(zé)binlog對(duì)象整體的發(fā)布訂閱管理器，類似于MQ。
2.5 Canal 數(shù)據(jù)格式
下面我們來一起看下Canal內(nèi)部封裝的 Binlog對(duì)象格式今野，更好的理解 Canal葡公。
Canal能夠同步 DCL、 DML条霜、 DDL催什。
業(yè)務(wù)通常關(guān)心 INSERT、 UPDATE宰睡、 DELETE引起的數(shù)據(jù)變更蒲凶。
EntryProtocol.proto
Entry
Header
logfileName [binlog文件名]
logfileOffset [binlog position]
executeTime [binlog里記錄變更發(fā)生的時(shí)間戳]
schemaName [數(shù)據(jù)庫(kù)實(shí)例]
tableName [表名]
eventType [insert/update/delete類型]
entryType [事務(wù)頭BEGIN/事務(wù)尾END/數(shù)據(jù)ROWDATA]
storeValue [byte數(shù)據(jù),可展開，對(duì)應(yīng)的類型為RowChange]
RowChange
isDdl [是否是ddl變更操作拆内，比如create table/drop table]
sql [具體的ddl sql]
rowDatas [具體insert/update/delete的變更數(shù)據(jù)旋圆，可為多條，1個(gè)binlog event事件可對(duì)應(yīng)多條變更麸恍，比如批處理]
beforeColumns [Column類型的數(shù)組]
afterColumns [Column類型的數(shù)組]
Column
index [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 對(duì)象的數(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分別有對(duì)應(yīng)的HA實(shí)現(xiàn)噪馏。
Canal Server：為了減少對(duì)mysql dump的請(qǐng)求麦到，不同server上的instance要求同一時(shí)間只能有一個(gè)處于running，其他的處于standby狀態(tài)欠肾。
Canal Client：為了保證有序性隅要，一份instance同一時(shí)間只能由一個(gè)canal client進(jìn)行g(shù)et/ack/rollback操作，否則客戶端接收無法保證有序董济。
依賴Zookeeper的特性（本文不著重講解zookeeper特性步清，請(qǐng)?jiān)诰W(wǎng)絡(luò)上查找對(duì)應(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)成功后廓啊，對(duì)應(yīng)的Canal server就啟動(dòng)對(duì)應(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 使用場(chǎng)景
上面介紹了Canal 的原理與運(yùn)行機(jī)制，下面我們從實(shí)際場(chǎng)景來看翩隧，Canal 能夠?yàn)槲覀儤I(yè)務(wù)場(chǎng)景解決什么樣的問題樊展。
<u style="margin: 0px; padding: 0px; border: 0px;">2.8.1 不停服遷移</u>
業(yè)務(wù)在發(fā)展初期，為了快速支撐業(yè)務(wù)發(fā)展堆生，很多數(shù)據(jù)存儲(chǔ)設(shè)計(jì)較為粗放专缠，比如用戶表、訂單表可能都會(huì)設(shè)計(jì)為單表淑仆，此時(shí)常規(guī)手段會(huì)采用分庫(kù)分表來解決容量和性能問題涝婉。
但數(shù)據(jù)遷移會(huì)面臨最大的問題：線上業(yè)務(wù)需要正常運(yùn)行，如果數(shù)據(jù)在遷移過程中有變更蔗怠，如何保證數(shù)據(jù)一致性是最大的挑戰(zhàn)墩弯。
基于Canal，通過訂閱數(shù)據(jù)庫(kù)的 Binlog蟀淮，可以很好地解決這一問題。
可詳見下方vivo帳號(hào)的不停機(jī)遷移實(shí)踐钞澳。
<u style="margin: 0px; padding: 0px; border: 0px;">2.8.2 緩存刷新</u>
互聯(lián)網(wǎng)業(yè)務(wù)數(shù)據(jù)源不僅僅為數(shù)據(jù)庫(kù)怠惶，比如 Redis 在互聯(lián)網(wǎng)業(yè)務(wù)較為常用，在數(shù)據(jù)變更時(shí)需要刷新緩存轧粟，常規(guī)手段是在業(yè)務(wù)邏輯代碼中手動(dòng)刷新策治。
基于Canal，通過訂閱指定表數(shù)據(jù)的Binlog兰吟，可以異步解耦刷新緩存通惫。
<u style="margin: 0px; padding: 0px; border: 0px;">2.8.3 任務(wù)下發(fā)</u>
另一種常見應(yīng)用場(chǎng)景是“下發(fā)任務(wù)”，當(dāng)數(shù)據(jù)變更時(shí)需要通知其他依賴系統(tǒng)混蔼。
其原理是任務(wù)系統(tǒng)監(jiān)聽數(shù)據(jù)庫(kù)變更履腋，然后將變更的數(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ā)歸集，如下圖所示：
<u style="margin: 0px; padding: 0px; border: 0px;">2.8.4 數(shù)據(jù)異構(gòu)</u>
在大型網(wǎng)站架構(gòu)中槽地，數(shù)據(jù)庫(kù)都會(huì)采用分庫(kù)分表來解決容量和性能問題迁沫，但分庫(kù)分表之后帶來的新問題芦瘾。
比如不同維度的查詢或者聚合查詢，此時(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ì)安裝逃贝、配置與使用谣辞，請(qǐng)查閱官方文檔 >> 鏈接
三、帳號(hào)實(shí)踐
1沐扳、實(shí)踐一：分庫(kù)分表
1.1 需求
- 難點(diǎn)：
表數(shù)據(jù)量大泥从，單表3億多。
常規(guī)定時(shí)任務(wù)遷移全量數(shù)據(jù)沪摄，時(shí)間長(zhǎng)且對(duì)業(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ù)劃分不合理
確定分庫(kù)分表方案
存量數(shù)據(jù)遷移方案
使用傳統(tǒng)的定時(shí)任務(wù)遷移杨拐，時(shí)長(zhǎng)過長(zhǎng)祈餐，且遷移過程中為了保證數(shù)據(jù)一致性，需要停機(jī)維護(hù)哄陶，對(duì)用戶影響較大帆阳。
確定使用canal進(jìn)行遷移，對(duì)canal做充分調(diào)研與評(píng)估屋吨，與中間件及DBA共同確定蜒谤，可支持全量、以及增量同步至扰。
- 遷移過程通過開關(guān)進(jìn)行控制鳍徽，單表模式 → 雙寫模式 → 分表模式。
- 數(shù)據(jù)遷移周期長(zhǎng)敢课，遷移過程中遇到部分未能預(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í)踐二：跨國(guó)數(shù)據(jù)遷移
2.1 需求
在vivo海外業(yè)務(wù)開展初期馋记，海外部分國(guó)家的數(shù)據(jù)存儲(chǔ)在中立國(guó)新加坡機(jī)房，但隨著海外國(guó)家法律合規(guī)要求越來越嚴(yán)格懊烤，特別是歐盟地區(qū)的GDPR合規(guī)要求梯醒，vivo帳號(hào)應(yīng)對(duì)合規(guī)要求，做了比較多的合規(guī)改造工作腌紧。
部分非歐盟地區(qū)的國(guó)家合規(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ī)房搭建備庫(kù)，主從同步 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借宵。
- 在對(duì)應(yīng)時(shí)刻，Canal消費(fèi)到更新手機(jī)號(hào)A的Binlog矾削，導(dǎo)致用戶新?lián)Q綁的手機(jī)號(hào)做了覆蓋壤玫。
3.3 數(shù)據(jù)庫(kù)主從延時(shí)
出于數(shù)據(jù)一致性地考慮（結(jié)合帳號(hào)業(yè)務(wù)數(shù)據(jù)未達(dá)到需要分庫(kù)的必要性），帳號(hào)分表在同一數(shù)據(jù)庫(kù)進(jìn)行哼凯，即遷移過程中分表數(shù)據(jù)不斷地進(jìn)行寫入欲间，加大數(shù)據(jù)庫(kù)負(fù)載的同時(shí)造成了從庫(kù)讀取延時(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)易監(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ǔ)篇亭，且對(duì)線上數(shù)據(jù)影響較小缠捌。
四、拓展思考
1译蒂、現(xiàn)有問題分析
以上是基于 Canal現(xiàn)有架構(gòu)畫出的簡(jiǎn)易圖曼月，雖然基于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è)咳燕，大家對(duì)“異地多活”已經(jīng)耳熟能詳勿决，而數(shù)據(jù)同步是異地多活的基礎(chǔ)，所有具備數(shù)據(jù)存儲(chǔ)能力的組件如：數(shù)據(jù)庫(kù)招盲、緩存低缩、MQ等，數(shù)據(jù)都可以進(jìn)行同步曹货，形成一個(gè)龐大而復(fù)雜的數(shù)據(jù)同步拓?fù)渑胤保嗷浞輰?duì)方的數(shù)據(jù)，才能做到真正意義上"異地多活”顶籽。
本邏輯不在本次討論范圍內(nèi)玩般，大家可以參閱以下文章內(nèi)容，筆者個(gè)人認(rèn)為講解較為詳細(xì)
http://www.tianshouzhi.com/api/tutorials/canal/404
五礼饱、參考資料
來自：vivo的技術(shù)團(tuán)隊(duì)
