前言
看了我們之前的文章，相信小夥伴們對RocketMQ已經有了一個初步的瞭解，那麼今天我們就來聊一聊具體如何來設計一套高可用的生產部署架構。
在聊如何設計這套架構的同時，我們再補充一些之前沒提到的知識。好了，那我們現在開始吧。
NameServer的部署
關於NameServer，我們之前的文章已經詳細講解過了集羣化的內容，這裏直接把它部署到三臺機器上，作爲一個高可用集羣，如果忘記了，小夥伴們參考一下這篇文章聊一聊RocketMQ的註冊中心NameServer，本篇文章就不再細聊了。
Broker的部署
Broker的部署我們之前也有講到過，主要使用的是4.5版本後的Dledger自動化切換主從的集羣，詳細內容可參考Broker的主從架構是怎麼實現的？
之前在講NameServer的文章中，我們聊了聊Broker是如何與NameServer進行通信的，但當時有些細節沒有說到。
Broker與NameServer之間的通信協議是什麼呢？http、rpc還是tcp呢？
其實它們之間採用的是TCP長連接通信，也就是說Broker會跟每個NameServer建立TCP長連接，然後定時通過TCP長連接發送心跳請求過去。
後邊的情況就不再細說了，聊一聊RocketMQ的註冊中心NameServer這篇文章中已經講過了。
訪問MQ的系統（生產者和消費者）的部署
一定會有大量的系統訪問RocketMQ，因爲RocketMQ就是爲此而生的，有些系統自己本身既是生產者又是消費者，所以這些系統的部署也要考慮進去。
對這些系統部署的考慮，其實不應該是搞MQ的部門來考慮的，如果系統本身是自己公司的，可以提出一些建議，讓生產者和消費者都集羣化部署，保證高可用。但如果是第三方系統，那就無法插手了，我們能做到的只有考慮第三方系統崩潰，無法與MQ正常通信的情況下，如何讓MQ正常運轉。
Topic是什麼
Topic是mq的核心數據模型，如果直接翻譯是主題的意思，但是聽到主題的解釋，是不是一臉懵逼，是不是瞬間想到的是手機主題，電腦主題。
所以它不能直譯，它表達的就是一個數據集合的含義，集合的是同一類的數據，不同類型的數據存到不同的Topic中。
所以系統無論是要寫入消息還是讀取數據，最開始都是要先定義Topic的，然後再從定義的Topic中獲取同類型的數據。
那麼Topic是如何在Broker中存儲的呢？
其實之前的文章你懂RocketMQ 的架構原理嗎？中已經聊過RocketMQ是如何存儲大量消息數據的。
存儲的方式其實就是分佈式存儲。我們在定義Topic的時候指定它裏面的數據分佈到多臺的Broker上進行存儲，這裏要注意的一點是，實際上分佈的對象是MasterBroker，SlaveBroker會向MasterBroker拉取數據，作爲一個副本存在。而Broker在向NameServer發送心跳的時候，會把Topic存儲在哪些Broker中的信息告訴NameServer。
生產者如何發送消息給Broker
前邊我們聊過，發送消息前首先是定義Topic，然後發送消息的時候是要指定你要發送到哪個Topic中去的。
既然我們知道了要發送到哪個Topic中，下一步就是要定位Topic的位置，如何定位呢？就是與NameServer建立Tcp長連接，定時拉取註冊信息，可以獲取到這個Topic目前被分配到哪些Broker中。然後就可以根據負載均衡算法，選定一臺Broker(具體的負載均衡算法後邊文章再介紹)。
選定了Broker後，就可以再與Broker建立Tcp長連接，通過Tcp長連接發送消息給Broker中的Topic。
而Broker在接收到消息後，就會把消息存儲到磁盤中，再往後就是SlaveBroker與MasterBroker數據同步，形成副本，保證高可用了。
整個過程就是這樣的。
消費者如何從Broker上消費消息
說完了生產者發送消息的過程，我們再來聊聊消費者消費消息的過程。
其實消費者消費消息的過程和生產者是類似的，同樣第一步也是定義Topic，然後從NameServer獲取信息，定位到Topic所在的多個Broker，之後負載均衡定位到要訪問的Broker，與Broker建立連接獲取消息。
這裏唯一不同的就是，再獲取消息的時候是可能在MasterBroker上獲取的，也可能在SlaveBroker上獲取，要依據當時的情況而定。想要了解具體什麼時候訪問Master，什麼時候訪問Slave，可以參考Broker的主從架構是怎麼實現的？這篇文章。
整體架構總結
最後我們再來看一看這套架構，是可以實現完全的高可用的。
NameServer集羣化部署，Broker集羣化部署，還可以通過Dledger自動化切換主從，生產者消費者也是集羣部署，隨便掛了一臺不受影響。
而且這套架構也不怕高併發，高併發下的消息可以分佈到多個Broker下處理，減少系統壓力。
然後我們的集羣可以存儲海量的消息，因爲存儲方式是分佈式存儲的。
最後，這套架構是具有可擴展性的，如果業務需求併發量增大，也是可以擴展Broker的數量以支持更高的併發和更大的存儲的。
這樣我們的RocketMQ的生產部署架構就算完成了。
好了，今天就說到這裏，歡迎小夥伴們繼續閱讀本專輯，一起走入消息中間件的世界。
往期文章推薦：
中間件專輯：
算法專輯：
