保证消息的安全
持久化
- 交换器持久化：声明交换器时指定持久化
- 队列持久化：声明队列时指定持久化
- 消息持久化：发送消息时指定持久化
一般队列和消息持久化要同时声明，此外消息假如进了交换器却找不到队列，也会丢失，必要时添加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不支持。