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

這篇文章主要講解了“MySQL Binlog存儲系統的架構如何設計”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“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存儲系統的架構如何設計”的內容了，經過本文的學習后，相信大家對MySQL Binlog存儲系統的架構如何設計這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！