Canal 组件简介与 vivo 帐号实践
互聯(lián)網(wǎng)應(yīng)用隨著業(yè)務(wù)的發(fā)展,部分單表數(shù)據(jù)體量越來越大,應(yīng)對服務(wù)性能與穩(wěn)定的考慮,有做分庫分表、數(shù)據(jù)遷移的需要,本文介紹了vivo帳號應(yīng)對以上需求的實踐。
一、前言
Canal 是阿里巴巴開源項目,關(guān)于什么是 Canal?又能做什么?我會在后文為大家一一介紹。
在本文您將可以了解到vivo帳號使用 Canal 解決了什么樣的業(yè)務(wù)痛點,基于此希望對您所在業(yè)務(wù)能有一些啟示。
二、Canal介紹
1. 簡介
Canal [k?'n?l],譯意為水道/管道/溝渠,主要用途是基于 MySQL 數(shù)據(jù)庫增量日志解析,提供增量數(shù)據(jù)訂閱和消費。
早期阿里巴巴因為杭州和美國雙機房部署,存在跨機房同步的業(yè)務(wù)需求,實現(xiàn)方式主要是基于業(yè)務(wù) trigger 獲取增量變更。從 2010 年開始,業(yè)務(wù)逐步嘗試數(shù)據(jù)庫日志解析獲取增量變更進行同步,由此衍生出了大量的數(shù)據(jù)庫增量訂閱和消費業(yè)務(wù)。
2. 工作原理
?
2.1 MySQL 主備復(fù)制原理
Canal最核心的運行機制就是依賴于MySQL的主備復(fù)制,我們優(yōu)先簡要說明下MySQL主備復(fù)制原理。
?
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運行實例,對應(yīng)于一個jvm
- instance 對應(yīng)于一個數(shù)據(jù)隊列 (1個server對應(yīng)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?(增量訂閱&消費信息管理器)
負(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ā)生的時間戳]schemaName [數(shù)據(jù)庫實例]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個binlog event事件可對應(yīng)多條變更,比如批處理]beforeColumns [Column類型的數(shù)組]afterColumns [Column類型的數(shù)組]Columnindex [column序號]sqlType [jdbc type]name [column name]isKey [是否為主鍵]updated [是否發(fā)生過變更]isNull [值是否為null]value [具體的內(nèi)容,注意為文本]?
2.6?Canal 示例 demo
下面我們通過實際代碼邏輯的判斷,查看 Binlog解析成Canal 對象的數(shù)據(jù)模型,加深理解
- insert 語句
- delete語句
-
update語句
2.7 Canal HA 機制
線上服務(wù)的穩(wěn)定性極為重要,Canal是支持HA的,其實現(xiàn)機制也是依賴Zookeeper來實現(xiàn)的,與HDFS的HA類似。
Canal的HA分為兩部分,Canal server和Canal client分別有對應(yīng)的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)絡(luò)上查找對應(yīng)資料):
- Watcher機制
- EPHEMERAL節(jié)點(和session生命周期綁定)
?
大致步驟:
Canal server要啟動某個canal instance時都先向zookeeper進行一次嘗試啟動判斷 (實現(xiàn):創(chuàng)建EPHEMERAL節(jié)點,誰創(chuàng)建成功就允許誰啟動)。
創(chuàng)建 ZooKeeper節(jié)點成功后,對應(yīng)的Canal server就啟動對應(yīng)的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詢問當(dāng)前是誰啟動了Canal instance,然后和其建立鏈接,一旦鏈接不可用,會重新嘗試connect。
2.8 Canal 使用場景
上面介紹了Canal 的原理與運行機制,下面我們從實際場景來看,Canal 能夠為我們業(yè)務(wù)場景解決什么樣的問題。
2.8.1 不停服遷移
業(yè)務(wù)在發(fā)展初期,為了快速支撐業(yè)務(wù)發(fā)展,很多數(shù)據(jù)存儲設(shè)計較為粗放,比如用戶表、訂單表可能都會設(shè)計為單表,此時常規(guī)手段會采用分庫分表來解決容量和性能問題。
但數(shù)據(jù)遷移會面臨最大的問題:線上業(yè)務(wù)需要正常運行,如果數(shù)據(jù)在遷移過程中有變更,如何保證數(shù)據(jù)一致性是最大的挑戰(zhàn)。
基于Canal,通過訂閱數(shù)據(jù)庫的 Binlog,可以很好地解決這一問題。
可詳見下方vivo帳號的不停機遷移實踐。
2.8.2?緩存刷新
互聯(lián)網(wǎng)業(yè)務(wù)數(shù)據(jù)源不僅僅為數(shù)據(jù)庫,比如 Redis 在互聯(lián)網(wǎng)業(yè)務(wù)較為常用,在數(shù)據(jù)變更時需要刷新緩存,常規(guī)手段是在業(yè)務(wù)邏輯代碼中手動刷新。
基于Canal,通過訂閱指定表數(shù)據(jù)的Binlog,可以異步解耦刷新緩存。
2.8.3?任務(wù)下發(fā)
另一種常見應(yīng)用場景是“下發(fā)任務(wù)”,當(dāng)數(shù)據(jù)變更時需要通知其他依賴系統(tǒng)。
其原理是任務(wù)系統(tǒng)監(jiān)聽數(shù)據(jù)庫變更,然后將變更的數(shù)據(jù)寫入MQ/Kafka進行任務(wù)下發(fā)。
比如帳號注銷時下游業(yè)務(wù)方需要訂單此通知,為用戶刪除業(yè)務(wù)數(shù)據(jù),或者做數(shù)據(jù)歸檔等。
基于Canal可以保證數(shù)據(jù)下發(fā)的精確性,同時業(yè)務(wù)系統(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ī)定時任務(wù)遷移全量數(shù)據(jù),時間長且對業(yè)務(wù)有損。
- 核心訴求:
不停機遷移,最大化保證業(yè)務(wù)不受影響
“給在公路上跑著的車換輪胎”
1.2?遷移方案
1.3?遷移過程
整體過程大致如下:
- 分析帳號現(xiàn)有痛點
單表數(shù)據(jù)量過大:帳號單表3億+
用戶唯一標(biāo)識過多
業(yè)務(wù)劃分不合理
- 確定分庫分表方案
- 存量數(shù)據(jù)遷移方案
使用傳統(tǒng)的定時任務(wù)遷移,時長過長,且遷移過程中為了保證數(shù)據(jù)一致性,需要停機維護,對用戶影響較大。
確定使用canal進行遷移,對canal做充分調(diào)研與評估,與中間件及DBA共同確定,可支持全量、以及增量同步。
- 遷移過程通過開關(guān)進行控制,單表模式?→ 雙寫模式?→ 分表模式。
- 數(shù)據(jù)遷移周期長,遷移過程中遇到部分未能預(yù)估到的問題,進行了多次遷移。
- 遷移完成后,正式切換至雙寫模式,即單表及分表同樣寫入數(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è)務(wù)開展初期,海外部分國家的數(shù)據(jù)存儲在中立國新加坡機房,但隨著海外國家法律合規(guī)要求越來越嚴(yán)格,特別是歐盟地區(qū)的GDPR合規(guī)要求,vivo帳號應(yīng)對合規(guī)要求,做了比較多的合規(guī)改造工作。
部分非歐盟地區(qū)的國家合規(guī)要求隨之變化,舉例澳洲當(dāng)?shù)匾鬂M足GDPR合規(guī)要求,原有存儲在新加坡機房的澳洲用戶數(shù)據(jù)需要遷移至歐盟機房,整體遷移復(fù)雜度增加,其中涉及到的難點有:
- 不停機遷移,已出貨的手機用戶需要能正常訪問帳號服務(wù)。
- 數(shù)據(jù)一致性,用戶變更數(shù)據(jù)一致性需要保證。
- 業(yè)務(wù)方影響,不能影響現(xiàn)網(wǎng)業(yè)務(wù)方正常使用帳號服務(wù)。
2.2?遷移方案
2.3?遷移過程
- 在新加坡機房搭建備庫,主從同步 Binlog。
- 搭建 Canal 的server及client端,同步訂閱消費Binlog。
- client端基于訂閱的Binlog進行解析,將數(shù)據(jù)加密傳輸至歐盟GDPR機房。
- 歐盟應(yīng)用數(shù)據(jù)解析傳輸?shù)臄?shù)據(jù),落地存儲。
- 數(shù)據(jù)同步完成后運維同事協(xié)助將上層域名的DNS解析轉(zhuǎn)發(fā)至歐盟機房,完成數(shù)據(jù)切換。
- 觀察新加坡機房Canal服務(wù)運行情況,沒有異常后停止Canal服務(wù)。
- 通過業(yè)務(wù)方,帳號側(cè)完成切換。
- 待業(yè)務(wù)方同步切換完成后,將新加坡機房的數(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ù)更新時,因判斷邏輯不一致,導(dǎo)致最終表中數(shù)據(jù)更新為空字符串。
3.2??數(shù)據(jù)一致性
帳號本次線上Canal-client只有單節(jié)點,但在數(shù)據(jù)遷移過程中,因業(yè)務(wù)特性,導(dǎo)致數(shù)據(jù)出現(xiàn)了不一致的現(xiàn)象,示例大致如下:
- 用戶換綁手機號A。
- Canal此時在還未訂閱到此 Binlog position。
- 用戶又換綁手機號B。
- 在對應(yīng)時刻,Canal消費到更新手機號A的Binlog,導(dǎo)致用戶新?lián)Q綁的手機號做了覆蓋。
3.3?數(shù)據(jù)庫主從延時
出于數(shù)據(jù)一致性地考慮(結(jié)合帳號業(yè)務(wù)數(shù)據(jù)未達到需要分庫的必要性),帳號分表在同一數(shù)據(jù)庫進行,即遷移過程中分表數(shù)據(jù)不斷地進行寫入,加大數(shù)據(jù)庫負(fù)載的同時造成了從庫讀取延時。
解決方案:增加速率控制,基于業(yè)務(wù)的實際情況,配置不同的策略,例如白天業(yè)務(wù)量大,可以適當(dāng)降低寫入速度,夜間業(yè)務(wù)量小,可以適當(dāng)提升寫入速度。
3.4?監(jiān)控告警
在整體數(shù)據(jù)遷移過程中,vivo帳號在client端增加了實時同步數(shù)據(jù)的簡易監(jiān)控手段,即基于業(yè)務(wù)表基于內(nèi)存做計數(shù)。
整體監(jiān)控粒度較粗,包括以上數(shù)據(jù)不一致性,在數(shù)據(jù)同步完成后,未能發(fā)現(xiàn)異常,導(dǎo)致切換至分表模式下出現(xiàn)了業(yè)務(wù)問題,好在邏輯數(shù)據(jù)可以通過補償?shù)绕渌侄螐浹a,且對線上數(shù)據(jù)影響較小。
四、拓展思考
1、現(xiàn)有問題分析
?
以上是基于 Canal現(xiàn)有架構(gòu)畫出的簡易圖,雖然基于HA整體高可用,但細究后還是會發(fā)現(xiàn)一些隱患,其中標(biāo)記紅色X的節(jié)點,可以視為可能出現(xiàn)的故障點。
2、通用組件復(fù)用
基于以上可能出現(xiàn)的問題點,我們可以嘗試做上圖中的優(yōu)化。
?
?
3、延展應(yīng)用-多數(shù)據(jù)中心同步
在互聯(lián)網(wǎng)行業(yè),大家對“異地多活”已經(jīng)耳熟能詳,而數(shù)據(jù)同步是異地多活的基礎(chǔ),所有具備數(shù)據(jù)存儲能力的組件如:數(shù)據(jù)庫、緩存、MQ等,數(shù)據(jù)都可以進行同步,形成一個龐大而復(fù)雜的數(shù)據(jù)同步拓?fù)?#xff0c;相互備份對方的數(shù)據(jù),才能做到真正意義上"異地多活”。
本邏輯不在本次討論范圍內(nèi),大家可以參閱以下文章內(nèi)容,筆者個人認(rèn)為講解較為詳細:http://www.tianshouzhi.com/api/tutorials/canal/404
五、參考資料
-
https://github.com/alibaba/canal
-
https://github.com/alibaba/otter
作者:vivo 產(chǎn)品平臺開發(fā)團隊
總結(jié)
以上是生活随笔為你收集整理的Canal 组件简介与 vivo 帐号实践的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 计算机网络mtu值设置,Win7修改本地
- 下一篇: Android studio 微信APP