前言

前段時間針對EQueue的完善終於告一段落了，實在值得慶祝，自己的付出和堅持總算有了成果。這次新版本主要為EQueue實現了叢集功能，基本實現了Broker的高可用。另外還增加了很多實用的功能，對效能也做了很多優化。總之，EQueue越來越成熟了。

EQueue最新版本資訊

版本釋出說明

• 為Broker支援叢集部署的功能，解決針對訊息生產者的高可用；
• 支援顯示無線上消費者的消費者分組，並支援刪除這些消費者分組；
• 支援刪除訊息時配置是否需要判斷訊息已經消費過；
• 完善重置消費進度的功能，重置後可立即看到效果；
• 採用雙緩衝佇列，提高Broker的效能；優化後單臺Broker的效能：單發10W TPS；單收10W TPS；同時收發 8.5W TPS；訊息大小為1KB；Broker配置：8核16G，虛擬機器；
• 管理控制檯功能極大的完善；
• 可配置按時間刪除訊息，滿足使用者希望訊息只儲存最近1天的需求；
• 支援Pull模式，允許高階使用者自己拉取訊息，自己消費，自己提交消費進度；

為什麼要做高可用

經過了一個多月的業餘時間的努力，終於為EQueue增加了Broker的叢集功能。作為一個分散式訊息中介軟體，除了效能之外，我們還關注其高可用，高可用指的是Broker的高可用。要實現Broker的高可用，最基本的條件是Broker要支援叢集部署的能力。假設一個叢集內我們部署了5臺Broker，然後掛掉幾臺，如果對Producer, Consumer都沒有影響，則我們可以說Broker支援高可用。

這次釋出的EQueue的版本，實現了Broker的叢集部署，但是還沒有實現Broker的主備。所以，在架構上來講，支援了對Producer的高可用，但是對Consumer來說還沒有實現高可用。因為如果有一臺Broker掛了，則Producer可以將訊息傳送到Broker叢集中的其他的Broker，所以對Producer沒有影響。但是對Consumer是有影響的。因為此時掛掉的這臺Broker上的訊息在掛掉的這段時間內就無法被Consumer消費了。必須等到Broker重新起來後才能被消費。而如果實現了Broker的主備功能，則當Broker Master掛掉了，則因為Broker Slave還在，所以Consumer可以從Broker Slave上消費訊息。從而可以做到對Consumer的高可用。Broker的主備功能，還能保證訊息的可靠性。因為假設Broker Master的硬碟壞掉了，訊息也不會丟失，因為Broker Slave上還有訊息。

所以，總結一下就是：

• Broker叢集功能解決的是針對Producer傳送訊息的高可用；
• Broker主備功能解決的是針對Consumer消費訊息的高可用，以及訊息的可靠性保證；

新版EQueue架構說明

下一個版本的EQueue將會實現Broker的主備功能。目前EQueue的高可用部署架構如下圖所示：

架構說明：

1. 總共有Producer, Consumer, Broker, Name Server四種伺服器角色；
2. Name Server的職責是負責管理所有的Broker，併為Producer，Consumer提供Broker資訊以及所有Topic的路由資訊；
3. 從部署邏輯上看，Broker Master, Broker Slave是屬於一個邏輯上的單元，一個Broker Master可以配置多個Broker Slave；所以，我設計了一個Broker Group的概念。同一個Broker Group中可以有一個Broker Master和多個Broker Slave；
4. Broker啟動時，
   • 與配置的所有的Name Server建立TCP長連線；
   • 定時（5s，可配置）向所有的Name Server註冊自己的所有資訊，主要包括：基本資訊、佇列資訊、消費資訊、生成者資訊、消費者資訊；
5. Name Server之間無聯絡，資料無同步；Name Server也可以部署多臺，由於每臺Broker都會向所有的Name Server註冊自己的資訊，所以，理論上所有的Name Server裡維護的資訊最終都是完全一致的；Name Server不持久化任何東西，啟動後只在記憶體中維護所有Broker上報上來的資訊；Name Server不與其他任何伺服器主動通訊；
6. Broker Slave會從Broker Master通過拉的方式同步訊息，並存儲到本地磁碟，訊息同步為非同步同步；
7. Producer啟動時，
   • 與配置的所有Name Server伺服器建立TCP長連線；
   • 隨機選擇一臺Name Server獲取所有可用的Broker列表，對所有的Broker建立TCP長連線，並定時（5s，可配置）更新所有可用的Broker列表；
   • 定時（1s，可配置）向所有當前連線的Broker傳送心跳，將自己的資訊註冊到Broker；
   • 定時（5s，可配置）從Name Server獲取所有當前叢集的所有Topic的佇列資訊；
   • 傳送Topic時，如果該Topic的佇列資訊在本地存在，則直接從本地獲取佇列資訊；如果不存在，則嘗試從Name Server獲取，如果Name Server上獲取不了，則認為該Topic下沒有佇列資訊；如果沒有獲取到佇列資訊，則會重試這個步驟5次（可配置），以保證儘量能傳送訊息成功；
8. Consumer啟動時，
   • 與配置的所有Name Server伺服器建立TCP長連線；
   • 隨機選擇一臺Name Server獲取所有可用的Broker列表，對所有的Broker建立TCP長連線，並定時（5s，可配置）更新所有可用的Broker列表；
   • 定時（1s，可配置）向所有當前連線的Broker傳送心跳，將自己的資訊註冊到Broker；
   • 定時（5s，可配置）從Name Server獲取所有當前叢集的所有Topic的佇列資訊；
   • 定時（每隔1s，可配置）進行消費者負載均衡，消費者負載均衡的邏輯是，針對當前消費者訂閱的每個Topic，執行下面的邏輯：
     • 從本地獲取該Topic的所有佇列資訊；
     • 從Broker叢集中的第一臺啟動的並且可用的Broker獲取所有當前線上的消費者；
     • 根據獲取到的佇列和消費者資訊，按佇列個數平均的目的為演算法，為消費者平均分配佇列，完成消費者負載均衡的目的；
9. Broker的Producer心跳超時時間預設為10s；Broker的Consumer心跳超時時間預設為10s；Name Server的Broker超時時間未10s；

EQueue管理控制檯 

因為支援了叢集功能，所以管理控制檯也需要增加相應的管理功能支援。主要是要支援以叢集為單位檢視叢集下的所有Broker列表，以Topic為單位檢視每個Topic在哪些Broker上存在，以Consumer Group為單位檢視每個Consumer Group下有哪些消費者，每個消費者分別正在消費哪些佇列等；總結起來，目前的EQueue管理控制檯支援以下功能：

1. 檢視當前有哪些叢集；
2. 檢視某個叢集下有哪些Broker，每個Broker的傳送TPS，消費TPS，總訊息堆積數；
3. 檢視單個Broker的詳細資訊，如監聽的埠，訊息儲存資訊，總的傳送和消費TPS，Topic數、佇列數、消費者組個數、消費者個數、生產者個數、該Broker上的佇列資訊、消費資訊、生產者列表、消費者列表，最近傳送的100條訊息，佇列擴容、縮容、重置佇列消費進度，etc；
4. 檢視某個叢集下的佇列資訊、消費資訊、生產者列表、消費者列表；
5. 檢視某個叢集下的所有佇列的傳送TPS，消費TPS；
6. 檢視某個叢集下根據訊息ID檢視某個訊息的詳情；
7. 單個叢集下支援的操作：
   • 新增一個Topic，該Topic會自動在該叢集下的所有Broker上建立；
   • 刪除一個Topic，該Topic會自動在該叢集下的所有Broker上刪除；
   • Topic的佇列擴容，自動在叢集下的所有Broker上擴容；
   • Topic的佇列縮容，自動在叢集下的所有Broker上縮容；
   • 重置佇列消費進度，自動在叢集下的所有Broker上的該佇列重置佇列消費進度；
8. 支援訊息堆積報警，傳送郵件；

下圖為管理控制檯的介面，供大家參考理解：

最後，大家對新版的EQueue的叢集功能有興趣的，可以進一步觀看我之前在鬥魚上直播的視訊：