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。

4. 總結

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

總結

以上是生活随笔為你收集整理的mysqlbinlog查看日志_一个分布式 MySQL Binlog 存储系统的架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。

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