MySQL Binlog儲存系統的架構如何設計

　　1. kingbus簡介

　　1.1 kingbus是什麼？

　　kingbus是一個基於raft強一致協定實作的分散式MySQL binlog 儲存系統。它能夠充當一個MySQL Slave從真正的Master上同步binlog，並儲存在分散式叢集中。同時又充當一個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。

以上是MySQL Binlog儲存系統的架構如何設計的詳細內容。更多資訊請關注PHP中文網其他相關文章！