本篇內(nèi)容介紹了“分布式MySQL Binlog存儲(chǔ)系統(tǒng)的架構(gòu)怎么設(shè)計(jì)”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

在太康等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,網(wǎng)絡(luò)營(yíng)銷推廣,外貿(mào)網(wǎng)站制作,太康網(wǎng)站建設(shè)費(fèi)用合理。

 1. kingbus簡(jiǎn)介

1.1 kingbus是什么？

kingbus是一個(gè)基于raft強(qiáng)一致協(xié)議實(shí)現(xiàn)的分布式MySQL binlog 存儲(chǔ)系統(tǒng)。它能夠充當(dāng)一個(gè)MySQL Slave從真正的Master上同步binglog，并存儲(chǔ)在分布式集群中。同時(shí)又充當(dāng)一個(gè)MySQL Master將集群中的binlog 同步給其他Slave。 kingbus具有如下特性：

• 兼容MySQL 復(fù)制協(xié)議，通過(guò)Gtid方式同步Master上的binlog，同時(shí)支持slave通過(guò)Gtid方式從kingbus拉取binlog。

• 跨地域數(shù)據(jù)復(fù)制，kingbus通過(guò)raft協(xié)議支持跨地域間的數(shù)據(jù)復(fù)制。寫入到集群的binlog數(shù)據(jù)在多個(gè)節(jié)點(diǎn)間保證強(qiáng)一致，并保證binlog順序與master上完全一致。

• 高可用，由于kingbus是構(gòu)建在Raft強(qiáng)一致協(xié)議之上，能夠?qū)崿F(xiàn)集群中過(guò)半數(shù)節(jié)點(diǎn)存活的情況下，整個(gè)binlog拉取和推送服務(wù)高可用。

1.2 kingbus能解決什么問(wèn)題？

• kingbus能降低Master的網(wǎng)絡(luò)傳輸流量。在一主多從的復(fù)制拓?fù)渲?，Master需要發(fā)送binlog到各個(gè)slave，如果slave過(guò)多的話，網(wǎng)絡(luò)流量很有可能達(dá)到Master的網(wǎng)卡上限。例如在Master執(zhí)行delete大表或者online DDL等操作，都有可能造成瞬間生成大量的binlog event，如果master下面掛10臺(tái)slave的話，master上的網(wǎng)卡流量就會(huì)放大10倍。如果master使用千兆網(wǎng)卡，產(chǎn)生了10MB/S以上的流量就有可能將其網(wǎng)卡跑滿。通過(guò)kingbus連接master的方式，可以將slave分散到多臺(tái)機(jī)器上，從而均衡傳輸流量。

• 簡(jiǎn)化Master Failover流程，只需將連接在kingbus上的一臺(tái)Slave提升為Master，并將kingbus重新指向新的Master，其他slave依舊連接在kingbus上，復(fù)制拓?fù)浔３植蛔儭?/p>

• 節(jié)省Master存儲(chǔ)binlog文件的空間。一般MySQL上都是較為昂貴的SSD，如果binlog文件占用空間較多，就使得MySQL存儲(chǔ)的數(shù)據(jù)不得不降低?？梢酝ㄟ^(guò)將binlog都存儲(chǔ)到kingbus中，從而降低Master上binlog文件的存儲(chǔ)數(shù)量

• 支持異構(gòu)復(fù)制。通過(guò)阿里巴巴開源的canal連接到kingbus，kingbus源源不斷推送binlog給canal，canal接收完binlog再推送給kafka消息隊(duì)列，最終存入HBase里，業(yè)務(wù)部門通過(guò)Hive直接寫SQL的方式來(lái)實(shí)現(xiàn)業(yè)務(wù)的實(shí)時(shí)分析。

2.kingbus總體架構(gòu)

kingbus整體架構(gòu)如下圖所示：

• storage負(fù)責(zé)存儲(chǔ)raft log entry和Metadata，在kingbus中，將raft log和mysql binlog融合在一起了，通過(guò)不同的頭部信息區(qū)分，raft log的數(shù)據(jù)部分就是binlog event，這樣就不需要分開存儲(chǔ)兩類log，節(jié)省存儲(chǔ)空間。因?yàn)閗ingbus需要存儲(chǔ)一些元信息，例如raft 節(jié)點(diǎn)投票信息、某些特殊binlog event的具體內(nèi)容（FORMAT_DESCRIPTION_EVENT）。

• raft復(fù)制kingbus集群的Lead選舉、日志復(fù)制等功能，使用的是etcd raft library。

• binlog syncer，只運(yùn)行在Raft集群的Lead節(jié)點(diǎn)上，整個(gè)集群只有一個(gè)syncer。syncer偽裝成一個(gè)slave，向Master建立主從復(fù)制連接，Master會(huì)根據(jù)syncer發(fā)送的executed_gtid_set過(guò)濾syncer已經(jīng)接受的binlog event，只發(fā)送syncer沒(méi)有接收過(guò)的binlog event，這套復(fù)制協(xié)議完全兼容MySQL 主從復(fù)制機(jī)制。syncer收到binlog event后，會(huì)根據(jù)binlog event類型做一些處理，然后將binlog event封裝成一個(gè)消息提交到raft 集群中。通過(guò)raft算法，這個(gè)binlog event就可以在多個(gè)節(jié)點(diǎn)存儲(chǔ)，并達(dá)到強(qiáng)一致的效果。

• binlog server，就是一個(gè)實(shí)現(xiàn)了復(fù)制協(xié)議的Master，真正的slave可以連接到binlog server監(jiān)聽的端口，binlog server會(huì)將binlog event發(fā)送給slave，整個(gè)發(fā)送binlog event的過(guò)程參照MySQL 復(fù)制協(xié)議實(shí)現(xiàn)。當(dāng)沒(méi)有binlog event發(fā)送給slave時(shí)，binlog server會(huì)定期發(fā)送heartbeat event給slave，?；顝?fù)制連接。

• api server，負(fù)責(zé)整個(gè)kingbus集群的管理，包括以下內(nèi)容：

• raft cluster membership操作，查看集群狀態(tài)，添加一個(gè)節(jié)點(diǎn)、移除一個(gè)節(jié)點(diǎn)，更新節(jié)點(diǎn)信息等

• binlog syncer相關(guān)操作，啟動(dòng)一個(gè)binlog syncer，停止binlog syncer，查看binlog syncer狀態(tài)。

• binlog server相關(guān)操作，啟動(dòng)一個(gè)binlog server，停止binlog server，查看binlog server狀態(tài)。 server層的各種異常，都不會(huì)影響到raft層，server可以理解為一種插件，按需啟動(dòng)和停止。以后擴(kuò)展kingbus時(shí)，只需要實(shí)現(xiàn)相關(guān)邏輯的server就行。例如實(shí)現(xiàn)一個(gè)kafka協(xié)議的server，那么就可以通過(guò)kafka client消費(fèi)kingbus中的消息。

3.kingbus核心實(shí)現(xiàn)

3.1 storage的核心實(shí)現(xiàn)

storage中有兩種日志形態(tài)，一種是raft日志（以下稱為raft log），由raft算法產(chǎn)生和使用，另一種是用戶形態(tài)的Log（也就是mysql binlog event）。Storage在設(shè)計(jì)中，將兩種Log形態(tài)組合成一個(gè)Log Entry。只是通過(guò)不同的頭部信息來(lái)區(qū)分。Storage由數(shù)據(jù)文件和索引文件組成，如下圖所示：

• segment固定大小（1GB），只能追加寫入，名字為first_raft_index-last_raft_index，表示該segment的raft index范圍。

• 只有***一個(gè)segment可寫，其文件名為first_raft_index-inprogress，其他segment只讀。

• 只讀的segment和對(duì)應(yīng)的index file都是通過(guò)mmap方式寫入和讀取。

• ***一個(gè)segment的index 內(nèi)容同時(shí)存儲(chǔ)在磁盤和內(nèi)存。讀取索引是只需要在內(nèi)存中讀取。

3.2 etcd raft庫(kù)的使用

Etcd raft library在處理已經(jīng)Apply的日志、committed entries等內(nèi)容時(shí)，是單線程處理的。具體函數(shù)參考鏈接，這個(gè)函數(shù)處理時(shí)間要確保盡可能短，如果處理時(shí)間超過(guò)raft 選舉時(shí)間，會(huì)造成集群重新選舉。這一點(diǎn)需要特別注意。

3.3 binlog syncer的核心實(shí)現(xiàn)

binlog syncer主要工作就是：

• 拉取binlog event

• 解析并處理binlog event

• 提交binlog event到raft 集群。 很明顯可以通過(guò)pipeline機(jī)制來(lái)提個(gè)整個(gè)過(guò)程的處理速度，每個(gè)階段kingbus都使用單獨(dú)的goroutine來(lái)處理，通過(guò)管道來(lái)銜接不同階段。 由于binlog syncer是按照binlog event一個(gè)一個(gè)接收的，syncer并不能保證事務(wù)完整性，有可能在syncer掛了后，需要重新連接Master，這時(shí)候***一個(gè)事務(wù)有可能不完整，binlog syncer需要有發(fā)現(xiàn)事務(wù)完整性的能力，kingbus實(shí)現(xiàn)了事務(wù)完整性解析的功能，完全參考MySQL源碼實(shí)現(xiàn)。

3.4 binlog server的核心實(shí)現(xiàn)

binlog server實(shí)現(xiàn)了一個(gè)master的功能，slave與binlog server建立復(fù)制連接時(shí)，slave會(huì)發(fā)送相關(guān)命令，binlog server需要響應(yīng)這些命令。最終發(fā)送binlog event給slave。對(duì)于每個(gè)slave，binlog server會(huì)啟動(dòng)一個(gè)goroutine不斷讀取raft log，并去掉相關(guān)頭部信息，就變成了binlog event，然后再發(fā)送給slave。

“分布式MySQL Binlog存儲(chǔ)系統(tǒng)的架構(gòu)怎么設(shè)計(jì)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！