背景
公司很多業務在使用RocketMQ，前期業務量小，沒啥問題，也沒有太關注集羣的可用性這塊，所以全公司的業務公用一個集羣，隨之公司的業務量增加，業務對RocketMQ集羣依賴越來越重，開始思考集羣拆分，風險分攤；開始想的是按部門劃分，一個部門一個集羣，但是部門之間有通過RocketMQ做數據交互的需求，這樣會帶來的問題是一個應用需要連接兩個RocketMQ集羣，需要業務方改代碼，在開發人不需要改代碼的情況下，如何能做到集羣無單點、風險分攤，集羣未來可以水平擴容呢，我們的方案如下：
集羣部署規劃
整個集羣分三層，分別是應用接入層、Nameserver集羣和Broker集羣，下面分別對這三部分說明：
接入層
接入層其實就是應用連接MQ集羣的地址，目前生產環境我們是直接連接了nameserver的IP地址，如果nameserver擴容或者換服務器了，大家需要修改配置重啓服務更新新的nameserver地址，雖然這個事情的機率比較低，但是如果發生了還是比較麻煩，所有我們新的接入方案是負載均衡+域名，大家在程序裏面配置連接MQ的地址爲：BLB:9876,nameserver1.chj.cloud:9876,nameserver2.chj.cloud:9876，這樣同時做了負載均衡和域名的雙保險，如果負載均衡器故障，應用會重試去連域名
Nameserver集羣
Nameserver本身是無狀態的，並且基本沒有壓力，所以我們計劃前期先部署兩臺；後續需要擴容的時候，需要依次重啓broker，讓broker也註冊到新的nameserver上
Broker集羣
Broker負責消息的存儲，Broker的部署有多種模式，我們會根據業務需求，部署兩種架構：多master多slave（同步複製、同步刷盤）、多master多slave（異步複製、異步刷盤）；集羣也可以橫向擴容
Broker命名規範：奇數爲異步複製+異步刷盤類型，偶數爲同步複製+同步刷盤類型，如：broker-1，broker-2
架構圖
Topic管理
根據業務場景，我們把Topic創建到不同的Broker集羣上，業務場景分兩種情況：一種是需要保證消息不丟，但是對吞吐量要求不高，如訂單相關信息，比如下圖的TopicA就是用來存儲訂單相關的Topic，那麼我們就把這個Topic創建到同步複製、同步刷盤這樣角色的Broker集羣上；另一種是對吞吐量要求特別高，但是消息容許發生少量丟失，如車輛上報的監控相關信息，比如下圖的TopicB就是用來存儲車輛上報的監控相關信息的Topic，那麼我們就把這個Topic創建到異步複製、異步刷盤這樣角色的Broker集羣上
