## 主要特性 ## 訂閱與發布 消息的發布是指某個生產者向某個topic發送消息；消息的訂閱是指某個消費者關注了某個topic中帶有某些tag的消息，進而從該topic消費數據。 ## 消息過濾 RocketMQ的消費者可以根據Tag進行消息過濾，也支持自定義屬性過濾。消息過濾目前是在Broker端實現的，優點是減少了對于Consumer無用消息的網絡傳輸，缺點是增加了Broker的負擔、而且實現相對復雜 ## 至少一次 至少一次(At least Once)指每個消息必須投遞一次。Consumer先Pull消息到本地，消費完成后，才向服務器返回ack，如果沒有消費一定不會ack消息，所以RocketMQ可以很好的支持此特性 ## 回溯消費 回溯消費是指Consumer已經消費成功的消息，由于業務上需求需要重新消費，要支持此功能，Broker在向Consumer投遞成功消息后，消息仍然需要保留。并且重新消費一般是按照時間維度，例如由于Consumer系統故障，恢復后需要重新消費1小時前的數據，那么Broker要提供一種機制，可以按照時間維度來回退消費進度。RocketMQ支持按照時間回溯消費，時間維度精確到毫秒 ## 消息重投 生產者在發送消息時，同步消息失敗會重投，異步消息有重試，oneway沒有任何保證。消息重投保證消息盡可能發送成功、不丟失，但可能會造成消息重復，消息重復在RocketMQ中是無法避免的問題。消息重復在一般情況下不會發生，當出現消息量大、網絡抖動，消息重復就會是大概率事件。另外，生產者主動重發、consumer負載變化也會導致重復消息。如下方法可以設置消息重試策略： * retryTimesWhenSendFailed:同步發送失敗重投次數，默認為2，因此生產者會最多嘗試發送retryTimesWhenSendFailed + 1次。不會選擇上次失敗的broker，嘗試向其他broker發送，最大程度保證消息不丟。超過重投次數，拋出異常，由客戶端保證消息不丟。當出現RemotingException、MQClientException和部分MQBrokerException時會重投。 * retryTimesWhenSendAsyncFailed:異步發送失敗重試次數，異步重試不會選擇其他broker，僅在同一個broker上做重試，不保證消息不丟。 * retryAnotherBrokerWhenNotStoreOK:消息刷盤（主或備）超時或slave不可用（返回狀態非SEND\_OK），是否嘗試發送到其他broker，默認false。十分重要消息可以開啟 ## 流量控制 生產者流控，因為broker處理能力達到瓶頸；消費者流控，因為消費能力達到瓶頸。 生產者流控： * commitLog文件被鎖時間超過osPageCacheBusyTimeOutMills時，參數默認為1000ms，返回流控。 * 如果開啟transientStorePoolEnable == true，且broker為異步刷盤的主機，且transientStorePool中資源不足，拒絕當前send請求，返回流控。 * broker每隔10ms檢查send請求隊列頭部請求的等待時間，如果超過waitTimeMillsInSendQueue，默認200ms，拒絕當前send請求，返回流控。 * broker通過拒絕send 請求方式實現流量控制。 注意，生產者流控，不會嘗試消息重投。 消費者流控： * 消費者本地緩存消息數超過pullThresholdForQueue時，默認1000。 * 消費者本地緩存消息大小超過pullThresholdSizeForQueue時，默認100MB。 * 消費者本地緩存消息跨度超過consumeConcurrentlyMaxSpan時，默認2000。 消費者流控的結果是降低拉取頻率