前言
看了我們之前的文章，相信小伙伴們對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的生產部署架構就算完成了。
好了，今天就說到這里，歡迎小伙伴們繼續閱讀本專輯，一起走入消息中間件的世界。
往期文章推薦：
中間件專輯：
算法專輯：
