純真破解工作室█████【電；18230062509】█████歡迎有需要的老闆私聊！！！訊息的釋出是指某個生產者向某個topic傳送訊息；訊息的訂閱是指某個消費者關注了某個topic中帶有某些tag的訊息。
2、訊息順序
訊息有序指的是一類訊息消費時，能按照傳送的順序來消費。例如：一個訂單產生了三條訊息分別是訂單建立、訂單付款、訂單完成。消費時要按照這個順序消費才能有意義，但是同時訂單之間是可以並行消費的。RocketMQ可以嚴格的保證訊息有序。
3、訊息過濾
RocketMQ的消費者可以根據Tag進行訊息過濾，也支援自定義屬性過濾。訊息過濾目前是在Broker端實現的，優點是減少了對於Consumer無用訊息的網路傳輸，缺點是增加了Broker的負擔、而且實現相對複雜。
4、訊息可靠性
RocketMQ支援訊息的高可靠，影響訊息可靠性的幾種情況：
1、Broker非正常關閉
2、Broker異常Crash
3、作業系統Crash
4、機器掉電，但是能立即恢復供電情況
5、機器無法開機（可能是cpu、主機板、記憶體等關鍵裝置損壞）
6、磁碟裝置損壞
注意事項
前四種情況都屬於硬體資源可立即恢復情況，RocketMQ在這四種情況下能保證訊息不丟，或者丟失少量資料（依賴刷盤方式是同步還是非同步）。
最後兩種情況屬於單點故障，且無法恢復，一旦發生，在此單點上的訊息全部丟失。
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 8m9m 10m 20m 30m 1h 2h”，18個level。
messageDelayLevel是broker的屬性，不屬於某個topic。
發訊息時，設定delayLevel等級即可：msg.setDelayLevel(level)。
level有以下三種情況：
level == 0，訊息為非延遲訊息
1<=level<=maxLevel，訊息延遲特定時間，例如level==1，延遲1
slevel > 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消費訊息失敗通常可以認為有以下幾種情況：
1、由於訊息本身的原因，例如反序列化失敗，訊息資料本身無法處理（例如話費充值，當前訊息的手機號被登出，無法充值）等。這種錯誤通常需要跳過這條訊息，再消費其它訊息，而這條失敗的訊息即使立刻重試消費，99%也不成功，所以最好提供一種定時重試機制，即過10秒後再重試。
2、由於依賴的下游應用服務不可用，例如db連線不可用，外系統網路不可達等。遇到這種錯誤，即使跳過當前失敗的訊息，消費其他訊息同樣也會報錯。這種情況建議應用sleep 30s，再消費下一條訊息，這樣可以減輕Broker重試訊息的壓力。
10、訊息重投
生產者在傳送訊息時：
同步訊息失敗會重投
非同步訊息有重試
oneway沒有任何保證。
訊息重投保證訊息儘可能傳送成功、不丟失，但可能會造成訊息重複，訊息重複在RocketMQ中是無法避免的問題。訊息重複在一般情況下不會發生，當出現訊息量大、網路抖動，訊息重複就會是大概率事件。另外，生產者主動重發、consumer負載變化也會導致重複訊息。
本作品採用《CC 協議》，轉載必須註明作者和本文連結