开始

image.png
消费端能力不足，处理不过来很多的并发的消息的问题。

image.png

image.png

image.png

Qos的前提是不使用自动确认机制
image.png

image.png

image.png

实战

在order服务里面。
image.png

一次性发送50条给商家服务。
image.png

我们在商家端模拟消息可能会处理的比较慢
商家端确认之前，休眠3秒
image.png

启动服务测试。

image.png
在没有采用Qos之前。会把50条消息一股脑的推送给消费端。
image.png
我们消费端所有的消息都处在Unacked的状态。
image.png
如果多启动一个消费端来同时处理消息的话，当前已经有50条推送给了消费者1了。这样是没有改善的。
因为50条消息已经推送给了消费者1.全都堆在他的内存里。启动一个新的消费端和它一样 抢消息也抢不到。
因为这里没有ready的只能等第一个消费者把这50条消息都处理完. 所以这就是为什么不用Qos限流的缺点.
不用Qos的缺点不是说他会把线程挤爆.它的线程不一定会挤爆.但是你的消息全都堆积在了老的消费者上.
image.png

加上消费端限流

image.png
设置为同时有2条消息可以在处理中
image.png

重启应用测试.
image.png
消息只有2条一直是unacked的状态。 只有2条消息是Unacked的状态，剩下的消息是Ready的状态。ready的状态的消息，可以多开消费端来处理这些数据。抢ready的数据。临时的横向扩展可以更好的处理。这就是Qos的优点。
image.png

结束