RabbitMQ：3、進階

保證消息的安全

持久化

• 交換器持久化：聲明交換器時指定持久化
• 隊列持久化：聲明隊列時指定持久化
• 消息持久化：發送消息時指定持久化
  通常隊列和消息持久化要同時聲明，此外消息假如進了交換器卻找不到隊列，也會丟失，必要時添加mandatory參數或者備份交換器。
  持久化會下降吞吐量。

消費者確認

• 訂閱隊列時設置autoAck爲false

生產者確認

• 事務
  • channel.txSelect()
  • channel.txCommit()
  • channel.txRollback()
• 發送方確認（confirm機制）
  • 普通確認：吞吐量低
  • 批量確認：丟失率高的時候影響效率
  • 異步確認：推薦使用，channel.addConfirmListener

過時時間TTL

• 隊列的過時時間TTL
• 消息的過時時間TTL

死信隊列

• 死信
  • 消息被拒絕
  • 消息過時
  • 隊列達到最大長度
• 死信會進入死信交換器，而後進入死信隊列
• 能夠用死信隊列來作延遲隊列

優先級隊列

• 發送時設置消息優先級

消費端要點

消息分發

• RabbitMQ擁有多個消費者時，隊列收到的消息會以輪詢的分發方式發送給消費者。每條消息只會發送給訂閱列表裏的一個消費者。這種方式很是適合擴展，並且它是專門爲併發程序設計的。若是如今負載加劇，那麼只須要建立更多的消費者來消費處理消息便可。
• 輪詢的方式會將m條消息發給第m%n（n是消費者數量）個消費者，這有可能致使消費者消費不均（有些消費者消費較快，而任務是均攤的，致使CPU空閒），而channel.basicQos（）方法容許限制信道上的消費者所能保持的最大未確認消息的數量。在訂閱消費隊列以前，消費端程序調用了 channel.basicQos(5) ，以後訂閱了某個隊列進行消費。 RabbitM 會保存一個消費者的列表，每發送一條消息都會爲對應的消費者計數，若是達到了所設定的上限，那麼 RabbitMQ 就不會向這個消費者再發送任何消息。直到消費者確認了某條消息以後 RabbitMQ 將相應的計數減1，以後消費者能夠繼續接收消息，直到再次到達計數上限。這種機制能夠類比於 TCP!IP中的"滑動窗口"。

消息順序性

• 消費進入隊列時是順序的，消費時也不能保證順序性，若是是須要順序消費的消息須要在業務方進行處理，如添加全局有序標識等等。

消息傳輸保障

• 至少一次：消息不會丟失，但可能重複發送，經過持久化，發送者確認，消費者確認等手段保證消息毫不丟失，至少發送一次。
• 至多一次：消息發送一次，可能丟失。直接發送便可。
• 剛好一次：RabbitMQ不支持。