docker掛載目錄幹嘛用的，拼多多+攜程+螞蟻金服技術面集合
NameServer的部署
關於NameServer，我們之前的文章已經詳細講解過了叢集化的內容，這裡直接把它部署到三臺機器上，作為一個高可用叢集
Broker的部署
Broker的部署我們之前也有講到過，主要使用的是4.5版本後的Dledger自動化切換主從的叢集
Broker與NameServer之間的通訊協議是什麼呢？http、rpc還是tcp呢？
其實它們之間採用的是TCP長連線通訊，也就是說Broker會跟每個NameServer建立TCP長連線，然後定時通過TCP長連線傳送心跳請求過去。
訪問MQ的系統（生產者和消費者）的部署
一定會有大量的系統訪問RocketMQ，因為RocketMQ就是為此而生的，有些系統自己本身既是生產者又是消費者，所以這些系統的部署也要考慮進去。
對這些系統部署的考慮，其實不應該是搞MQ的部門來考慮的，如果系統本身是自己公司的，可以提出一些建議，讓生產者和消費者都叢集化部署，保證高可用。但如果是第三方系統，那就無法插手了，我們能做到的只有考慮第三方系統崩潰，無法與MQ正常通訊的情況下，如何讓MQ正常運轉。
Topic是什麼
Topic是mq的核心資料模型，如果直接翻譯是主題的意思，但是聽到主題的解釋，是不是一臉懵逼，是不是瞬間想到的是手機主題，電腦主題。
所以它不能直譯，它表達的就是一個資料集合的含義，集合的是同一類的資料，不同型別的資料存到不同的Topic中。
所以系統無論是要寫入訊息還是讀取資料，最開始都是要先定義Topic的，然後再從定義的Topic中獲取同類型的資料。
那麼Topic是如何在Broker中儲存的呢？
儲存的方式其實就是分散式儲存。我們在定義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上獲取，要依據當時的情況而定。
整體架構總結
最後我們再來看一看這套架構，是可以實現完全的高可用的。
NameServer叢集化部署，Broker叢集化部署，還可以通過Dledger自動化切換主從，生產者消費者也是叢集部署，隨便掛了一臺不受影響。
而且這套架構也不怕高併發，高併發下的訊息可以分佈到多個Broker下處理，減少系統壓力。
然後我們的叢集可以儲存海量的訊息，因為儲存方式是分散式儲存的。
最後，這套架構是具有可擴充套件性的，如果業務需求併發量增大，也是可以擴充套件Broker的數量以支援更高的併發和更大的儲存的。
這樣我們的RocketMQ的生產部署架構就算完成了。
好了，今天就說到這裡，歡迎小夥伴們一起走入訊息中介軟體的世界。
最後
我還通過一些渠道整理了一些大廠真實面試主要有：螞蟻金服、拼多多、阿里雲、百度、唯品會、攜程、豐巢科技、樂信、軟通動力、OPPO、銀盛支付、中國平安等初，中級，高階Java面試題集合，附帶超詳細答案，希望能幫助到大家。
還有專門針對JVM、SPringBoot、SpringCloud、資料庫、Linux、快取、訊息中介軟體、原始碼等相關面試題。