【黑马程序员RabbitMQ全套教程,rabbitmq消息中间件到实战】
【回顾一下 我们之前谈到 的MQ 的作用 → 削峰填谷】

这样一个 A系统 ,原本它每秒 最大只能处理 1000 请求,
这个时候,由于某些原因,当 用户请求 量 瞬间增多, 它就承载不了 了
比如“秒杀 ” 活动 啥的,

现在 每秒来了 5000 个请求,如果全部直接 打到 A 系统上,那么它肯定就会 崩溃 或者说直接宕机,从而 就会影响 整个业务 的正常运转。

解决方案就是 利用 MQ 加一层,A 系统每秒从 MQ 中 拉自己能够承受的请求 数量 进行处理。这样 就能保证 A 系统的稳定性。
每秒拉 1000个,换句话说,就是 做一个 “限流” 的处理。
而且 这对 系统维护升级 也非常有帮助
【修改消费端】
直接来一个 新的监听类 QosListener
package com.dingjiaxiong.listener;import com.rabbitmq.client.Channel;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.listener.api.ChannelAwareMessageListener;
import org.springframework.stereotype.Component;/*** ClassName: QosListener* date: 2022/11/16 21:16** @author DingJiaxiong*//*** Consumer 限流机制* 1. 确保ack 机制为手动确认。* 2. listener-container配置属性 prefetch【这个的具体数值 就是能够拉取的消息最大数目】* 比如prefetch = 1 → 表示 消费端每次从 MQ 拉取一条消息进行消费,直到手动 确认消费完毕后,才会继续拉取下一条消息*/
@Component
public class QosListener implements ChannelAwareMessageListener {@Overridepublic void onMessage(Message message, Channel channel) throws Exception {// 1. 获取消息System.out.println(new String(message.getBody()));// 2. 处理业务逻辑// 3. 签收channel.basicAck(message.getMessageProperties().getDeliveryTag(),true);}
}
spring 核心配置文件修改
OK,直接启动消费端

它会一直等待
OK,发送10条消息
@Test
public void testSend() {for (int i = 0; i < 10; i++) {// 发送消息rabbitTemplate.convertAndSend("test_exchange_confirm", "confirm", "message confirm...");}}
为了效果更明显,先把消费端 的ack 注掉

现在 预期结果就是消费端只会拉取一条消息,剩余9 条会留在 队列里,
试试

OK,可以看到发送端 已经完成了 10 条消息的 发送,看看 消费端 的日志

没毛病,只拿到 了 一条消息
查看管控台

没毛病
直接停掉消费端

那条没被 确认 的消息就退回去了
现在 来个操作, 把拉取限制 注掉

OK, 再次运行消费端

可以看到 10 条消息全被 拉过来了

而且全部是 未被 签收的状态,没问题,现在还原

一次消费一条消息

且进行一个签收 的操作
再次运行消费端

OK, 现在就是 真的被消费掉了 ,查看管控台

嗯,10 条都被消费了 【如果加上一个 睡眠,效果 会更明显】
【这就是 消费端 限流的配置】
上一篇:JWT渗透与攻防(二)
下一篇:字符串函数