MetaQ 高可用配置(異步複製和同步複製)

介紹

Meta相比於kafka的一個重要特性就是消息高可用方案的實現，咱們稱之爲HA方案。消息在發送到broker以後當即寫入磁盤才返回客戶端告訴消息生產者消息發送成功，經過unflushThreshold和unflushInterval兩個參數的控制，能夠保證單機消息數據的安全性，只要機器的磁盤沒有永久損壞，消息總能夠在重啓後恢復並正常投遞給消費者們。可是，若是遇到了磁盤永久損壞或者數據文件永久損壞的狀況，那麼該broker上的消息數據將可能永久丟失。爲了防止這種狀況的發生，一個可行的方案就是將消息數據複製到多臺機器，相似mysql的主從複製功能。

同步複製和異步複製

meta提供相似mysql主從複製的異步複製和同步功能，分別對應不一樣的可靠級別。理論上說同步複製能帶來更高的可靠級別，異步複製由於延遲的存在，可能會丟失極少許的消息數據，相應地，同步複製會帶來性能的損失，由於要同步寫入兩臺甚至更多的broker機器上纔算寫入成功。

在實際實踐中，我更推薦採用異步複製的架構，由於異步複製的架構相對簡單，而且易於維護和恢復，對性能也沒有影響。而同步複製對運維要求相對很高，機制複雜容易出錯，故障恢復也比較麻煩。異步複製加上磁盤作磁盤陣列，足以應對很是苛刻的數據可靠性要求。

異步複製配置

假設你已經根據如何開始這份文檔配置了一臺broker服務器，而且配置了一個topic爲test，如今你但願test能複製到另外一臺slave broker上來保證消息數據的高可用。你能夠這樣作：

1.首先，你須要部署一個新的broker，具體仍然參照如何開始這份文檔，配置server.ini從master broker拷貝一份。

2.其次，配置slave文件。編輯conf/async_slave.properties：

#slave編號,大於等於0表示做爲slave啓動,同一個master下的slave編號應該設不一樣值.
slaveId=0

#做爲slave啓動時向master訂閱消息的group,若是沒配置則默認爲meta-slave-group
#不一樣的slaveId請使用不一樣的group
slaveGroup=meta-slave-group

#slave數據同步的最大延時,單位毫秒  
slaveMaxDelayInMills=500

#是否自動從master同步server.ini, 1.4.2新增選項
#第一次仍然須要本身拷貝server.ini，後續能夠經過設置此選項爲true來自動同步
autoSyncMasterConfig=true

配置參數的含義請本身看註釋。可見，一個master能夠複製到多個slave。

3.執行下列命令啓動slave:

bin/metaServer.sh start slave

4.第一次複製由於須要跟master徹底同步須要耗費必定時間，你能夠在數據文件的目錄觀察複製狀況。

5.請注意，異步複製的slave將參與消費者的消費活動，消息消費者能夠從slave中獲取消息並消費，消費者會隨機從master和slaves中挑選一臺做爲消費broker。

6.請注意，從1.4.2開始，能夠經過autoSyncMasterConfig選項配置是否自動同步master的server.ini到異步複製的slave上，當master的server.ini文件變動並經過bin/metaServer.sh reload以後，slave將監控到這一變動並自動同步。

異步複製的侷限

• 異步複製有延遲，雖然能夠經過設定slaveMaxDelayInMills來控制延遲。

異步複製的故障處理

• Master永久故障： 將slave做爲master啓動，去除啓動參數中的slave便可，也就是metaServer.sh restart

• Slave永久故障： 啓動新的broker並配置做爲master新的slave啓動。

同步複製配置

TODO