做公司网站需要会什么,wordpress修改上传文件大小,百度有哪些app产品,英文字体设计网站前言#xff1a;
学习收获#xff1a;
Redis消息队列#xff1a;
消息队列#xff08;Message Queue#xff09;#xff0c;字面意思就是存放消息的队列。最简单的消息队列包括3个角色#xff1a;
消息队列#xff1a;存储和管理消息#xff0c;也被称为消息代理生…前言
学习收获
Redis消息队列
消息队列Message Queue字面意思就是存放消息的队列。最简单的消息队列包括3个角色
消息队列存储和管理消息也被称为消息代理生产者发送消息到消息队列消费者从消息队列获取消息并处理消息 通过消息队列解除耦合提高工作效率。使秒杀抢单的业务和写入数据库业务分离解除里耦合。提高了并发能力。
消息队列是一个独立与JVM的服务不受JVM的内存影响解决了内存限制问题。并且消息队列不仅仅是做一个数据存储的问题还有一个数据安全的问题存进消息队列的所有消息会做持久化操作并且还会确保每个消息至少执行一次。
Redis通过了三种不同的方式来实现消息队列
list结构基于List结构模拟消息队列PubSub基本的点对点消息模型Stream比较完善的消息队列模型
List模拟消息队列
Redis的list数据结构是一个双向链表很容易模拟出队列效果。队列时入口和出口不在一边因此我们可以利用LPUSH结合RPOP、或者RPUSH结合LPOP来实现。不过要注意的是当队列中没有消息时RPOP或LPOP操作会返回null并不像JVM的阻塞队列那样会阻塞并等待消息。不过可以通过使用BRPOP或者BLPOP来实现阻塞效果。 与阻塞队列相比它是在JVM以外的独立的存储不用依赖内存不用担心存储上限的问题。并且Redis支持数据持久化如果宕机了数据也还存在。
基于List消息队列的优缺点
优点
利用Redis存储不受限于JVM内存上限基于Redis的持久化机制数据安全性有保证可以满足消息有序性
缺点
无法避免消息丢失只支持单消费者无法实现一条消息被很多消费者消费的需求
基于PubSub发布订阅的消息队列
PubSub发布订阅是Redis2.0版本引入的消息传递模型。顾名思义消费者可以订阅一个或多个channel生产者向对于channel发送消息后所有订阅者都能收到相关消息。
SUBSCRIBE channel [channel]订阅一个或多个频道PUBLISH channel msg向一个频道发送消息PSUBSCRIBE pattern [pattern]订阅于pattern格式匹配的所有频道
并且基于PubSub的消息队列天生就是堵塞的。
基于PubSub消息队列的优缺点
优点
采用发布订阅模型支持多生产、多消费
缺点
不支持数据持久化无法避免消息丢失消息堆积有上限超出时数据丢失 List有数据持久化是应为他本来就是做数据存储的只是我们把他当作消息队列来用了。而Redis用来做数据存储的都支持数据持久化。而PubSub他本来就是做消息发送的因此当我们发送一条消息是如果这个频道没有被任务消费者订阅时那么这条消息就可能丢失。
基于Stream的消息队列
Stream是Redis5.0引入的一种新的数据类型可以实现一个功能非常完善的消息队列。他是一种以数据流为核心设计理念的消息中间件它将消息视为连续的数据流进行处理具备高吞吐量、低延迟、持久化存储和实时流处理等特性。
发送消息的命令 读消息的方式之一 在业务开发中我们可以循环的调用XREAD阻塞方式来查询最新消息从而实现持续监听队列的效果伪代码如下 基于Stream类型消息队列的XREAD命令特点
消息可回溯一个消息可以被多个消费者读取可以阻塞读取有消息漏读的风险
上面我们介绍的消费方式都是单消费方式容易发生消息堆积导致消息丢失所以我们需要改用消费者组的模式。
消费者组将多个消费者划分到一个组中监听同一个队列。
消息分流队列中的消息会分流给组内的不同消费者而不是重复消费从而加快消息处理速度消息标示消费者会维护一个标示记录最后一个被处理的消息哪怕消费者宕机重启还会从标示之后读取消息。确保每一个消息都会被消费消息确认消费者获取消息后消息处于pending状态并存入一个pending-list。当处理完成后需要通过XACK来确认消息标记消息为已处理才会从pending-list移除。
这里的消息确认会确保所有消息至少会被消费一次就不会有出现获取到消息但是没有消费的情况。
常见命令
# 创建消费者组
XGROUP CREATE key groupName ID
# 删除指定的消费者组
XGROUP DESTORY key groupName
# 给指定的消费者组添加消费者
XGROUP CREATECONSUMER key groupName consumerName
# 删除消费者组中指定消费者
XGROUP DELCONSUMER key groupName consumerName
# 从消费者组中读取消息
XREADGROUP GROUPstream类型消息队列的XREADGROUP命令特点 消息可回溯 可以多消费者争抢消息加快消费速度 可以阻塞读取 没有消息漏读的风险 有消息确认机制保证消息至少被消费一次
消除了漏读的风险会标记上一次消费 消费到哪里了然后从此处继续消费。
总结 Stream的消息确认仅支持消费者的确认机制不支持生产者的确认机制如果生产者再发消息使消息丢失。
基于Redis的Stream实现异步秒杀下单 1. 创建一个Stream的消息队列名为stream.orders 2. 之前是在java代码中取调用lua脚本仅仅判断有没有资格然后取利用java代码去王阻塞队列里添加。但现在使发消息就是redis的命令直接lua脚本里发送减少了java代码和与redis的交互。 在VoucherOrderServiceImpl中编写Java代码
/*** 抢购秒杀券** param voucherId* return*/TransactionalOverridepublic Result seckillVoucher(Long voucherId) {Long userId ThreadLocalUtls.getUser().getId();long orderId redisIdWorker.nextId(SECKILL_VOUCHER_ORDER);// 1、执行Lua脚本判断用户是否具有秒杀资格Long result null;try {result stringRedisTemplate.execute(SECKILL_SCRIPT,Collections.emptyList(),voucherId.toString(),userId.toString(),String.valueOf(orderId));} catch (Exception e) {log.error(Lua脚本执行失败);throw new RuntimeException(e);}if (result ! null !result.equals(0L)) {// result为1表示库存不足result为2表示用户已下单int r result.intValue();return Result.fail(r 2 ? 不能重复下单 : 库存不足);}// 2、result为0下单成功直接返回ok// 索取锁成功创建代理对象使用代理对象调用第三方事务方法 防止事务失效IVoucherOrderService proxy (IVoucherOrderService) AopContext.currentProxy();this.proxy proxy;return Result.ok();}
————————————————该文章版权属于知识汲取者未经允许请勿转载原文链接https://blog.csdn.net/qq_66345100/article/details/131986713
3.
获取消息队列中的订单信息判断消息获取是否成功如果获取失败说明没有消息继续下一次循环如果获取成功则可以下单ACK确认 qps1000、平均值889、异常率0%、吞吐量474.2可以看到stream实现的消息队列并没有比Java的BlockingQueue实现的消息队列高多少性能但是stream实现的信息队列比BlockingQueue实现的消息队列的可靠性和灵活性要高一大截。
