互聯網應用隨著業務的發展，部分單表數據體量越來越大，應對服務性能與穩定的考慮，有做分庫分表、數據遷移的需要，本文介紹了vivo帳號應對以上需求的實踐。

一、前言

Canal 是阿里巴巴開源項目，關于什么是 Canal？又能做什么？我會在后文為大家一一介紹。
在本文您將可以了解到vivo帳號使用 Canal 解決了什么樣的業務痛點，基于此希望對您所在業務能有一些啟示。

二、Canal介紹

1. 簡介

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

早期阿里巴巴因為杭州和美國雙機房部署，存在跨機房同步的業務需求，實現方式主要是基于業務 trigger 獲取增量變更。從 2010 年開始，業務逐步嘗試數據庫日志解析獲取增量變更進行同步，由此衍生出了大量的數據庫增量訂閱和消費業務。

2. 工作原理

?

2.1 MySQL 主備復制原理

Canal最核心的運行機制就是依賴于MySQL的主備復制，我們優先簡要說明下MySQL主備復制原理。

?

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

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

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

2.2 MySQL Binary Log介紹

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

如果后續我們需要配置主從數據庫，如果我們需要從數據庫同步主數據庫的內容，我們就可以通過 Binlog來進行同步。

2.3?Canal 工作原理

Canal 模擬MySQL slave的交互協議，偽裝自己為MySQL slave，向MySQL master發送dump協議。

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

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

Canal 把解析后的 binary log 以特定格式的進行推送，供下游消費。

2.4 Canal 整體架構

說明：

• server 代表一個canal運行實例，對應于一個jvm
• instance 對應于一個數據隊列 （1個server對應1..n個instance)

instance模塊：

• EventParser?(數據源接入，模擬slave協議和master進行交互，協議解析)
  與數據庫交互模擬從庫，發送dump binlog請求，接收binlog進行協議解析并做數據封裝，并將數據傳遞至下層EventSink進行存儲，記錄binlog同步位置。

• EventSink?(Parser和Store鏈接器，進行數據過濾，加工，分發的工作)
  數據過濾、數據歸并、數據加工、數據路由存儲。

• EventStore?(數據存儲)
  管理數據對象存儲，包括新binlog對象的寫入管理、對象訂閱的位置管理、對象消費成功的回執位置管理。

• MetaManager?(增量訂閱&消費信息管理器)

  負責binlog對象整體的發布訂閱管理器，類似于MQ。

2.5?Canal 數據格式

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

Canal能夠同步 DCL、 DML、 DDL。

業務通常關心 INSERT、 UPDATE、 DELETE引起的數據變更。

EntryProtocol.proto

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

?

2.6?Canal 示例 demo

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

• insert 語句

• delete語句

• update語句

2.7 Canal HA 機制

線上服務的穩定性極為重要，Canal是支持HA的，其實現機制也是依賴Zookeeper來實現的，與HDFS的HA類似。

Canal的HA分為兩部分，Canal server和Canal client分別有對應的HA實現。

• Canal Server：為了減少對mysql dump的請求，不同server上的instance要求同一時間只能有一個處于running，其他的處于standby狀態。
• Canal Client：為了保證有序性，一份instance同一時間只能由一個canal client進行get/ack/rollback操作，否則客戶端接收無法保證有序。

依賴Zookeeper的特性（本文不著重講解zookeeper特性，請在網絡上查找對應資料）：

• Watcher機制
• EPHEMERAL節點(和session生命周期綁定)

?

大致步驟：

Canal server要啟動某個canal instance時都先向zookeeper進行一次嘗試啟動判斷 (實現：創建EPHEMERAL節點，誰創建成功就允許誰啟動)。

創建 ZooKeeper節點成功后，對應的Canal server就啟動對應的Canal instance，沒有創建成功的Canal instance就會處于standby狀態。

一旦ZooKeeper發現Canal server A創建的節點消失后，立即通知其他的Canal server再次進行步驟1的操作，重新選出一個Canal server啟動instance。

Canal client每次進行connect時，會首先向ZooKeeper詢問當前是誰啟動了Canal instance，然后和其建立鏈接，一旦鏈接不可用，會重新嘗試connect。

2.8 Canal 使用場景

上面介紹了Canal 的原理與運行機制，下面我們從實際場景來看，Canal 能夠為我們業務場景解決什么樣的問題。

2.8.1 不停服遷移

業務在發展初期，為了快速支撐業務發展，很多數據存儲設計較為粗放，比如用戶表、訂單表可能都會設計為單表，此時常規手段會采用分庫分表來解決容量和性能問題。

但數據遷移會面臨最大的問題：線上業務需要正常運行，如果數據在遷移過程中有變更，如何保證數據一致性是最大的挑戰。

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

可詳見下方vivo帳號的不停機遷移實踐。

2.8.2?緩存刷新

互聯網業務數據源不僅僅為數據庫，比如 Redis 在互聯網業務較為常用，在數據變更時需要刷新緩存，常規手段是在業務邏輯代碼中手動刷新。

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

2.8.3?任務下發

另一種常見應用場景是“下發任務”，當數據變更時需要通知其他依賴系統。

其原理是任務系統監聽數據庫變更，然后將變更的數據寫入MQ/Kafka進行任務下發。

比如帳號注銷時下游業務方需要訂單此通知，為用戶刪除業務數據，或者做數據歸檔等。

基于Canal可以保證數據下發的精確性，同時業務系統中不會散落著各種下發MQ的代碼，從而實現了下發歸集，如下圖所示：

2.8.4 數據異構

在大型網站架構中，數據庫都會采用分庫分表來解決容量和性能問題，但分庫分表之后帶來的新問題。

比如不同維度的查詢或者聚合查詢，此時就會非常棘手。一般我們會通過數據異構機制來解決此問題。

所謂的數據異構，那就是將需要join查詢的多表按照某一個維度又聚合在一個DB中。

基于Canal可以實現數據異構，如下圖示意：

?

3、Canal 的安裝及使用

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

三、帳號實踐

1、實踐一：分庫分表

1.1 需求

• 難點：

表數據量大，單表3億多。

常規定時任務遷移全量數據，時間長且對業務有損。

• 核心訴求：

不停機遷移，最大化保證業務不受影響

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

1.2?遷移方案

1.3?遷移過程

整體過程大致如下：

• 分析帳號現有痛點

單表數據量過大：帳號單表3億+

用戶唯一標識過多

業務劃分不合理

• 確定分庫分表方案
• 存量數據遷移方案

使用傳統的定時任務遷移，時長過長，且遷移過程中為了保證數據一致性，需要停機維護，對用戶影響較大。

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

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

2、實踐二：跨國數據遷移

2.1 需求

在vivo海外業務開展初期，海外部分國家的數據存儲在中立國新加坡機房，但隨著海外國家法律合規要求越來越嚴格，特別是歐盟地區的GDPR合規要求，vivo帳號應對合規要求，做了比較多的合規改造工作。

部分非歐盟地區的國家合規要求隨之變化，舉例澳洲當地要求滿足GDPR合規要求，原有存儲在新加坡機房的澳洲用戶數據需要遷移至歐盟機房，整體遷移復雜度增加，其中涉及到的難點有：

• 不停機遷移，已出貨的手機用戶需要能正常訪問帳號服務。
• 數據一致性，用戶變更數據一致性需要保證。
• 業務方影響，不能影響現網業務方正常使用帳號服務。

2.2?遷移方案

2.3?遷移過程

• 在新加坡機房搭建備庫，主從同步 Binlog。
• 搭建 Canal 的server及client端，同步訂閱消費Ｂinlog。
• client端基于訂閱的Ｂinlog進行解析，將數據加密傳輸至歐盟GDPR機房。
• 歐盟應用數據解析傳輸的數據，落地存儲。
• 數據同步完成后運維同事協助將上層域名的DNS解析轉發至歐盟機房，完成數據切換。
• 觀察新加坡機房Canal服務運行情況，沒有異常后停止Canal服務。
• 通過業務方，帳號側完成切換。
• 待業務方同步切換完成后，將新加坡機房的數據清除。

3、經驗總結

3.1??數據序列化

Canal底層使用protobuf作為數據數據列化的方式，Canal-client在訂閱到變更數據時，為null的數據會自動轉換為空字符串，在ORM側數據更新時，因判斷邏輯不一致，導致最終表中數據更新為空字符串。

3.2??數據一致性

帳號本次線上Canal-client只有單節點，但在數據遷移過程中，因業務特性，導致數據出現了不一致的現象，示例大致如下：

• 用戶換綁手機號A。
• Canal此時在還未訂閱到此 Binlog position。
• 用戶又換綁手機號B。
• 在對應時刻，Canal消費到更新手機號A的Binlog，導致用戶新換綁的手機號做了覆蓋。

3.3?數據庫主從延時

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

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

3.4?監控告警

在整體數據遷移過程中，vivo帳號在client端增加了實時同步數據的簡易監控手段，即基于業務表基于內存做計數。

整體監控粒度較粗，包括以上數據不一致性，在數據同步完成后，未能發現異常，導致切換至分表模式下出現了業務問題，好在邏輯數據可以通過補償等其他手段彌補，且對線上數據影響較小。

四、拓展思考

1、現有問題分析

?

以上是基于 Canal現有架構畫出的簡易圖，雖然基于HA整體高可用，但細究后還是會發現一些隱患，其中標記紅色X的節點，可以視為可能出現的故障點。

2、通用組件復用

基于以上可能出現的問題點，我們可以嘗試做上圖中的優化。

?

?

3、延展應用-多數據中心同步

在互聯網行業，大家對“異地多活”已經耳熟能詳，而數據同步是異地多活的基礎，所有具備數據存儲能力的組件如：數據庫、緩存、MQ等，數據都可以進行同步，形成一個龐大而復雜的數據同步拓撲，相互備份對方的數據，才能做到真正意義上"異地多活”。

本邏輯不在本次討論范圍內，大家可以參閱以下文章內容，筆者個人認為講解較為詳細：http://www.tianshouzhi.com/api/tutorials/canal/404

五、參考資料

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

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

作者：vivo 產品平臺開發團隊

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。