RabbitMQ:三、进阶

保证消息的安全

持久化

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

你可能感兴趣的:(RabbitMQ:三、进阶)