互聯(lián)網(wǎng)應用隨著業(yè)務的發(fā)展胁塞，部分單表數(shù)據(jù)體量越來越大咏尝，應對服務性能與穩(wěn)定的考慮，有做分庫分表啸罢、數(shù)據(jù)遷移的需要编检，本文介紹了vivo帳號應對以上需求的實踐。
一扰才、前言
Canal 是阿里巴巴開源項目允懂，關(guān)于什么是 Canal？又能做什么衩匣？我會在后文為大家一一介紹蕾总。
在本文您將可以了解到vivo帳號使用 Canal 解決了什么樣的業(yè)務痛點，基于此希望對您所在業(yè)務能有一些啟示琅捏。
二生百、Canal介紹
1. 簡介
Canal [k?'n?l]，譯意為水道/管道/溝渠柄延，主要用途是基于 MySQL 數(shù)據(jù)庫增量日志解析蚀浆，提供增量數(shù)據(jù)訂閱和消費。
早期阿里巴巴因為杭州和美國雙機房部署，存在跨機房同步的業(yè)務需求市俊，實現(xiàn)方式主要是基于業(yè)務 trigger 獲取增量變更杨凑。從 2010 年開始，業(yè)務逐步嘗試數(shù)據(jù)庫日志解析獲取增量變更進行同步摆昧，由此衍生出了大量的數(shù)據(jù)庫增量訂閱和消費業(yè)務撩满。
2. 工作原理
2.1 MySQL 主備復制原理
Canal最核心的運行機制就是依賴于MySQL的主備復制，我們優(yōu)先簡要說明下MySQL主備復制原理据忘。
MySQL master 將數(shù)據(jù)變更寫入二進制日志( binary log, 其中記錄叫做二進制日志事件binary log events鹦牛，可以通過 show binlog events 進行查看)。
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ù)庫的二進制日志汉规，用于記錄用戶對數(shù)據(jù)庫操作的SQL語句（除了數(shù)據(jù)查詢語句）信息礼殊。
如果后續(xù)我們需要配置主從數(shù)據(jù)庫晶伦，如果我們需要從數(shù)據(jù)庫同步主數(shù)據(jù)庫的內(nèi)容，我們就可以通過 Binlog來進行同步。
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 以特定格式的進行推送微猖，供下游消費逻炊。
2.4 Canal 整體架構(gòu)
說明：
server 代表一個canal運行實例，對應于一個jvm
instance 對應于一個數(shù)據(jù)隊列 （1個server對應1..n個instance)
instance模塊：
EventParser(數(shù)據(jù)源接入犁享，模擬slave協(xié)議和master進行交互余素，協(xié)議解析)
與數(shù)據(jù)庫交互模擬從庫，發(fā)送dump binlog請求炊昆，接收binlog進行協(xié)議解析并做數(shù)據(jù)封裝桨吊，并將數(shù)據(jù)傳遞至下層EventSink進行存儲威根，記錄binlog同步位置。EventSink(Parser和Store鏈接器视乐，進行數(shù)據(jù)過濾洛搀，加工，分發(fā)的工作)
數(shù)據(jù)過濾佑淀、數(shù)據(jù)歸并留美、數(shù)據(jù)加工、數(shù)據(jù)路由存儲伸刃。EventStore(數(shù)據(jù)存儲)
管理數(shù)據(jù)對象存儲谎砾，包括新binlog對象的寫入管理、對象訂閱的位置管理捧颅、對象消費成功的回執(zhí)位置管理景图。-
MetaManager(增量訂閱&消費信息管理器)
負責binlog對象整體的發(fā)布訂閱管理器，類似于MQ隘道。
2.5 Canal 數(shù)據(jù)格式
下面我們來一起看下Canal內(nèi)部封裝的 Binlog對象格式症歇，更好的理解 Canal。
Canal能夠同步 DCL谭梗、 DML忘晤、 DDL。
業(yè)務通常關(guān)心 INSERT激捏、 UPDATE设塔、 DELETE引起的數(shù)據(jù)變更。
EntryProtocol.proto
Entry
Header
logfileName [binlog文件名]
logfileOffset [binlog position]
executeTime [binlog里記錄變更發(fā)生的時間戳]
schemaName [數(shù)據(jù)庫實例]
tableName [表名]
eventType [insert/update/delete類型]
entryType [事務頭BEGIN/事務尾END/數(shù)據(jù)ROWDATA]
storeValue [byte數(shù)據(jù),可展開远舅，對應的類型為RowChange]
RowChange
isDdl [是否是ddl變更操作闰蛔，比如create table/drop table]
sql [具體的ddl sql]
rowDatas [具體insert/update/delete的變更數(shù)據(jù)，可為多條图柏，1個binlog event事件可對應多條變更序六，比如批處理]
beforeColumns [Column類型的數(shù)組]
afterColumns [Column類型的數(shù)組]
Column
index [column序號]
sqlType [jdbc type]
name [column name]
isKey [是否為主鍵]
updated [是否發(fā)生過變更]
isNull [值是否為null]
value [具體的內(nèi)容，注意為文本]
2.6 Canal 示例 demo
下面我們通過實際代碼邏輯的判斷蚤吹，查看 Binlog解析成Canal 對象的數(shù)據(jù)模型例诀，加深理解
-
insert 語句
05.png -
delete語句
06.png -
update語句
07.png
2.7 Canal HA 機制
線上服務的穩(wěn)定性極為重要，Canal是支持HA的裁着，其實現(xiàn)機制也是依賴Zookeeper來實現(xiàn)的繁涂，與HDFS的HA類似。
Canal的HA分為兩部分二驰，Canal server和Canal client分別有對應的HA實現(xiàn)扔罪。
Canal Server：為了減少對mysql dump的請求，不同server上的instance要求同一時間只能有一個處于running桶雀，其他的處于standby狀態(tài)矿酵。
Canal Client：為了保證有序性唬复，一份instance同一時間只能由一個canal client進行g(shù)et/ack/rollback操作，否則客戶端接收無法保證有序坏瘩。
依賴Zookeeper的特性（本文不著重講解zookeeper特性盅抚，請在網(wǎng)絡上查找對應資料）：
Watcher機制
EPHEMERAL節(jié)點(和session生命周期綁定)
大致步驟：
Canal server要啟動某個canal instance時都先向zookeeper進行一次嘗試啟動判斷 (實現(xiàn)：創(chuàng)建EPHEMERAL節(jié)點，誰創(chuàng)建成功就允許誰啟動)倔矾。
創(chuàng)建 ZooKeeper節(jié)點成功后，對應的Canal server就啟動對應的Canal instance柱锹，沒有創(chuàng)建成功的Canal instance就會處于standby狀態(tài)哪自。
一旦ZooKeeper發(fā)現(xiàn)Canal server A創(chuàng)建的節(jié)點消失后，立即通知其他的Canal server再次進行步驟1的操作禁熏，重新選出一個Canal server啟動instance壤巷。
Canal client每次進行connect時，會首先向ZooKeeper詢問當前是誰啟動了Canal instance瞧毙，然后和其建立鏈接胧华，一旦鏈接不可用，會重新嘗試connect宙彪。
2.8 Canal 使用場景
上面介紹了Canal 的原理與運行機制矩动，下面我們從實際場景來看，Canal 能夠為我們業(yè)務場景解決什么樣的問題释漆。
2.8.1 不停服遷移
業(yè)務在發(fā)展初期悲没，為了快速支撐業(yè)務發(fā)展，很多數(shù)據(jù)存儲設計較為粗放男图，比如用戶表示姿、訂單表可能都會設計為單表，此時常規(guī)手段會采用分庫分表來解決容量和性能問題逊笆。
但數(shù)據(jù)遷移會面臨最大的問題：線上業(yè)務需要正常運行栈戳，如果數(shù)據(jù)在遷移過程中有變更，如何保證數(shù)據(jù)一致性是最大的挑戰(zhàn)难裆。
基于Canal子檀，通過訂閱數(shù)據(jù)庫的 Binlog，可以很好地解決這一問題差牛。
可詳見下方vivo帳號的不停機遷移實踐命锄。
2.8.2 緩存刷新
互聯(lián)網(wǎng)業(yè)務數(shù)據(jù)源不僅僅為數(shù)據(jù)庫，比如 Redis 在互聯(lián)網(wǎng)業(yè)務較為常用偏化，在數(shù)據(jù)變更時需要刷新緩存脐恩，常規(guī)手段是在業(yè)務邏輯代碼中手動刷新。
基于Canal侦讨，通過訂閱指定表數(shù)據(jù)的Binlog驶冒，可以異步解耦刷新緩存苟翻。
2.8.3 任務下發(fā)
另一種常見應用場景是“下發(fā)任務”，當數(shù)據(jù)變更時需要通知其他依賴系統(tǒng)骗污。
其原理是任務系統(tǒng)監(jiān)聽數(shù)據(jù)庫變更崇猫，然后將變更的數(shù)據(jù)寫入MQ/Kafka進行任務下發(fā)。
比如帳號注銷時下游業(yè)務方需要訂單此通知需忿，為用戶刪除業(yè)務數(shù)據(jù)诅炉，或者做數(shù)據(jù)歸檔等。
基于Canal可以保證數(shù)據(jù)下發(fā)的精確性屋厘，同時業(yè)務系統(tǒng)中不會散落著各種下發(fā)MQ的代碼涕烧，從而實現(xiàn)了下發(fā)歸集，如下圖所示：
2.8.4 數(shù)據(jù)異構(gòu)
在大型網(wǎng)站架構(gòu)中汗洒，數(shù)據(jù)庫都會采用分庫分表來解決容量和性能問題议纯，但分庫分表之后帶來的新問題。
比如不同維度的查詢或者聚合查詢溢谤，此時就會非常棘手瞻凤。一般我們會通過數(shù)據(jù)異構(gòu)機制來解決此問題。
所謂的數(shù)據(jù)異構(gòu)世杀，那就是將需要join查詢的多表按照某一個維度又聚合在一個DB中阀参。
基于Canal可以實現(xiàn)數(shù)據(jù)異構(gòu)，如下圖示意：
3玫坛、Canal 的安裝及使用
Canal的詳細安裝结笨、配置與使用，請查閱官方文檔 >> 鏈接
三湿镀、帳號實踐
1炕吸、實踐一：分庫分表
1.1 需求
- 難點：
表數(shù)據(jù)量大，單表3億多勉痴。
常規(guī)定時任務遷移全量數(shù)據(jù)赫模，時間長且對業(yè)務有損。
- 核心訴求：
不停機遷移蒸矛，最大化保證業(yè)務不受影響
“給在公路上跑著的車換輪胎”
1.2 遷移方案
1.3 遷移過程
整體過程大致如下：
- 分析帳號現(xiàn)有痛點
單表數(shù)據(jù)量過大：帳號單表3億+
用戶唯一標識過多
業(yè)務劃分不合理
確定分庫分表方案
存量數(shù)據(jù)遷移方案
使用傳統(tǒng)的定時任務遷移瀑罗，時長過長，且遷移過程中為了保證數(shù)據(jù)一致性雏掠，需要停機維護斩祭，對用戶影響較大。
確定使用canal進行遷移乡话，對canal做充分調(diào)研與評估摧玫，與中間件及DBA共同確定，可支持全量绑青、以及增量同步诬像。
遷移過程通過開關(guān)進行控制屋群，單表模式 → 雙寫模式 → 分表模式。
數(shù)據(jù)遷移周期長坏挠，遷移過程中遇到部分未能預估到的問題芍躏，進行了多次遷移。
遷移完成后降狠，正式切換至雙寫模式对竣，即單表及分表同樣寫入數(shù)據(jù)，此時數(shù)據(jù)讀取仍然在單表模式下讀取數(shù)據(jù)喊熟，Canal仍然訂閱原有單表柏肪，進行數(shù)據(jù)變更。
運行兩周后線上未產(chǎn)生新問題芥牌，正式切至分表模式，此時原有單表不再寫入數(shù)據(jù)聂使，即單表不會再有新的Binlog產(chǎn)生壁拉，切換后線上出現(xiàn)了部分問題，即時跟進處理柏靶，“有驚無險”弃理。
2、實踐二：跨國數(shù)據(jù)遷移
2.1 需求
在vivo海外業(yè)務開展初期屎蜓，海外部分國家的數(shù)據(jù)存儲在中立國新加坡機房痘昌，但隨著海外國家法律合規(guī)要求越來越嚴格，特別是歐盟地區(qū)的GDPR合規(guī)要求炬转，vivo帳號應對合規(guī)要求辆苔，做了比較多的合規(guī)改造工作。
部分非歐盟地區(qū)的國家合規(guī)要求隨之變化扼劈，舉例澳洲當?shù)匾鬂M足GDPR合規(guī)要求驻啤，原有存儲在新加坡機房的澳洲用戶數(shù)據(jù)需要遷移至歐盟機房，整體遷移復雜度增加荐吵，其中涉及到的難點有：
不停機遷移骑冗，已出貨的手機用戶需要能正常訪問帳號服務治泥。
數(shù)據(jù)一致性诈胜，用戶變更數(shù)據(jù)一致性需要保證。
業(yè)務方影響璃赡，不能影響現(xiàn)網(wǎng)業(yè)務方正常使用帳號服務薯蝎。
2.2 遷移方案
2.3 遷移過程
在新加坡機房搭建備庫遥倦，主從同步 Binlog。
搭建 Canal 的server及client端良风，同步訂閱消費Ｂinlog谊迄。
client端基于訂閱的Ｂinlog進行解析闷供，將數(shù)據(jù)加密傳輸至歐盟GDPR機房。
歐盟應用數(shù)據(jù)解析傳輸?shù)臄?shù)據(jù)统诺，落地存儲歪脏。
數(shù)據(jù)同步完成后運維同事協(xié)助將上層域名的DNS解析轉(zhuǎn)發(fā)至歐盟機房，完成數(shù)據(jù)切換粮呢。
觀察新加坡機房Canal服務運行情況婿失，沒有異常后停止Canal服務。
通過業(yè)務方啄寡，帳號側(cè)完成切換豪硅。
待業(yè)務方同步切換完成后，將新加坡機房的數(shù)據(jù)清除挺物。
3懒浮、經(jīng)驗總結(jié)
3.1****數(shù)據(jù)序列化
Canal底層使用protobuf作為數(shù)據(jù)數(shù)據(jù)列化的方式，Canal-client在訂閱到變更數(shù)據(jù)時识藤，為null的數(shù)據(jù)會自動轉(zhuǎn)換為空字符串砚著，在ORM側(cè)數(shù)據(jù)更新時，因判斷邏輯不一致痴昧，導致最終表中數(shù)據(jù)更新為空字符串稽穆。
3.2 ****數(shù)據(jù)一致性
帳號本次線上Canal-client只有單節(jié)點，但在數(shù)據(jù)遷移過程中赶撰，因業(yè)務特性舌镶，導致數(shù)據(jù)出現(xiàn)了不一致的現(xiàn)象，示例大致如下：
用戶換綁手機號A豪娜。
Canal此時在還未訂閱到此 Binlog position餐胀。
用戶又換綁手機號B。
在對應時刻侵歇，Canal消費到更新手機號A的Binlog骂澄，導致用戶新?lián)Q綁的手機號做了覆蓋。
3.3 ****數(shù)據(jù)庫主從延時
出于數(shù)據(jù)一致性地考慮（結(jié)合帳號業(yè)務數(shù)據(jù)未達到需要分庫的必要性）惕虑，帳號分表在同一數(shù)據(jù)庫進行坟冲，即遷移過程中分表數(shù)據(jù)不斷地進行寫入，加大數(shù)據(jù)庫負載的同時造成了從庫讀取延時溃蔫。
解決方案：增加速率控制健提，基于業(yè)務的實際情況，配置不同的策略伟叛，例如白天業(yè)務量大私痹，可以適當降低寫入速度，夜間業(yè)務量小，可以適當提升寫入速度紊遵。
3.4 ****監(jiān)控告警
在整體數(shù)據(jù)遷移過程中账千，vivo帳號在client端增加了實時同步數(shù)據(jù)的簡易監(jiān)控手段，即基于業(yè)務表基于內(nèi)存做計數(shù)暗膜。
整體監(jiān)控粒度較粗匀奏，包括以上數(shù)據(jù)不一致性，在數(shù)據(jù)同步完成后学搜，未能發(fā)現(xiàn)異常娃善，導致切換至分表模式下出現(xiàn)了業(yè)務問題，好在邏輯數(shù)據(jù)可以通過補償?shù)绕渌侄螐浹a瑞佩，且對線上數(shù)據(jù)影響較小聚磺。
四、拓展思考
1炬丸、現(xiàn)有問題分析
以上是基于 Canal現(xiàn)有架構(gòu)畫出的簡易圖瘫寝，雖然基于HA整體高可用，但細究后還是會發(fā)現(xiàn)一些隱患稠炬，其中標記紅色X的節(jié)點矢沿，可以視為可能出現(xiàn)的故障點。
2酸纲、通用組件復用
基于以上可能出現(xiàn)的問題點，我們可以嘗試做上圖中的優(yōu)化瑟匆。
3闽坡、延展應用-多數(shù)據(jù)中心同步
在互聯(lián)網(wǎng)行業(yè)，大家對“異地多活”已經(jīng)耳熟能詳愁溜，而數(shù)據(jù)同步是異地多活的基礎疾嗅，所有具備數(shù)據(jù)存儲能力的組件如：數(shù)據(jù)庫、緩存冕象、MQ等代承，數(shù)據(jù)都可以進行同步，形成一個龐大而復雜的數(shù)據(jù)同步拓撲渐扮，相互備份對方的數(shù)據(jù)论悴，才能做到真正意義上"異地多活”。
本邏輯不在本次討論范圍內(nèi)墓律，大家可以參閱以下文章內(nèi)容膀估，筆者個人認為講解較為詳細：http://www.tianshouzhi.com/api/tutorials/canal/404
五、參考資料
作者：vivo 產(chǎn)品平臺開發(fā)團隊
