性能和可靠性的权衡
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预拉取
生产者这样生产
确实有批量确认的效果
