你懂RocketMQ 的架構原理嗎？
前言
前面我們跟大家聊了聊什麼是消息中間件，以及哪些場景使用哪些消息中間件更加合適。
我們了解到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王子一起細嚼慢咽，探索消息中間件的樂趣吧。
往期文章推薦：
我的博客即將同步至騰訊雲+社區，邀請大家一同入駐：//cloud.tencent.com/developer/support-plan?invite_code=2dl7u9oadykgw
