rabbitMq實現支付消息通知

作支付平臺的時候。須要實現接受上游支付消息，通知給下游渠道。 針對下游渠道：要實現 按通知次數 遞進 延時通知 下游渠道的支付/簽約/代扣的狀態

可參考微信按照 15/15/30/180/1800/1800/1800/1800/3600 單位s 等5個level去通知下游業務端

當時採用rabbitmq死信隊列實現延時消息的通知： 當一個消息過時後，會自動變成死信。若是消息綁定了dead letter change，那麼消息過時後會被轉發到相應隊列。從而實現消息延遲消費

     

     具體能夠參考相關文章

 

rabbitmq的延時消息分爲兩類（https://www.rabbitmq.com/ttl.html）：

•     per queue message TTL： 隊列中全部消息過時時間同樣，能夠經過建立mq時候增長 message-ttl。設置過時時間
•     per message TTL：能夠爲每一個消息設置過時時間，能夠經過發送消息時候增長 expires。設置過時時間

  當兩種都設置的時候，過時時間按照小的生效。最開始採用  per message TTL即每一個消息的過時時間不一致。可是發現這樣一個現象

 

  問題：當delay_queue中的消息的過時時間不一致的時候，rabbitmq處理機制從性能角度考慮按照FIFO，當queue頭元素未過時時候，後面即便有已通過期的消息時候，

             消息也不會立刻變成死信隊列。而被consumer消費，從而致使了delay_queue消息堆積，消息長時間不被消費的現象。

 

   解決： 採用相似於rocketmq的解決方案。不能級別的延時放在不一樣queue，即delayMs=1000 一個queue，delayMs=2000 一個queue。這樣保證同一個queue中的消息過時時間一致。

               從而解決消息堆積問題。  具體實現很簡單：

1. 1.  預先建立5個level的queue
   2. 照延時時間，選擇對應queue投遞便可