作者：zhh1072773034
來源：CSDN
原文：https://blog.csdn.net/zhh1072773034/article/details/79082140
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！
版權聲明：本文爲博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/zhh1072773034/article/details/79082140
RocketMQ是一個純java、分佈式、隊列模型的開源消息中間件，前身是Metaq，當 Metaq 3.0發佈時，產品名稱改爲 RocketMQ。
具有以下特點：
1、能夠保證嚴格的消息順序
2、提供豐富的消息拉取模式
3、高效的訂閱者水平擴展能力
4、實時的消息訂閱機制
5、億級消息堆積能力
一.基本概念
Producer
消息生產者，負責產生消息，一般由業務系統負責產生消息
Consumer
消息消費者，負責消費消息，一般是後臺系統負責異步消費
Push Consumer
Consumer的一種，應用通常向Consumer對象註冊一個Listener接口，一旦收到消息，Consumer對象立刻回調Listener接口方法
Pull Consumer
Consumer的一種，應用通常主動調用Consumer的拉消息方法從Broker拉消息，主動權由應用控制
Producer Group
一類Producer的集合名稱，這類Producer通常發送一類消息，且發送邏輯一致
Consumer Group
一類Consumer的集合名稱，這類Consumer通常消費一類消息，且消費邏輯一致
Broker
消息中轉角色，負責存儲消息，轉發消息，一般也稱爲Server。
長連接
在頁面嵌入一個隱藏的Iframe，將這個隱藏Iframe的src屬性設置爲對一個長連接的請求或是採用xhr請求，服務器端就源源不斷的向客戶端輸入數據。
二.RocketMQ網絡部署特點
Broker集羣有多種配置方式：
1，單Master
優點：除了配置簡單沒什麼優點
缺點：不可靠，該機器重啓或宕機，將導致整個服務不可用
2，多Master
優點：配置簡單，性能最高
缺點：可能會有少量消息丟失（配置相關），單臺機器重啓或宕機期間，該機器下未被消費的消息在機器恢復前不可訂閱，影響消息實時性
3，多Master多Slave，每個Master配一個Slave，有多對Master-Slave，HA採用異步複製方式，主備有短暫消息延遲，毫秒級
優點：性能同多Master幾乎一樣，實時性高，主備間切換對應用透明，不需人工干預
缺點：Master宕機或磁盤損壞時會有少量消息丟失
4，多Master多Slave，每個Master配一個Slave，有多對Master-Slave，HA採用同步雙寫方式，主備都寫成功，嚮應用返回成功
優點：服務可用性與數據可用性非常高
缺點：性能比一部HA略低，當前版本主宕備不能自動切換爲主
Master和Slave的配置文件參考conf目錄下的配置文件
Master與Slave通過指定相同的brokerName參數來配對，Master的BrokerId必須是0，Slave的BrokerId必須是大於0的數
一個Master下面可以掛載多個Slave，同一Master下的多個Slave通過指定不同的BrokerId來區分
如下是常用的部署結構。
（1）NameServer是一個幾乎無狀態的節點，可集羣部署，節點之間無任何信息同步
（2）Broker部署相對複雜，Broker氛圍Master與Slave，一個Master可以對應多個Slaver，但是一個Slaver只能對應一個Master，Master與Slaver的對應關係通過指定相同的BrokerName，不同的BrokerId來定義，BrokerId爲0表示Master，非0表示Slaver。Master可以部署多個。每個Broker與NameServer集羣中的所有節點建立長連接，定時註冊Topic信息到所有的NameServer
（3）Producer與NameServer集羣中的其中一個節點（隨機選擇）建立長連接，定期從NameServer取Topic路由信息，並向提供Topic服務的Master建立長連接，且定時向Master發送心跳。Produce完全無狀態，可集羣部署
（4）Consumer與NameServer集羣中的其中一個節點（隨機選擇）建立長連接，定期從NameServer取Topic路由信息，並向提供Topic服務的Master、Slaver建立長連接，且定時向Master、Slaver發送心跳。Consumer即可從Master訂閱消息，也可以從Slave訂閱消息，訂閱規則由Broker配置決定
三.RocketMQ儲存特點
（1）零拷貝原理：Consumer消費消息過程，使用了零拷貝，零拷貝包括一下2中方式，RocketMQ使用第一種方式，因小塊數據傳輸的要求效果比sendfile方式好
a )使用mmap+write方式
優點：即使頻繁調用，使用小文件塊傳輸，效率也很高
缺點：不能很好的利用DMA方式，會比sendfile多消耗CPU資源，內存安全性控制複雜，需要避免JVM Crash問題
b）使用sendfile方式
優點：可以利用DMA方式，消耗CPU資源少，大塊文件傳輸效率高，無內存安全新問題
缺點：小塊文件效率低於mmap方式，只能是BIO方式傳輸，不能使用NIO
（2）數據存儲結構
四.RocketMQ關鍵特性
1.單機支持1W以上的持久化隊列
（1）所有數據單獨儲存到commit Log ，完全順序寫，隨機讀
（2）對最終用戶展現的隊列實際只儲存消息在Commit Log 的位置信息，並且串行方式刷盤
這樣做的好處：
（1）隊列輕量化，單個隊列數據量非常少
（2）對磁盤的訪問串行話，避免磁盤競爭，不會因爲隊列增加導致IOWait增高
每個方案都有優缺點，他的缺點是：
（1）寫雖然是順序寫，但是讀卻變成了隨機讀
（2）讀一條消息，會先讀Consume Queue，再讀Commit Log，增加了開銷
（3）要保證Commit Log 與 Consume Queue完全的一致，增加了編程的複雜度
以上缺點如何客服：
（1）隨機讀，儘可能讓讀命中pagecache，減少IO操作，所以內存越大越好。如果系統中堆積的消息過多，讀數據要訪問硬盤會不會由於隨機讀導致系統性能急劇下降，答案是否定的。
a）訪問pagecache時，即使只訪問1K的消息，系統也會提前預讀出更多的數據，在下次讀時就可能命中pagecache
b）隨機訪問Commit Log 磁盤數據，系統IO調度算法設置爲NOOP方式，會在一定程度上將完全的隨機讀變成順序跳躍方式，而順序跳躍方式讀較完全的隨機讀性能高5倍
（2）由於Consume Queue存儲數量極少，而且順序讀，在pagecache的與讀取情況下，Consume Queue的讀性能與內存幾乎一直，即使堆積情況下。所以可以認爲Consume Queue完全不會阻礙讀性能
（3）Commit Log中存儲了所有的元信息，包含消息體，類似於MySQl、Oracle的redolog，所以只要有Commit Log存在， Consume Queue即使丟失數據，仍可以恢復出來
2.刷盤策略
rocketmq中的所有消息都是持久化的，先寫入系統pagecache，然後刷盤，可以保證內存與磁盤都有一份數據，訪問時，可以直接從內存讀取
2.1異步刷盤
在有 RAID 卡， SAS 15000 轉磁盤測試順序寫文件，速度可以達到 300M 每秒左右，而線上的網卡一般都爲千兆網卡，寫磁盤速度明顯快於數據網絡入口速度，那麼是否可以做到寫完 內存就向用戶返回，由後臺線程刷盤呢？
(1). 由於磁盤速度大於網卡速度，那麼刷盤的進度肯定可以跟上消息的寫入速度。
(2). 萬一由於此時系統壓力過大，可能堆積消息，除了寫入 IO，還有讀取 IO，萬一出現磁盤讀取落後情況，會不會導致系統內存溢出，答案是否定的，原因如下：
a) 寫入消息到 PAGECACHE 時，如果內存不足，則嘗試丟棄乾淨的 PAGE，騰出內存供新消息使用，策略
是 LRU 方式。
b) 如果幹淨頁不足，此時寫入 PAGECACHE 會被阻塞，系統嘗試刷盤部分數據，大約每次嘗試 32 個 PAGE，
來找出更多幹淨 PAGE。
綜上，內存溢出的情況不會出現
2.2同步刷盤：
同步刷盤與異步刷盤的唯一區別是異步刷盤寫完 PAGECACHE 直接返回，而同步刷盤需要等待刷盤完成才返回，同步刷盤流程如下：
（1）寫入 PAGECACHE 後，線程等待，通知刷盤線程刷盤。
（2）刷盤線程刷盤後，喚醒前端等待線程，可能是一批線程。
（3）前端等待線程向用戶返回成功。
3.消息查詢
3.1按照MessageId查詢消息
MsgId總共16個字節，包含消息儲存主機地址，消息Commit Log Offset。從MsgId中解析出Broker的地址和Commit Log 偏移地址，然後按照存儲格式所在位置消息buffer解析成一個完整消息
3.2按照Message Key查詢消息
1.根據查詢的key的hashcode%slotNum得到具體的槽位置 （slotNum是一個索引文件裏面包含的最大槽目數目，例如圖中所示 slotNum=500W）
2.根據slotValue（slot對應位置的值）查找到索引項列表的最後一項（倒序排列，slotValue總是指向最新的一個索引項）
3.遍歷索引項列表返回查詢時間範圍內的結果集（默認一次最大返回的32條記錄）
4.Hash衝突，尋找key的slot位置時相當於執行了兩次散列函數，一次key的hash，一次key的hash取值模，因此這裏存在兩次衝突的情況；第一種，key的hash值不同但模數相同，此時查詢的時候會在比較第一次key的hash值（每個索引項保存了key的hash值），過濾掉hash值不想等的情況。第二種，hash值相等key不想等，出於性能的考慮衝突的檢測放到客戶端處理（key的原始值是存儲在消息文件中的，避免對數據文件的解析），客戶端比較一次消息體的key是否相同
5.存儲，爲了節省空間索引項中存儲的時間是時間差值（存儲時間——開始時間，開始時間存儲在索引文件頭中），整個索引文件是定長的，結構也是固定的
4.服務器消息過濾
RocketMQ的消息過濾方式有別於其他的消息中間件，是在訂閱時，再做過濾，先來看下Consume Queue存儲結構
1.在Broker端進行Message Tag比較，先遍歷Consume Queue，如果存儲的Message Tag與訂閱的Message Tag不符合，則跳過，繼續比對下一個，符合則傳輸給Consumer。注意Message Tag是字符串形式，Consume Queue中存儲的是其對應的hashcode，比對時也是比對hashcode
2.Consumer收到過濾消息後，同樣也要執行在broker端的操作，但是比對的是真實的Message Tag字符串，而不是hashcode
爲什麼過濾要這麼做？
1.Message Tag存儲hashcode，是爲了在Consume Queue定長方式存儲，節約空間
2.過濾過程中不會訪問Commit Log 數據，可以保證堆積情況下也能高效過濾
3.即使存在hash衝突，也可以在Consumer端進行修正，保證萬無一失
5.單個JVM進程也能利用機器超大內存
1.Producer發送消息，消息從socket進入java 堆
2.Producer發送消息，消息從java堆進入pagecache，物理內存
3.Producer發送消息，由異步線程刷盤，消息從pagecache刷入磁盤
4.Consumer拉消息（正常消費），消息直接從pagecache（數據在物理內存）轉入socket，到達Consumer，不經過java堆。這種消費場景最多，線上96G物理內存，按照1K消息算，可以物理緩存1億條消息
5.Consumer拉消息（異常消費），消息直接從pagecache轉入socket
6.Consumer拉消息（異常消費），由於socket訪問了虛擬內存，產生缺頁中斷，此時會產生磁盤IO，從磁盤Load消息到pagecache，然後直接從socket發出去
7.同5
8.同6
6.消息堆積問題解決辦法
堆積性能指標
1 消息的堆積容量 依賴磁盤大小
2 發消息的吞吐量大小受影響程度 無Slave情況，會受一定影響
有Slave情況，不受影響
3 正常消費的Consumer是否會受影響 無Slave情況，會受一定影響
有Slave情況，不受影響
4 訪問堆積在磁盤的消息時，吞吐量有多大 與訪問的併發有關，最終會降到5000左右
在有Slave情況下，Master一旦發現Consumer訪問堆積在磁盤的數據時，回想Consumer下達一個重定向指令，令Consumer從Slave拉取數據，這樣正常的發消息與正常的消費不會因爲堆積受影響，因爲系統將堆積場景與非堆積場景分割在了兩個不同的節點處理。這裏會產生一個問題，Slave會不會寫性能下降，答案是否定的。因爲Slave的消息寫入只追求吞吐量，不追求實時性，只要整體的吞吐量高就行了，而Slave每次都是從Master拉取一批數據，如1M，這種批量順序寫入方式使堆積情況，整體吞吐量影響相對較小，只是寫入RT會變長。