1 訂閱與發佈
消息的發佈是指某個生產者向某個topic發送消息；消息的訂閱是指某個消費者關注了某個topic中帶有某些tag的消息，進而從該topic消費數據。
2 消息順序
消息有序指的是一類消息消費時，能按照發送的順序來消費。例如：一個訂單產生了三條消息分別是訂單創建、訂單付款、訂單完成。消費時要按照這個順序消費纔能有意義，但是同時訂單之間是可以並行消費的。RocketMQ可以嚴格的保證消息有序。
順序消息分爲全局順序消息與分區順序消息，全局順序是指某個Topic下的所有消息都要保證順序；部分順序消息只要保證每一組消息被順序消費即可。
全局順序：對於指定的一個 Topic，所有消息按照嚴格的先入先出（FIFO）的順序進行發佈和消費。適用場景：性能要求不高，所有的消息嚴格按照 FIFO 原則進行消息發佈和消費的場景
分區順序：對於指定的一個 Topic，所有消息根據 sharding key 進行區塊分區。 同一個分區內的消息按照嚴格的 FIFO 順序進行發佈和消費。 Sharding key 是順序消息中用來區分不同分區的關鍵字段，和普通消息的 Key 是完全不同的概念。適用場景：性能要求高，以 sharding key 作爲分區字段，在同一個區塊中嚴格的按照 FIFO 原則進行消息發佈和消費的場景。
3 消息過濾
RocketMQ的消費者可以根據Tag進行消息過濾，也支持自定義屬性過濾。消息過濾目前是在Broker端實現的，優點是減少了對於Consumer無用消息的網絡傳輸，缺點是增加了Broker的負擔、而且實現相對複雜。
4 消息可靠性
RocketMQ支持消息的高可靠，影響消息可靠性的幾種情況：
1) Broker非正常關閉
2) Broker異常Crash
3) OS Crash
4) 機器掉電，但是能立即恢復供電情況
5) 機器無法開機（可能是cpu、主板、內存等關鍵設備損壞）
6) 磁盤設備損壞
1)、2)、3)、4) 四種情況都屬於硬件資源可立即恢復情況，RocketMQ在這四種情況下能保證消息不丟，或者丟失少量數據（依賴刷盤方式是同步還是異步）。
5)、6)屬於單點故障，且無法恢復，一旦發生，在此單點上的消息全部丟失。RocketMQ在這兩種情況下，通過異步複製，可保證99%的消息不丟，但是仍然會有極少量的消息可能丟失。通過同步雙寫技術可以完全避免單點，同步雙寫勢必會影響性能，適合對消息可靠性要求極高的場合，例如與Money相關的應用。注：RocketMQ從3.0版本開始支持同步雙寫。
5 至少一次
至少一次(At least Once)指每個消息必須投遞一次。Consumer先Pull消息到本地，消費完成後，才向服務器返回ack，如果沒有消費一定不會ack消息，所以RocketMQ可以很好的支持此特性。
6 回溯消費
回溯消費是指Consumer已經消費成功的消息，由於業務上需求需要重新消費，要支持此功能，Broker在向Consumer投遞成功消息後，消息仍然需要保留。並且重新消費一般是按照時間維度，例如由於Consumer系統故障，恢復後需要重新消費1小時前的數據，那麼Broker要提供一種機制，可以按照時間維度來回退消費進度。RocketMQ支持按照時間回溯消費，時間維度精確到毫秒。
7 事務消息
RocketMQ事務消息（Transactional Message）是指應用本地事務和發送消息操作可以被定義到全局事務中，要麼同時成功，要麼同時失敗。RocketMQ的事務消息提供類似 X/Open XA 的分佈事務功能，通過事務消息能達到分佈式事務的最終一致。
8 定時消息
定時消息（延遲隊列）是指消息發送到broker後，不會立即被消費，等待特定時間投遞給真正的topic。
broker有配置項messageDelayLevel，默認值爲“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18個level。可以配置自定義messageDelayLevel。注意，messageDelayLevel是broker的屬性，不屬於某個topic。發消息時，設置delayLevel等級即可：msg.setDelayLevel(level)。level有以下三種情況：
level == 0，消息爲非延遲消息
1<=level<=maxLevel，消息延遲特定時間，例如level==1，延遲1s
level > maxLevel，則level== maxLevel，例如level==20，延遲2h
定時消息會暫存在名爲SCHEDULE_TOPIC_XXXX的topic中，並根據delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1，即一個queue只存相同延遲的消息，保證具有相同發送延遲的消息能夠順序消費。broker會調度地消費SCHEDULE_TOPIC_XXXX，將消息寫入真實的topic。
需要注意的是，定時消息會在第一次寫入和調度寫入真實topic時都會計數，因此發送數量、tps都會變高。
9 消息重試
Consumer消費消息失敗後，要提供一種重試機制，令消息再消費一次。Consumer消費消息失敗通常可以認爲有以下幾種情況：
由於消息本身的原因，例如反序列化失敗，消息數據本身無法處理（例如話費充值，當前消息的手機號被註銷，無法充值）等。這種錯誤通常需要跳過這條消息，再消費其它消息，而這條失敗的消息即使立刻重試消費，99%也不成功，所以最好提供一種定時重試機制，即過10秒後再重試。
由於依賴的下游應用服務不可用，例如db連接不可用，外系統網絡不可達等。遇到這種錯誤，即使跳過當前失敗的消息，消費其他消息同樣也會報錯。這種情況建議應用sleep 30s，再消費下一條消息，這樣可以減輕Broker重試消息的壓力。
RocketMQ會爲每個消費組都設置一個Topic名稱爲“%RETRY%+consumerGroup”的重試隊列（這裏需要注意的是，這個Topic的重試隊列是針對消費組，而不是針對每個Topic設置的），用於暫時保存因爲各種異常而導致Consumer端無法消費的消息。考慮到異常恢復起來需要一些時間，會爲重試隊列設置多個重試級別，每個重試級別都有與之對應的重新投遞延時，重試次數越多投遞延時就越大。RocketMQ對於重試消息的處理是先保存至Topic名稱爲“SCHEDULE_TOPIC_XXXX”的延遲隊列中，後臺定時任務按照對應的時間進行Delay後重新保存至“%RETRY%+consumerGroup”的重試隊列中。
10 消息重投
生產者在發送消息時，同步消息失敗會重投，異步消息有重試，oneway沒有任何保證。消息重投保證消息儘可能發送成功、不丟失，但可能會造成消息重複，消息重複在RocketMQ中是無法避免的問題。消息重複在一般情況下不會發生，當出現消息量大、網絡抖動，消息重複就會是大概率事件。另外，生產者主動重發、consumer負載變化也會導致重複消息。如下方法可以設置消息重試策略：
retryTimesWhenSendFailed:同步發送失敗重投次數，默認爲2，因此生產者會最多嘗試發送retryTimesWhenSendFailed + 1次。不會選擇上次失敗的broker，嘗試向其他broker發送，最大程度保證消息不丟。超過重投次數，拋出異常，由客戶端保證消息不丟。當出現RemotingException、MQClientException和部分MQBrokerException時會重投。
retryTimesWhenSendAsyncFailed:異步發送失敗重試次數，異步重試不會選擇其他broker，僅在同一個broker上做重試，不保證消息不丟。
retryAnotherBrokerWhenNotStoreOK:消息刷盤（主或備）超時或slave不可用（返回狀態非SEND_OK），是否嘗試發送到其他broker，默認false。十分重要消息可以開啓。
11 流量控制
生產者流控，因爲broker處理能力達到瓶頸；消費者流控，因爲消費能力達到瓶頸。
生產者流控：
- commitLog文件被鎖時間超過osPageCacheBusyTimeOutMills時，參數默認爲1000ms，返回流控。
- 如果開啓transientStorePoolEnable == true，且broker爲異步刷盤的主機，且transientStorePool中資源不足，拒絕當前send請求，返回流控。
- broker每隔10ms檢查send請求隊列頭部請求的等待時間，如果超過waitTimeMillsInSendQueue，默認200ms，拒絕當前send請求，返回流控。
- broker通過拒絕send 請求方式實現流量控制。
注意，生產者流控，不會嘗試消息重投。
消費者流控：
- 消費者本地緩存消息數超過pullThresholdForQueue時，默認1000。
- 消費者本地緩存消息大小超過pullThresholdSizeForQueue時，默認100MB。
- 消費者本地緩存消息跨度超過consumeConcurrentlyMaxSpan時，默認2000。
- 消費者流控的結果是降低拉取頻率。
12 死信隊列
死信隊列用於處理無法被正常消費的消息。當一條消息初次消費失敗，消息隊列會自動進行消息重試；達到最大重試次數後，若消費依然失敗，則表明消費者在正常情況下無法正確地消費該消息，此時，消息隊列 不會立刻將消息丟棄，而是將其發送到該消費者對應的特殊隊列中。
RocketMQ將這種正常情況下無法被消費的消息稱爲死信消息（Dead-Letter Message），將存儲死信消息的特殊隊列稱爲死信隊列（Dead-Letter Queue）。在RocketMQ中，可以通過使用console控制檯對死信隊列中的消息進行重發來使得消費者實例再次進行消費。