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