3.2.rabbitMq消费者的消费方式(gold_axe)

性能和可靠性的权衡

3种消费方式:
事务 , 拉取 , Qos

• 消费者一般使用推送, 不用拉取(太慢了)
• 批量机制可以极大提升性能
• 事务 机制一般会被遗弃
• 单队列 一般用于顺序消息，但是也丧失了高性能

拉取

就是轮询, 很慢,一般不拉取 用推送

和推送一样, 可以选手动和自动确认:

手动确认

上图中把自动确认传的false

有个ack的机制,如果设置的手动确认又没有发ack, 下次还能get到这条
如果ack了 消息就会从队列删除

自动确认

正常还是推送, 以下的消费方法都是推送的 :

批量确认

极大提升性能

自定义Consumer,里面有批量确认

使用自定义Consumer

Qos预拉取+批量quere

在确认消息被接收之前，消费者可以预先要求接收一定数量的消息，在处理完一定数量的消息后，批量进行确认。

这种机制一方面可以实现限速（将消息暂存到 RabbitMQ 内存中）的作用，一方面可以保证消息确认质量（比如确认了但是处理有异常的情况）。

如果消费者应用程序在确认消息之前崩溃，则所有未确认的消息将被重新发送给其他消费者。所以这里存在着一定程度上的可靠性风险。

注意：消费确认模式必须是非自动 ACK 机制（这个是使用 baseQos 的前提条件

使用就是比 批量 加一句
channel.basicQos(150,true);

第二个入参global：true\false 是否将上面设置应用于 channel，简单点说，就是上面限制是 channel 级别的还是 consumer 级别。

一行开启Qos预拉取

生产者这样生产

确实有批量确认的效果