（1）Publis/Subscribe

釋出訂閱是訊息中介軟體的最基本功能，是相對於傳統的RPC通訊而言。

（2）Message　Priority

規範中描述的優先順序是指在一個訊息佇列中，每條訊息都有不同的優先順序，一般用整數來描述，優先順序高的資訊先投遞，如果訊息完全在一個記憶體佇列中，那麼在投遞前可以按照優先順序排序，令優先順序高的先投遞。

由於RocketMQ所有的訊息都是持久化的，所以如果按照優先順序排序，開銷會非常大，因此RockeMQ沒有特意支援訊息優先順序，但是可以通過變通的方式實現類似的功能，即單獨配置一個優先順序高的佇列和一個普通優先順序的佇列。將不同優先順序傳送到不同佇列即可、

對於優先順序問題，歸納為2類：

a、只要達到優先順序目的即可，不是嚴格意義上的優先順序，通常優先順序劃分為高中低或者更多，每個優先順序可以用不同的topic表示，發訊息時，指定不同的topic表示優先順序，這種方式可以解決絕大部分的優先順序問題，但是對業務的優先順序精確性做了妥協。
b、嚴格優先順序，優先順序用整數表示，如0-65535，這種優先順序問題如果用topic解決就不行，如果要MQ解決，會對MQ的效能造成非常大的影響。

（3）Message Order

訊息有序指的是一類訊息消費時，按照發送的順序來消費，例如一個訂單產生了3條訊息，分別是訂單建立，訂單付款，訂單完成，消費時，必須按照這個順序才有意義，但同時訂單之間是可以並行消費的。

RocketMQ是可以嚴格保證訊息有序。

（4）Message Filter

   Broker端過濾訊息，在Broker中，按照Consumer的要求做過濾，優點是減少了對於Consumer無用訊息進行網路傳輸，缺點是增加了Broker的負擔，實現相對複雜。

    （a）淘寶Notify支援多種過濾方式，包括直接按照訊息型別過濾，靈活的語法表示式過濾，幾乎可以滿足最苛刻過濾要求、

   （b）淘寶RocketMQ支援按照簡單的Message Tag過濾，也支援按照Message Header、body進行過濾、

consumer端訊息過濾

   這種過濾方式可由應用完全自定義實現，缺點是很多無用訊息要傳輸到Consumer端。

（5）Message Persistence

訊息中介軟體通常採用幾種持久化方式：

（1）持久化到資料庫，例如MySql

（2）持久化到KV儲存

（3）檔案記錄形式持久化

（4）對記憶體資料做一個持久化映象

（1）（2）（3）三中持久化方式都具有將記憶體佇列Buffer進行擴充套件的能力，（4）只是一個記憶體的映象，作用是當Broker掛掉重啟後仍然能將之前記憶體的資料恢復出來。

RocketMQ 參考了Kafka的持久化方式，充分利用Linux檔案系統記憶體Cache來提高效能。

（6）Message Reliablity

影響訊息可靠性的幾種情況：

（1）Broker正常關閉

（2）Broker異常Crash

（3）OS Crash

（4）機器掉電，但是能立即恢復供電情況、

（5）機器無法開機

（6）磁碟裝置損壞

1、2、3、4都屬於硬體資源可立即恢復情況，RocketMQ在這四種情況下能保證訊息不丟，或者丟失少量資料（依賴刷盤方式是非同步還是同步）

5、6屬於單點故障，且無法恢復，一旦發生，在此單點上的訊息全部丟失，RocketMQ在這兩種情況下，通過非同步複製，可保證99%的訊息不丟，但是仍然會有極少量的訊息可能丟失，通過同步雙寫技術可以完全避免單點，同步雙寫勢必會影響效能，適合對訊息可靠性要求極高的場合，例如與錢相關的應用。

RocketMQ從3.0開始支援同步雙寫。

（7）Low Latency Messaging

在訊息不堆積的情況下，訊息到達Broker後，能立刻到達Consumer。

RocketMQ使用長輪詢Pull方式，可保證訊息非常實時，訊息實時性不低於Push.

（8）At least Once

指每個訊息必須投遞一次

RocektMQ consumer 先pull訊息到本地，消費完成後，才想伺服器返回ack，如果沒有消費一定不會ack，所以RocketMQ可以很好支援此特性。

（9）Exactly Only Once

（a）傳送訊息階段，不允許傳送重複的訊息

（b）消費訊息階段，不允許消費重複的訊息。

只有以上兩個條件都滿足的情況下，才認為訊息是“Exactly only once”，而要實現以上兩點，在分散式環境下，不可避免要產生巨大的開銷，所以RocketMQ為了追求高效能，並不保證此特性，要求在業務上進行去重，也就是消費訊息要做到冪等性，RocketMQ雖然不能嚴格保證不重複，但是正常情況下，很少會出現重複傳送，消費的情況，只有網路異常，Consumer啟停等異常情況下會出現訊息重複。

此問題本質原因是網路呼叫存在不確定性，導致出現既不成功也不失敗的第三種狀態，所以才產生了訊息重複性問題。

（10）Broker的Buffer滿了怎麼辦

Broker的Buffer指的是Broker中一個佇列的記憶體Buffer大小，這類Buffer通常大小有限，若Buffer滿了怎麼辦？

CORBA Notification規範中處理方式：

（1）RejectNewEvents 拒絕新來的訊息，向Producer返回RejectNewEvents錯誤碼。

（2）按照特定策略丟棄已有的訊息

RocketMQ沒有記憶體Buffer概念，RocketMQ的佇列都是持久化磁碟，資料定期清除。

對於此問題的解決思路，RocketMQ同其他MQ有非常顯著的區別，RocketMQ記憶體Buffer抽象成一個無限長度的佇列，不管有多少資料進來都能裝的進來，這個無限是有前提的，Broker會定期刪除過期的資料，例如Broker只會儲存3天的訊息，那麼這個Buffer雖然長度無限，但是3天前的資料會被從隊尾刪除。

（11）回溯訊息

回溯訊息是指Consumer已經消費成功的訊息，由於業務上需求需要重新消費，要支援此功能，Broker在向Consumer投遞成功訊息後，訊息仍然需要保留，並且重新消費一般是按照時間維度，例如由於Consumer系統故障，恢復後需要重新消費1小時前的資料，那麼Broker要提供一種機制，可以按照時間維度來回退消費進度。

RocketMQ支援按照時間回溯消費，時間維度精確到毫秒，可以向前回溯，也可以向後回溯。

（12）訊息堆積

訊息中介軟體的主要功能是非同步解耦，還有個重要功能是擋住前端的資料洪峰，保證後端系統的穩定性，這就要求訊息中介軟體有一定的訊息堆積能力，訊息堆積分以下兩種情況：
（a）訊息堆積在記憶體Buffer，一旦超過記憶體Buffer，可以根據一定的丟棄策略來丟棄訊息。

（b）訊息堆積到持久化儲存系統中，例如DB，KV，檔案記錄形式。

當訊息不能在記憶體cache命中時，要不可避免的訪問磁碟，會產生大量讀IO，讀IO的吞吐量直接決定了訊息堆積後的訪問能力

（13）分散式事務

分散式事務涉及到兩階段提交問題，在資料儲存方面必然需要支援KV儲存的支援，因為第二階段的提交回滾需要修改訊息狀態，一定涉及到根據key去查詢Message動作，RocketMQ在第二階段繞過了根據key去查詢Message的問題，採用第一階段傳送Prepared訊息時，拿到了訊息的offset，第二階段通過offset去訪問訊息，並修改狀態，offset就是資料的地址。

RocketMQ這種實現事務方式，沒有通過KV儲存做，而是通過offset方式，存在一個顯著的缺陷，即通過offset更改資料，會令系統的髒頁過多，需要特別關注。

（14）定時訊息

定時訊息指訊息傳送到Broker後，不能立刻被Consumer消費，要到特定的時間點或者特定的時間後才能被消費。

如果要支援任意的時間精度，在Broker層面，必須要做訊息排序，如果在涉及到持久化，那麼訊息排序要不可避免產生巨大效能開銷。

RocketMQ支援定時訊息，但是不支援任意時間精度，支援特定的level1

（15）訊息重試

Consumer消費訊息失敗後，要提供一種重試機制，令訊息在消費一次，consumer消費訊息失敗通常可以認為以下幾種情況：

1、由於訊息本身的原因，例如反序列化失敗，訊息資料本身無法處理（如充話費，當前訊息的手機號被登出，無法充值），這種錯誤通常需要跳過這條訊息，再消費其他訊息，而這條失敗的訊息即使立刻重試消費，99%也不成功，所以最好提供一種定時重試機制，即過10s在重試。

2、由於依賴的下游應用服務不可用，例如db連線不可用，外系統網路不可到達

遇到這種錯誤，即使跳過當前失敗訊息，消費其他訊息同樣也會報錯，這種情況建議應用sleep 30s，再消費下一條訊息，這樣可以減輕Broker重試訊息的壓力。