消息中間件主備方案選型實踐

背景介紹

該消息中間件由三個子系統組成：客戶端SDK、Server和控制管理中心（Admin）。我們所說的主備主要是針對Server，而Server的節點是局部有狀態的，具體而言就是發佈無狀態，但是拉取有狀態。因此，對於發佈而言，由於分佈式部署所以本身具備高可用性；但是對於拉取，就存在單點的可用性問題。

主備切換的關鍵問題

實現主備切換，需要解決兩個核心問題：
1. 解決主備之間狀態檢測、通信和決策問題。
通過心跳檢測來得知互相之間的狀態，一旦得知對方狀態異常需要接管對方的資源繼續提供服務。
2. 解決資源轉移的問題。
通過資源共享機制或者資源同步冗餘方式來解決資源轉移的問題。

任何一套主備切換方案都需要解決這兩個基本問題。

主備切換思路

1. 故障檢測
2. 狀態和決策
3. 資源切換

方案比較

1. Zookeeper
   

   如果使用Zookeeper，每組主備Server需要部署Zookeeper，作爲Zookeeper Server；SDK作爲Zookeeper Client，建立和主備Server的連接，並且監控Zookeeper Server的事件。如果發生不可用，則可以通過監聽到的事件，來觸發主備切換。那麼其實，我們使用Zookeeper只解決了第一個問題。至於第二個問題，如果是Single模式，資源轉移可以通過DB中間件來共享資源解決；如果是Master-Slave模式，則需要Server自身的開發來解決。

2. 負載均衡軟件（LVS、HAProxy、Nginx）+ 高可用軟件（Keepalived、Heartbeat）
   這種方案是用於負載均衡Server的高可用，Keepalived和Heartbeat也只是解決了第一個問題；第二個問題是負載均衡軟件來解決。

3. 自研
   自研方案一

   1. Admin作爲觀察者，建立和每一個主備server的的連接，並通過心跳檢測監控連接狀態。Admin管理每組主備的關係和其激活狀態。需要考慮Admin本身的高可用性。
   2. Server的備機啓動項區別於主機，並且只提供拉取服務，其他服務拒絕。另外，備機在恢復時，需要先停止服務，然後同步消費狀態；Server的主機在恢復時，首先要從Admin拉取消費狀態信息，並更新到DB。
   3. SDK定時從飛鴿Admin拉取飛鴿Server的信息，如果發現Slave被激活，則建立同Slave的連接，剔除Master連接；如果發現Master被激活，則建立同Master的連接，待連接建立成功後，再剔除Slave連接。

   主備切換序列圖：
   

   主備切換序列圖：
   

   自研方案二

   1. 在SDK和Server之間加一個飛鴿Proxy，其負責主備切換，並且負責路由，這樣可以輕量化SDK。因爲目前server的連接是帶了鑑權狀態的，因此就需要將鑑權功能上移到proxy。或者考慮是否可以去除連接的狀態？連接是否有狀態會影響proxy本身的高可用方案，如果連接無狀態，直接採用F5即可；如果有狀態，則proxy本身的高可用方案又是個難題了。
   2. Proxy保持這和Master和Slave的長連接，並且做心跳檢測，檢測達到切換條件，則觸發切換動作。
   3. Proxy方案對現有飛鴿方案的衝擊比較大，改動面比較多。