RocketMQ特性及面試（下）

8、主動同步策略：同步雙寫、異步複製

8.1 多 Master 多 Slave 模式，異步複製

每一個 Master 配置一個 Slave，有多對Master-Slave，HA 採用異步複製方式，主備有短暫消息延遲，毫秒級。

• 優勢：即便磁盤損壞，消息丟失的很是少，且消息實時性不會受影響，由於 Master 宕機後，消費者仍然能夠從 Slave 消費，此過程對應用透明。不須要人工干預。性能同多 Master 模式幾乎同樣。

• 缺點：Master 宕機，磁盤損壞狀況，會丟失少許消息。

8.2 多 Master 多 Slave 模式，同步雙寫

每一個 Master 配置一個 Slave，有多對Master-Slave，HA 採用同步雙寫方式，主備都寫成功，嚮應用返回成功。

• 優勢：數據與服務都無單點，Master宕機狀況下，消息無延遲，服務可用性與數據可用性都很是高

• 缺點：性能比異步複製模式略低，大約低 10%左右，發送單個消息的 RT 會略高。目前主宕機後，備機不能自動切換爲主機，後續會支持自動切換功能。

9、消息的刷盤策略

9.1 異步刷盤（ASYNC_FLUSH）

返回成功狀態時，消息只是被寫入內存 pagecache，寫操做返回快，吞吐量達，當內存裏的消息積累到必定程度時，統一出發寫磁盤動做，快速寫入。

在有 RAID 卡，SAS 15000 轉磁盤測試順序寫文件，速度能夠達到 300M 每秒左右，而線上的網卡通常都爲千兆網卡，寫磁盤速度明顯快於數據網絡入口速度，那舉是否能夠作到寫完內存就吐用戶返回，由後臺線程刷盤呢？

因爲磁盤速度大於網卡速度，那麼刷盤的進度確定能夠跟上消息的寫入速度。 萬一因爲此時系統壓力過大，可能堆積消息，除了寫入 IO，還有讀取 IO，萬一出現磁盤讀取落後狀況， 會不會致使系統內存溢出，答案是否認的，緣由以下： a) 寫入消息到 pagecache 時，若是內存不足，則嘗試丟棄乾淨的 page，騰出內存供新消息使用，策略是 LRU 方式。 b) 若是乾淨頁不足，此時寫入 pagecache 會被阻塞，系統嘗試刷盤部分數據，大約每次嘗試 32 個 page，來找出更多幹淨 page。

綜上，內存溢出的狀況不會出現。

9.2 同步刷盤（SYNC_FLUSH）

返回成功狀態時，消息已經被寫入磁盤。

消息寫入內存 pagecache 後，當即通知刷盤線程，刷盤完成後，返回消息寫成功的狀態。

同步刷盤與異步刷盤的惟一區別是異步刷盤寫完 pagecache 直接返回，而同步刷盤須要等待刷盤完成才返回， 同步刷盤流程以下：

1. 寫入 pagecache 後，線程等待，通知刷盤線程刷盤。
2. 刷盤線程刷盤後，喚醒前端等待線程，多是一批線程。
3. 前端等待線程吐用戶返回成功。

10、消息持久性

RocketMQ收到消息後，會將消息持久化到文件，並利用Linux文件系統內存來提升性能

11、消息存儲

11.1 RocketMQ存儲模型：

RocketMQ的消息的存儲是由ConsumeQueue和CommitLog 配合來完成的，ConsumeQueue中只存儲不多的數據，消息主體都是經過CommitLog來進行讀寫。

CommitLog： 是消息主體以及元數據的存儲主體，對CommitLog創建一個ConsumeQueue，每一個ConsumeQueue對應一個（概念模型中的）MessageQueue，因此只要有Commit Log在，Consume Queue即便數據丟失，仍然能夠恢復出來。 Consume Queue： 是一個消息的邏輯隊列，存儲了這個Queue在CommitLog中的起始offset，log大小和MessageTag的hashCode。每一個Topic下的每一個Queue都有一個對應的ConsumerQueue文件，例如Topic中有三個隊列，每一個隊列中的消息索引都會有一個編號，編號從0開始，往上遞增。並由此一個位點offset的概念，有了這個概念，就能夠對Consumer端的消費狀況進行隊列定義。

• RocketMQ的broker端，不負責推送消息，不管消費者是否消費消息，都將消息存儲起來。誰要消費消息，就向broker發請求獲取消息，消費記錄由consumer來維護。RocketMQ提供了兩種存儲方式來保留消費記錄：一種是保留在consumer所在的服務器上；另外一種是保存在broker服務器上。用戶還能夠本身實現相應的消費進度存儲接口。

• 默認狀況下，採用集羣消費（CLUSTERING），會將記錄保存在broker端；而採用廣播消費（BROADCASTING）則會將消費記錄保存在本地。

• RocketMQ以Topic來管理不一樣應用的消息。對於生產者而言，發送消息是，須要指定消息的Topic，對於消費者而言，在啓動後，須要訂閱相應的Topic，而後能夠消費相應的消息。Topic是邏輯上的概念，在物理實現上，一個Topic由多個Queue組成，採用多個Queue的好處是能夠將Broker存儲分佈式化，提升系統性能。

• RocketMQ中，producer將消息發送給Broker時，須要制定發送到哪個隊列中，默認狀況下，producer會輪詢的將消息發送到每一個隊列中（全部broker下的Queue合併成一個List去輪詢）。

• 對於consumer而言，會爲每一個consumer分配固定的隊列（若是隊列總數沒有發生變化），consumer從固定的隊列中去拉取沒有消費的消息進行處理。

11.2 RocketMQ存儲特色：

零拷貝原理：Consumer 消費消息過程，使用了零拷貝，零拷貝包含如下兩種方式：

1. 使用 mmap + write 方式
   • 優勢：即便頻繁調用，使用小塊文件傳輸，效率也很高
   • 缺點：不能很好的利用 DMA 方式，會比 sendfile 多消耗CPU，內存安全性控制複雜，須要避免 JVM Crash 問題。
2. 使用 sendfile 方式
   • 優勢：能夠利用 DMA 方式，消耗 CPU 較少，大塊文件傳輸效率高，無內存安全新問題。
   • 缺點：小塊文件效率低亍 mmap 方式，只能是 BIO 方式傳輸，不能使用 NIO。 RocketMQ 選擇了第一種方式，mmap+write 方式，由於有小塊數據傳輸的需求，效果會比 sendfile 更好。

11.3 RocketMQ 數據存儲結構：

12、消息堆積

Producer 已經將消息發送到消息隊列 RocketMQ 的服務端，但因爲 Consumer 消費能力有限，未能在短期內將全部消息正確消費掉，此時在消息隊列 RocketMQ 的服務端保存着未被消費的消息，該狀態即消息堆積。

支持10億級別的消息堆積，不會由於消息堆積影響性能。
若是出現消息堆積而且性能明顯降低的狀況，首先查看RocketMQ控制檯，查看消費者狀態找尋性能降低主機，查看堆棧信息，以後查看 ConsumeMessageThread 的狀態與堆棧。

十3、消息可靠性

生產者的可靠性保證：生產者發送消息後返回SendResult，若是isSuccess返回true，則表示消息已經確認發送到服務器並被服務器接收保存。整個發送過程是一個同步過程。

服務器的可靠性：消息生產者發送的消息，RocketMQ服務收到後在作必要的校驗和檢查以後立刻保存到磁盤，寫入成功後返回給生產者。所以能夠確認每條發送結果爲成功的消息都會被消息服務器寫入磁盤。

消費者的可靠性：消費者是一條一條順序消費的，以後在成功消費一條後纔會消費嚇一跳。若是在消費某一條消息時失敗則會重試消費這條消息，默認爲5次，若是超過最大次數仍然沒法消費，則將消息保存到本地，後臺線程繼續重試消費，主線程則會繼續日後走，消費隊列後面的消息。

十4、消息過濾

Consumer 能夠根據消息標籤（Tag）對消息進行過濾，確保 Consumer 最終只接收被過濾後的消息類型。消息過濾在消息隊列 RocketMQ 的服務端完成。

如下圖電商交易場景爲例，從客戶下單到收到商品這一過程會生產一系列消息，好比訂單建立消息（order）、支付消息（pay）、物流消息（logistics）。 這些消息會發送到 Topic 爲 Trade_Topic 的隊列中，被各個不一樣的系統所接收，好比支付系統、物流系統、交易成功率分析系統、實時計算系統等。 其中，物流系統只需接收物流類型的消息（logistics），而實時計算系統須要接收全部和交易相關（order、pay、logistics）的消息。

十5、削峯填谷

流量削鋒也是消息隊列 RocketMQ 的經常使用場景，通常在秒殺或團隊搶購活動中使用普遍。 在秒殺或團隊搶購活動中，因爲用戶請求量較大，致使流量暴增，秒殺的應用在處理如此大量的訪問流量後，下游的通知系統沒法承載海量的調用量，甚至會致使系統崩潰等問題而發生漏通知的狀況。爲解決這些問題，可在應用和下游通知系統之間加入消息隊列 RocketMQ，以下圖所示。

秒殺處理流程以下所述：

1. 用戶發起海量秒殺請求到秒殺業務處理系統。
2. 秒殺處理系統按照秒殺處理邏輯將知足秒殺條件的請求發送至消息隊列 RocketMQ。
3. 下游的通知系統訂閱消息隊列 RocketMQ 的秒殺相關消息，再將秒殺成功的消息發送到相應用戶。
4. 用戶收到秒殺成功的通知。

大規模機器的緩存同步

雙十一大促時，各個分會場會有玲琅滿目的商品，每件商品的價格都會實時變化。使用緩存技術也沒法知足對商品價格的訪問需求，緩存服務器網卡滿載。訪問較屢次商品價格查詢影響會場頁面的打開速度。 此時須要提供一種廣播機制，一條消息原本只能夠被集羣的一臺機器消費，若是使用消息隊列 RocketMQ 的廣播消費模式，那麼這條消息會被全部節點消費一次，至關於把價格信息同步到須要的每臺機器上，取代緩存的做用。