本文主要介紹云消息隊列 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++:收發定時消息和延時消息