前言 前段時間針對EQueue的完善終於告一段落了，實在值得慶祝，自己的付出和堅持總算有了成果。這次新版本主要為EQueue實現了集群功能，基本實現了Broker的高可用。另外還增加了很多實用的功能，對性能也做了很多優化。總之，EQueue越來越成熟了。 EQueue最新版本信息 Nuget：htt ...
前言
前段時間針對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的高可用部署架構如下圖所示：
架構說明：
- 總共有Producer, Consumer, Broker, Name Server四種伺服器角色；
- Name Server的職責是負責管理所有的Broker，併為Producer，Consumer提供Broker信息以及所有Topic的路由信息；
- 從部署邏輯上看，Broker Master, Broker Slave是屬於一個邏輯上的單元，一個Broker Master可以配置多個Broker Slave；所以，我設計了一個Broker Group的概念。同一個Broker Group中可以有一個Broker Master和多個Broker Slave；
- Broker啟動時，
- 與配置的所有的Name Server建立TCP長連接；
- 定時（5s，可配置）向所有的Name Server註冊自己的所有信息，主要包括：基本信息、隊列信息、消費信息、生成者信息、消費者信息；
- Name Server之間無聯繫，數據無同步；Name Server也可以部署多台，由於每台Broker都會向所有的Name Server註冊自己的信息，所以，理論上所有的Name Server里維護的信息最終都是完全一致的；Name Server不持久化任何東西，啟動後只在記憶體中維護所有Broker上報上來的信息；Name Server不與其他任何伺服器主動通信；
- Broker Slave會從Broker Master通過拉的方式同步消息，並存儲到本地磁碟，消息同步為非同步同步；
- 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次（可配置），以保證儘量能發送消息成功；
- Consumer啟動時，
- 與配置的所有Name Server伺服器建立TCP長連接；
- 隨機選擇一臺Name Server獲取所有可用的Broker列表，對所有的Broker建立TCP長連接，並定時（5s，可配置）更新所有可用的Broker列表；
- 定時（1s，可配置）向所有當前連接的Broker發送心跳，將自己的信息註冊到Broker；
- 定時（5s，可配置）從Name Server獲取所有當前集群的所有Topic的隊列信息；
- 定時（每隔1s，可配置）進行消費者負載均衡，消費者負載均衡的邏輯是，針對當前消費者訂閱的每個Topic，執行下麵的邏輯：
- 從本地獲取該Topic的所有隊列信息；
- 從Broker集群中的第一臺啟動的並且可用的Broker獲取所有當前線上的消費者；
- 根據獲取到的隊列和消費者信息，按隊列個數平均的目的為演算法，為消費者平均分配隊列，完成消費者負載均衡的目的；
- Broker的Producer心跳超時時間預設為10s；Broker的Consumer心跳超時時間預設為10s；Name Server的Broker超時時間未10s；
EQueue管理控制台
因為支持了集群功能，所以管理控制台也需要增加相應的管理功能支持。主要是要支持以集群為單位查看集群下的所有Broker列表，以Topic為單位查看每個Topic在哪些Broker上存在，以Consumer Group為單位查看每個Consumer Group下有哪些消費者，每個消費者分別正在消費哪些隊列等；總結起來，目前的EQueue管理控制台支持以下功能：
- 查看當前有哪些集群；
- 查看某個集群下有哪些Broker，每個Broker的發送TPS，消費TPS，總消息堆積數；
- 查看單個Broker的詳細信息，如監聽的埠，消息存儲信息，總的發送和消費TPS，Topic數、隊列數、消費者組個數、消費者個數、生產者個數、該Broker上的隊列信息、消費信息、生產者列表、消費者列表，最近發送的100條消息，隊列擴容、縮容、重置隊列消費進度，etc；
- 查看某個集群下的隊列信息、消費信息、生產者列表、消費者列表；
- 查看某個集群下的所有隊列的發送TPS，消費TPS；
- 查看某個集群下根據消息ID查看某個消息的詳情；
- 單個集群下支持的操作：
- 新增一個Topic，該Topic會自動在該集群下的所有Broker上創建；
- 刪除一個Topic，該Topic會自動在該集群下的所有Broker上刪除；
- Topic的隊列擴容，自動在集群下的所有Broker上擴容；
- Topic的隊列縮容，自動在集群下的所有Broker上縮容；
- 重置隊列消費進度，自動在集群下的所有Broker上的該隊列重置隊列消費進度；
- 支持消息堆積報警，發送郵件；
下圖為管理控制台的界面，供大家參考理解：
最後，大家對新版的EQueue的集群功能有興趣的，可以進一步觀看我之前在鬥魚上直播的視頻：
https://pan.baidu.com/s/1pLlf7j9
