互聯(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?(增量訂閱&消費信息管理器)

  負責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詢問當前是誰啟動了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ù)”，當數(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億+

用戶唯一標識過多

業(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ī)要求越來越嚴格，特別是歐盟地區(qū)的GDPR合規(guī)要求，vivo帳號應(yīng)對合規(guī)要求，做了比較多的合規(guī)改造工作。

部分非歐盟地區(qū)的國家合規(guī)要求隨之變化，舉例澳洲當?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端，同步訂閱消費Ｂinlog。
• client端基于訂閱的Ｂinlog進行解析，將數(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ù)更新時，因判斷邏輯不一致，導致最終表中數(shù)據(jù)更新為空字符串。

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

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

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

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

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

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

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)異常，導致切換至分表模式下出現(xiàn)了業(yè)務(wù)問題，好在邏輯數(shù)據(jù)可以通過補償?shù)绕渌侄螐浹a，且對線上數(shù)據(jù)影響較小。

四、拓展思考

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

?

以上是基于 Canal現(xiàn)有架構(gòu)畫出的簡易圖，雖然基于HA整體高可用，但細究后還是會發(fā)現(xiàn)一些隱患，其中標記紅色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ù)同步拓撲，相互備份對方的數(shù)據(jù)，才能做到真正意義上"異地多活”。

本邏輯不在本次討論范圍內(nèi)，大家可以參閱以下文章內(nèi)容，筆者個人認為講解較為詳細：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)容，希望文章能夠幫你解決所遇到的問題。

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