一個分散式 MySQL Binlog 儲存系統的架構設計

摘要： 1. kingbus簡介 1.1 kingbus是什麼？ kingbus是一個基於raft強一致協議實現的分散式MySQL binlog 儲存系統。它能夠充當一個MySQL Slave從真正的Master上同步binglog，並存儲在分散式叢集中。同時又充當一個MySQL Master...

1. kingbus簡介

1.1 kingbus是什麼？

kingbus是一個基於raft強一致協議實現的分散式MySQL binlog 儲存系統。它能夠充當一個MySQL Slave從真正的Master上同步binglog，並存儲在分散式叢集中。同時又充當一個MySQL Master將叢集中的binlog 同步給其他Slave。 kingbus具有如下特性：

• 相容MySQL 複製協議，通過Gtid方式同步Master上的binlog，同時支援slave通過Gtid方式從kingbus拉取binlog。
• 跨地域資料複製，kingbus通過raft協議支援跨地域間的資料複製。寫入到叢集的binlog資料在多個節點間保證強一致，並保證binlog順序與master上完全一致。
• 高可用，由於kingbus是構建在Raft強一致協議之上，能夠實現叢集中過半數節點存活的情況下，整個binlog拉取和推送服務高可用。

1.2 kingbus能解決什麼問題？

• kingbus能降低Master的網路傳輸流量。在一主多從的複製拓撲中，Master需要傳送binlog到各個slave，如果slave過多的話，網路流量很有可能達到Master的網絡卡上限。例如在Master執行delete大表或者online DDL等操作，都有可能造成瞬間生成大量的binlog event，如果master下面掛10臺slave的話，master上的網絡卡流量就會放大10倍。如果master使用千兆網絡卡，產生了10MB/S以上的流量就有可能將其網絡卡跑滿。通過kingbus連線master的方式，可以將slave分散到多臺機器上，從而均衡傳輸流量。
• 簡化Master Failover流程，只需將連線在kingbus上的一臺Slave提升為Master，並將kingbus重新指向新的Master，其他slave依舊連線在kingbus上，複製拓撲保持不變。
• 節省Master儲存binlog檔案的空間。一般MySQL上都是較為昂貴的SSD，如果binlog檔案佔用空間較多，就使得MySQL儲存的資料不得不降低。可以通過將binlog都儲存到kingbus中，從而降低Master上binlog檔案的儲存數量
• 支援異構複製。通過阿里巴巴開源的canal連線到kingbus，kingbus源源不斷推送binlog給canal，canal接收完binlog再推送給kafka訊息佇列，最終存入HBase裡，業務部門通過Hive直接寫SQL的方式來實現業務的實時分析。

2.kingbus總體架構

kingbus整體架構如下圖所示：

• storage負責儲存raft log entry和Metadata，在kingbus中，將raft log和mysql binlog融合在一起了，通過不同的頭部資訊區分，raft log的資料部分就是binlog event，這樣就不需要分開儲存兩類log，節省儲存空間。因為kingbus需要儲存一些元資訊，例如raft 節點投票資訊、某些特殊binlog event的具體內容（FORMAT_DESCRIPTION_EVENT）。
• raft複製kingbus叢集的Lead選舉、日誌複製等功能，使用的是etcd raft library。
• binlog syncer，只執行在Raft叢集的Lead節點上，整個叢集只有一個syncer。syncer偽裝成一個slave，向Master建立主從複製連線，Master會根據syncer傳送的executed_gtid_set過濾syncer已經接受的binlog event，只發送syncer沒有接收過的binlog event，這套複製協議完全相容MySQL 主從複製機制。syncer收到binlog event後，會根據binlog event型別做一些處理，然後將binlog event封裝成一個訊息提交到raft 叢集中。通過raft演算法，這個binlog event就可以在多個節點儲存，並達到強一致的效果。
• binlog server，就是一個實現了複製協議的Master，真正的slave可以連線到binlog server監聽的埠，binlog server會將binlog event傳送給slave，整個傳送binlog event的過程參照MySQL 複製協議實現。當沒有binlog event傳送給slave時，binlog server會定期傳送heartbeat event給slave，保活複製連線。
• api server，負責整個kingbus叢集的管理，包括以下內容：
  • raft cluster membership操作，檢視叢集狀態，新增一個節點、移除一個節點，更新節點資訊等
  • binlog syncer相關操作，啟動一個binlog syncer，停止binlog syncer，檢視binlog syncer狀態。
  • binlog server相關操作，啟動一個binlog server，停止binlog server，檢視binlog server狀態。 server層的各種異常，都不會影響到raft層，server可以理解為一種外掛，按需啟動和停止。以後擴充套件kingbus時，只需要實現相關邏輯的server就行。例如實現一個kafka協議的server，那麼就可以通過kafka client消費kingbus中的訊息。

3.kingbus核心實現

3.1 storage的核心實現

storage中有兩種日誌形態，一種是raft日誌（以下稱為raft log），由raft演算法產生和使用，另一種是使用者形態的Log（也就是mysql binlog event）。Storage在設計中，將兩種Log形態組合成一個Log Entry。只是通過不同的頭部資訊來區分。Storage由資料檔案和索引檔案組成，如下圖所示：

• segment固定大小（1GB），只能追加寫入，名字為first_raft_index-last_raft_index，表示該segment的raft index範圍。
• 只有最後一個segment可寫，其檔名為first_raft_index-inprogress，其他segment只讀。
• 只讀的segment和對應的index file都是通過mmap方式寫入和讀取。
• 最後一個segment的index 內容同時儲存在磁碟和記憶體。讀取索引是隻需要在記憶體中讀取。

3.2 etcd raft庫的使用

Etcd raft library在處理已經Apply的日誌、committed entries等內容時，是單執行緒處理的。具體函式參考連結，這個函式處理時間要確保儘可能短，如果處理時間超過raft 選舉時間，會造成叢集重新選舉。這一點需要特別注意。

3.3 binlog syncer的核心實現

binlog syncer主要工作就是：

• 拉取binlog event
• 解析並處理binlog event
• 提交binlog event到raft 叢集。 很明顯可以通過pipeline機制來提個整個過程的處理速度，每個階段kingbus都使用單獨的goroutine來處理，通過管道來銜接不同階段。 由於binlog syncer是按照binlog event一個一個接收的，syncer並不能保證事務完整性，有可能在syncer掛了後，需要重新連線Master，這時候最後一個事務有可能不完整，binlog syncer需要有發現事務完整性的能力，kingbus實現了事務完整性解析的功能，完全參考MySQL原始碼實現。

3.4 binlog server的核心實現

binlog server實現了一個master的功能，slave與binlog server建立複製連線時，slave會發送相關命令，binlog server需要響應這些命令。最終傳送binlog event給slave。對於每個slave，binlog server會啟動一個goroutine不斷讀取raft log，並去掉相關頭部資訊，就變成了binlog event，然後再發送給slave。

4. 總結

本文簡要介紹了kingbus整體架構和核心元件及流程，通過這篇文章，希望讀者對kingbus有個較為全面的認識。