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不支持。