本文主要介紹雲訊息佇列 RocketMQ 版的定時訊息和延時訊息的概念、適用情境以及使用過程中的注意事項。
概念介紹
- 定時訊息：Producer將訊息發送到雲訊息佇列 RocketMQ 版服務端，但並不期望立馬投遞這條訊息，而是延遲到在目前時間點之後的某一個時間投遞到Consumer進行消費，該訊息即定時訊息。
- 延時訊息：Producer將訊息發送到雲訊息佇列 RocketMQ 版服務端，但並不期望立馬投遞這條訊息，而是延遲一定時間後才投遞到Consumer進行消費，該訊息即延時訊息。
定時訊息與延時訊息在代碼配置上存在一些差異，但是最終達到的效果相同：訊息在發送到雲訊息佇列 RocketMQ 版服務端後並不會立馬投遞，而是根據訊息中的屬性延遲固定時間後才投遞給消費者。
適用情境
定時訊息和延時訊息適用於以下一些情境：
- 訊息生產和消費有時間視窗要求，例如在電商交易中逾時未支付關閉訂單的情境，在訂單建立時會發送一條延時訊息。這條訊息將會在30分鐘以後投遞給消費者，消費者收到此訊息後需要判斷對應的訂單是否已完成支付。如支付未完成，則關閉訂單。如已完成支付則忽略。
- 通過訊息觸發一些定時任務，例如在某一固定時間點向使用者發送提醒訊息。
使用方式
定時訊息和延時訊息的使用在代碼編寫上存在略微的區別：
- 發送定時訊息需要明確指定訊息發送時間點之後的某一時間點作為訊息投遞的時間點。
- 發送延時訊息時需要設定一個延時時間長度，訊息將從當前發送時間點開始延遲固定時間之後才開始投遞。
定時和延時時間設定規則
- 定時和延時訊息的
msg.setStartDeliverTime參數需要設定成目前時間戳之後的某個時刻（單位毫秒）。如果被設定成目前時間戳之前的某個時刻，訊息將立刻投遞給消費者。 - 定時和延時訊息的
msg.setStartDeliverTime參數可設定40天內的任何時刻（單位毫秒），超過40天訊息發送將失敗。
使用限制
訊息類型一致性
訊息類型必須和Topic類型一致。即您在雲訊息佇列 RocketMQ 版控制台建立Topic時選擇的消息类型為定时/延时消息，則該Topic只能用於發送定時和延時訊息，不支援發送普通訊息。
定時和延時時間精度
- 定時訊息的精度會有1s~2s的延遲誤差。
StartDeliverTime是服務端開始向消費端投遞的時間。如果消費者當前有訊息堆積，那麼定時和延時訊息會排在堆積訊息後面，將不能嚴格按照配置的時間進行投遞。- 由於用戶端和服務端可能存在時間差，訊息的實際投遞時間與用戶端設定的投遞時間之間可能存在偏差。
- 設定定時和延時訊息的投遞時間後，依然受3天的訊息儲存時間長度限制。
例如，設定定時訊息5天后才能被消費，如果第5天后一直沒被消費，那麼這條訊息將在第8天被刪除。
TCP協議範例程式碼
收發定時訊息和延時訊息的範例程式碼，請參見以下文檔：
HTTP協議範例程式碼
收發定時訊息和延時訊息的範例程式碼，請參見以下文檔：
- Java：收發定時訊息和延時訊息
- Go：收發定時訊息和延時訊息
- Python：收發定時訊息和延時訊息
- Node.js：收發定時訊息和延時訊息
- PHP：收發定時訊息和延時訊息
- C#：收發定時訊息和延時訊息
- C++：收發定時訊息和延時訊息