RabbitMQ的消息限流與延時隊列

  1. 消息隊列如何限流?

消息隊列限流是指在服務器面臨鉅額流量時,爲了避免服務器崩潰,進行降級操作把處理不了的流量隔絕在系統之外。

RabbitMQ 提供了一種 qos (服務質量保證)功能,即在非自動確認消息的前提下,如果一定數目的消息(通過基於 consume 或者 channel 設置 Qos 的值)未被確認前,不進行消費新的消息。

  • 需要關閉自動 ack,將 autoAck 設置爲 false
  • 設置具體的限流大小以及數量
  • 在消費者的 handleDelivery 消費方法中手動 ack,並且設置批量處理 ack 迴應爲 true

TTL

TTL是Time To Live的縮寫,也就是生存時間。

RabbitMQ支持消息的過期時間,在消息發送時可以進行指定。

RabbitMQ支持隊列的過期時間,從消息入隊列開始計算,只要超過了隊列的超時時間配置,那麼消息會自動的清除。

RabbitMQ allows you to set TTL (time to live) for both messages and queues. This can be done using optional queue arguments or policies (the latter option is recommended). Message TTL can be enforced for a single queue, a group of queues or applied for individual messages. RabbitMQ允許您爲消息和隊列設置TTL(生存時間)。 這可以使用可選的隊列參數或策略來完成(建議使用後一個選項)。 可以對單個隊列,一組隊列強制執行消息TTL,也可以爲單個消息應用消息TTL。

1.消息的 TTL

在生產端發送消息的時候可以在 properties 中指定 expiration屬性來對消息過期時間進行設置,單位爲毫秒(ms)。

也可以後臺管理頁面中進入 Exchange 發送消息指定expiration

2.隊列的 TTL

在後臺管理界面中新增一個 queue,創建時可以設置 ttl,對於隊列中超過該時間的消息將會被移除。

死信隊列

沒有被及時消費的消息存放的隊列

消息沒有被及時消費的原因:

a.消息被拒絕(basic.reject/ basic.nack)並且不再重新投遞 requeue=false

b.TTL(time-to-live) 消息超時未消費

c.達到最大隊列長度

實現死信隊列步驟:

1.置死信隊列的 exchange 和 queue然後進行綁定; 2.在普通目標隊列加上一個參數即可:arguments.put("x-dead-letter-exchange",' dlx.exchange' )

這樣消息在過期、requeue失敗、 隊列在達到最大長度時,消息就可以直接路由到死信隊列

DLX也是一個正常的 Exchange和一般的 Exchange 沒有區別,它能在任何的隊列上被指定。當這個隊列中有死信時,RabbitMQ 就會自動的將這個消息重新發布到設置的 Exchange 上去,進而被路由到另一個隊列。可以監聽這個隊列中消息做相應的處理。

適用場景:

1.訂單在十分鐘之內未支付則自動取消。

2.新創建的店鋪,如果在十天內都沒有上傳過商品,則自動發送消息提醒。

3.賬單在一週內未支付,則自動結算。

4.用戶註冊成功後,如果三天內沒有登陸則進行短信提醒。

5.用戶發起退款,如果三天內沒有得到處理則通知相關運營人員。

6.預定會議後,需要在預定的時間點前十分鐘通知各個與會人員參加會議。

7.物聯網系統經常會遇到向終端下發命令,如果命令一段時間沒有應答,就需要設置成超時。

在 RabbitMQ 3.6.x 開始,RabbitMQ 官方提供了延遲隊列的插件,可以下載放置到 RabbitMQ 根目錄下的 plugins 下。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章