前言
前面我們跟大家聊了聊什麼是訊息中介軟體，以及哪些場景使用哪些訊息中介軟體更加合適。
我們瞭解到RocketMQ是java語言開發的，我們能更深入的閱讀原始碼瞭解它的底層原理，而且它具有優秀的訊息中介軟體高階功能。再換個角度想，對於面試MQ來說，其實我們需要深入的瞭解一箇中介軟體來與面試官聊，其他的中介軟體瞭解基本原理就可以了（後文會講解）。
所以接下來我們就以RocketMQ為敲門磚，一點一點了解MQ的奧祕。
今天我們來聊一聊RocketMQ 的架構原理
RocketMQ是如何承受高併發的呢？
先聊一聊RocketMQ是怎麼實現高併發的呢，我們先從它的單機模式說起。
之前我們說過，單機的RocketMQ可以承受十萬多的併發，那麼這個時候如果業務上突然出現了幾十萬的併發量，這時候如何處理呢。
沒關係，RocketMQ是支援叢集化部署的，部署多臺機器，每臺機器承受十萬的併發不就可以了嗎。
其實這就是RocketMQ承受高併發的原理，當然，關於它是如何將流量分配到叢集的每臺機器上，這個問題以後會單獨講解，今天主要聊一聊總體的架構原理。
RocketMQ是如何儲存大量訊息資料的呢？
現在我們來看看，RocketMQ是如何持久化資料的。MQ收到大量訊息後，這些訊息是不能實時消費掉的，所以就會存在訊息的積壓，同時為了保證訊息不丟失，所以持久化是很必要的。
而對於海量的訊息，單獨一臺機器是儲存不下的。退一步來講，就算能夠儲存的下，一旦這臺機器壞掉，資料就丟失了，無法保證訊息的可靠性。
其實對於訊息資料的持久化，和高併發的解決方案是類似的，看下圖：
假設一共有一萬條訊息要傳送給MQ，分散到10臺機器，可能每臺機器就會收到1000條左右的訊息，這時候MQ會把傳送到自己機器的訊息儲存到自己的磁碟裡，其實就是資料的分散式儲存。
所謂分散式儲存就是把資料分散到多臺機器儲存，可以通過擴充套件機器儲存海量資料。
如果RocketMQ掛掉了怎麼辦?
在討論這個問題之前，我們先引入一個新的概念，Broker。
Master Broker收到訊息後會同步給Slave Broker，這樣Slave Broker就有了一份副本資料，
這樣，當RocketMQ掛掉了一個Broker，還有一份副本Broker可以繼續提供服務，這就保證了系統的高可用性。
對於系統而言（無論是生產者還是消費者），要呼叫MQ服務，首先會去NameServer中獲取路由資訊，也會知道系統中有哪些Broker正在提供服務，從而確定自己應該訪問哪臺機器上的Broker。
RoketMQ的基本架構原理就是這樣了，當然這只是個總體的架構，很多細節的東西都可以去深入探索，歡迎小夥伴們關注後續的文章，和HUC王子一起細嚼慢嚥，探索訊息中介軟體的樂趣吧。
往期文章推薦：
我的部落格即將同步至騰訊雲+社群，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan?invite_code=2dl7u9oadykgw