RabbitMQ：三、进阶

保证消息的安全

持久化

• 交换器持久化：声明交换器时指定持久化
• 队列持久化：声明队列时指定持久化
• 消息持久化：发送消息时指定持久化
  一般队列和消息持久化要同时声明，此外消息假如进了交换器却找不到队列，也会丢失，必要时添加mandatory参数或者备份交换器。
  持久化会降低吞吐量。

消费者确认

• 订阅队列时设置autoAck为false

生产者确认

• 事务
  • channel.txSelect()
  • channel.txCommit()
  • channel.txRollback()
• 发送方确认（confirm机制）
  • 普通确认：吞吐量低
  • 批量确认：丢失率高的时候影响效率
  • 异步确认：推荐使用，channel.addConfirmListener

过期时间TTL

• 队列的过期时间TTL
• 消息的过期时间TTL
  同时设置队列和消息的TTL时，按时间小的过期。

死信队列

• 死信
  • 消息被拒绝
  • 消息过期
  • 队列达到最大长度
• 死信会进入死信交换器，然后进入死信队列
• 可以用死信队列来做延迟队列

优先级队列

• 发送时设置消息优先级

服务端限流

• 最大队列长度（个数）
• 最大队列长度（总大小）
• 内存百分比
• 磁盘百分比
• 磁盘绝对值
  达到相应的临界点以后服务端会限制流量，不再接收生产者的消息

消费端限流

• prefetch count：达到该数量无应答以后停止接收消息

消费端要点

消息分发

• RabbitMQ拥有多个消费者时，队列收到的消息会以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者。这种方式非常适合扩展，而且它是专门为并发程序设计的。如果现在负载加重，那么只需要创建更多的消费者来消费处理消息即可。
• 轮询的方式会将m条消息发给第m%n（n是消费者数量）个消费者，这有可能导致消费者消费不均（有些消费者消费较快，而任务是均摊的，导致CPU空闲），而channel.basicQos（）方法允许限制信道上的消费者所能保持的最大未确认消息的数量。在订阅消费队列之前，消费端程序调用了 channel.basicQos(5) ，之后订阅了某个队列进行消费。 RabbitM 会保存一个消费者的列表，每发送一条消息都会为对应的消费者计数，如果达到了所设定的上限，那么 RabbitMQ 就不会向这个消费者再发送任何消息。直到消费者确认了某条消息之后 RabbitMQ 将相应的计数减1，之后消费者可以继续接收消息，直到再次到达计数上限。这种机制可以类比于 TCP!IP中的"滑动窗口"。

消息顺序性

• 消费进入队列时是顺序的，消费时也不能保证顺序性，如果是需要顺序消费的消息需要在业务方进行处理，如添加全局有序标识等等。

消息传输保障

• 至少一次：消息不会丢失，但可能重复发送，通过持久化，发送者确认，消费者确认等手段保证消息绝不丢失，至少发送一次。
• 至多一次：消息发送一次，可能丢失。直接发送即可。
• 恰好一次：RabbitMQ不支持。