使用場景介紹

1、發版時經常需要不停機發版，遇到mq消費者，消費一半停機就會出現訊息丟失（沒有使用手動確認的情況）

2、例如支付場景，準時支付、超過未支付將執行不同的方案，其中超時未支付可以看做一個延時訊息。

3、例如滴滴、淘寶的自動評價都是類似場景（不一定是用的什麼技術）

我是發版的情況遇到了

（類似於假如我做一個事情需要兩步完成，每一步完成都會收錢。那麼就會出現，第一步完成後，停機了，假如使用訊息重發就會造成浪費第一步完成的錢）

實現方式

在網上找資料找到兩種實現方式：

1、使用外掛

2、使用兩個特性

AMQP和RabbitMQ本身沒有直接支援延遲佇列功能，但是可以通過以下特性模擬出延遲佇列的功能。但是我們可以通過RabbitMQ的兩個特性來曲線實現延遲佇列。

Time To Live(TTL)

1. A: 通過佇列屬性設定，佇列中所有訊息都有相同的過期時間。  
2. B: 對訊息進行單獨設定，每條訊息TTL可以不同。  

Dead Letter Exchanges（DLX）

1. 訊息或者佇列的TTL過期  
2. 佇列達到最大長度  
3. 訊息被消費端拒絕（basic.reject or basic.nack）並且requeue=false  

利用DLX，當訊息在一個佇列中變成死信後，它能被重新publish到另一個Exchange。這時候訊息就可以重新被消費。

示例程式碼

初始化過期佇列的程式碼

1. @Bean
2.     public Queue signQueueStore() {  
3.         Map<String, Object> arguments = new HashMap<>();  
4.         arguments.put("x-dead-letter-exchange", exchange);  
5.         arguments.put("x-dead-letter-routing-key", signKey);  
6.         arguments.put("x-message-ttl",300000);  
7.         Queue queue = new Queue(signQueueStore,true,false,false,arguments);  
8.         System.out.println("arguments :" + queue.getArguments());  
9.         return queue;  
10.     }  

繫結過期佇列的程式碼

1. @Bean
2.     public Binding  signStoreBinding() {  
3.         return BindingBuilder.bind(signQueueStore()).to(defaultExchange()).with(signKeyStore);  
4.     }  

初始化正常佇列的程式碼和繫結普通佇列的程式碼

1. @Bean
2.     public Queue signQueue() {  
3.         returnnew Queue(signQueue);  
4.     }  
5.     @Bean
6.     public Binding signBinding(Queue signQueue, DirectExchange defaultExchange) {  
7.         /** 將佇列繫結到交換機 */
8.         return BindingBuilder.bind(signQueue).to(defaultExchange).with(signKey);  
9.     }  

在重啟時將訊息傳送到過期佇列，在重啟完成後，訊息傳送到正常佇列，過期佇列訊息過期後會自動路由到正常佇列進行消費。（可以設定一個標誌，判斷該標誌位重啟狀態，則發到過期佇列，為正常狀態傳送到正常佇列）