面試連環炮系列（五）：你們的項目為什么要用RabbitMQ

1. 你們的項目為什么要用RabbitMQ？
   消息隊列的作用是系統解耦、同步改異步、請求消峰，舉個下訂單的例子：
   前端獲取用戶訂單信息，請求后端的訂單創建接口。這個接口並不直接請求訂單服務，而是首先生成唯一訂單編號，再組裝一個訂單消息並發送給RabbitMQ，然后返回唯一訂單編號給前端。前端會根據唯一訂單編號輪詢訂單狀態接口，如果訂單創建成功，則拉起支付界面引導用戶付款。作為消費者，訂單服務收到訂單消息后，開始檢查參數、檢查庫存、生成訂單等等核心業務流程。
   解耦體現在訂單創建接口並沒有直接訪問訂單服務，使得它不用關注訂單服務接口的變化。由於不是直接調用，同步操作變成了異步操作。試想一下，訂單創建狀態是同步返回的，用戶界面必然卡起來。由於消息隊列允許消息堆積，即使大量的用戶訂單涌過來，訂單服務依然能夠穩步的處理訂單消息。

2. 為什么非要用RabbitMQ，考慮過RocketMQ或者ActiveMQ嗎？
   近些年ActiveMQ更新較少，而且沒有大規模吞吐量場景的驗證，就不考慮了。我們考慮過RocketMQ，無論是可用性、吞吐量、成功案例，它都很不錯。我們的運維團隊對RabbitMQ更熟悉，而且更看重消息的可靠性，最后選擇了RabbitMQ。

3. 采用RabbitMQ怎么避免消息丟失？

   1. 生產者丟失消息：RabbitMQ提供transaction和confirm模式來確保生產者不丟消息。開啟事務channel.txSelect()，然后發送消息，如果發送過程中出現什么異常，事務就會回滾channel.txRollback()，如果發送成功則提交事務channel.txCommit()。但是這種方式會導致吞吐量下降。confirm模式用的居多：一旦channel進入confirm模式，所有在該信道上發布的消息都將會被指派一個唯一的ID（從1開始），一旦消息被投遞到所有匹配的隊列之后；rabbitMQ就會發送一個ACK給生產者（包含消息的唯一ID），這就使得生產者知道消息已經正確到達目的隊列了；如果rabbitMQ沒能處理該消息，則會發送一個Nack消息給生產者，生產者可以重試。
   2. 消息列表丟失消息：開啟持久化磁盤的配置
   3. 消費者丟失消息：處理消息成功后，手動回復確認消息。

4. 通過RabbitMQ能實現定時任務嗎？
   RabbitMQ並不支持設置定時消息，但是可以通過過期消息和死信隊列來實現。
   有2種方式設置消息的過期時間，第一種通過對隊列進行設置，該隊列中所有的消息都存在相同的過期時間，第二種對消息本身進行設置，那么每條消息的過期時間都不一樣。如果同時使用這2種方法，那么以過期時間小的那個數值為准。當消息達到過期時間還沒有被消費，那個消息就成為了一個死信消息。消費者監聽死信交換器綁定的隊列，就能消費到消息，做相應的業務處理。

5. 哪幾種情況會變成死信消息？
   3種情況，消息被拒絕、消息過期了、隊列達到最大的長度。

參考(部分摘抄的文字版權屬於原作者)：

https://www.cnblogs.com/woadmin/p/10537174.html
https://blog.csdn.net/jerryDzan/article/details/89183625

雞湯：不要裝逼，別人都看得出來。