Redis 常被用作缓存服务器,它还可以用来实现消息队列,这里介绍 SpringBoot+Redis实现简单的发布/订阅
Redis发布订阅(Pub/Sub)是Redis提供的一种消息传递机制,它使用“发布者-订阅者”(publisher-subscriber)模式来处理消息传递。在这种模式下,发布者将消息发布到一组订阅者中,而无需关心谁是订阅者,也不需要知道订阅者是否收到了消息。
朋友们好啊,我是码农小胖哥。 今天有个同学问我在吗,我说什么事? 给我发个截图,我一看!噢,原来是帮忙搞个定时任务,还是动态的。 他说了两种选择,一种是用DelayQueue,一种是用消息队列。 他说,胖哥你能不能教我点招式混元功法,帮我完成这个需求。 我说可以! 我说你这两种都不好用,他不服气。 我说那你写个DelayQueue来看看,他写不出来。 他说你这估计也不会,我说我确实不会。 这是 JUC,传统底层开发是要讲基础的,必须融会贯通,我只会调包。 这种定时任务我用 Redis 更简单些。 他让我写个
这个时候你可以搞个api测试下,设置过期事件为30秒,看下当key过期时,是否会正常被监听到。
至于乱码,很简单,RedisTemplate字符编码与序列化的时候有问题,自己重新弄一个RedisConfig并追加本文的内容即可RedisConfig的Bean即可!!!
我们以订单功能为例说明下:生成订单后一段时间不支付订单会自动关闭。最简单的想法是设置定时任务轮询,但是每个订单的创建时间不一样,定时任务的规则无法设定,如果将定时任务执行的间隔设置的过短,太影响效率。还有一种想法,在用户进入订单界面的时候,判断时间执行相关操作。方式可能有很多,在这里介绍一种监听 Redis 键值对过期时间来实现订单自动关闭。整理了一份Java面试宝典完整版PDF
发布消息 stringRedisTemplate.convertAndSend("myMsgChannel", "Any Message"); 订阅消息 // 创建消息监听器容器 @Bean public RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory) { RedisMessageListenerContainer listenerContainer = new RedisMessag
发现应用的CPU利用率持续大于90%,且存在CPU热点。 查看监控,发现“线程创建销毁”指标不正常:
注意:发布返回的是订阅者数量,发布的消息不会持久化,没有订阅者时候,发布消息会丢失,当在发布消息之后对channel进行订阅不会收到之前发布的消息。
之前的写法 每个频道都要写个@bean 重复代码太多 import cn.tim.util.Constants; import com.alibaba.druid.filter.config.ConfigTools; import lombok.extern.slf4j.Slf4j; import org.redisson.Redisson; import org.redisson.api.RedissonClient; import org.redisson.config.ClusterServersC
今天写拼团功能,如果24小时后还没有人满,则此次拼团就失败了,那么这里我用redis过期监听来实现,键过期去处理订单状态等业务
生成订单后一段时间不支付订单会自动关闭。最简单的想法是设置定时任务轮询,但是每个订单的创建时间不一样,定时任务的规则无法设定,如果将定时任务执行的间隔设置的过短,太影响效率。
pom.xml 引入redis依赖 application.properties略
业务系统经常需要用到MQ消息队列,但是又不希望引入一个完整的中间件,比如RocketMQ,RabbitMQ,因为会增加接入成本和运维成本。所以当业务量不是很大,且一致性要求不是很强的场景下,可以选择Redis,使用其pub/sub机制作为消息队列的实现 添加依赖 ---- <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-
我们以订单功能为例说明下:生成订单后一段时间不支付订单会自动关闭。最简单的想法是设置定时任务轮询,但是每个订单的创建时间不一样,定时任务的规则无法设定,如果将定时任务执行的间隔设置的过短,太影响效率。还有一种想法,在用户进入订单界面的时候,判断时间执行相关操作。方式可能有很多,在这里介绍一种监听 Redis 键值对过期时间来实现订单自动关闭。 实现思路
我们都知道redis 也有发布订阅模式, 但是使用的比较少。 并且redis的发布订阅不会持久化落入磁盘。总的来说就是不可靠。
自从JDK1.5之后,提供了ScheduledExecutorService代替TimerTask来执行定时任务,提供了不错的可靠性。
上一篇文章《浅析Spring中的事件驱动机制》简单介绍了Spring对事件的支持。Event的整个生命周期,从publisher发出,经过applicationContext容器通知到EventListener,都是发生在单个Spring容器中,而在分布式场景下,有些时候一个事件的产生,可能需要被多个实例响应,本文主要介绍分布式场景下的事件驱动机制,由于使用了Redis,ActiveMQ,也可以换一个名词来理解:分布式下的发布订阅模式。 JMS 在日常项目开发中,我们或多或少的发现一些包一些类位于java
1. 一个交易系统里面有一个价格提醒的功能,用户可以设置一组价格并设置一个周期,后台需要在交易的时间内进行价格扫描一旦触发用户设置的价格的周期就需要下发消息提醒给用户,提醒用户交易做单;
redis是一款高性能key-value存储系统,不仅能做缓存,还能用于消息队列 这里利用Spring Data Redis 来实现消息的发布订阅机制 Demo地址:GitHub - jujunchen/redis-queue-demo: redis 实现的消息 发布/订阅机制 一共3个应用,1个发布者应用,2个订阅者应用 📷 发布者应用 📷 RedisConfig redis序列化配置 Person 示例传输的POJO对象 Publisher 发布服务 @Component public cla
来源:antoniopeng.com/Redis 业务场景 实现思路 开启 Redis key 过期提醒 引入依赖 相关配置 ---- 业务场景 我们以订单功能为例说明下: 生成订单后一段时间不支付订单会自动关闭。最简单的想法是设置定时任务轮询,但是每个订单的创建时间不一样,定时任务的规则无法设定,如果将定时任务执行的间隔设置的过短,太影响效率。 还有一种想法,在用户进入订单界面的时候,判断时间执行相关操作。方式可能有很多,在这里介绍一种监听 Redis 键值对过期时间来实现订单自动关闭。 实现思路 在生成
Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。
Redis自身提供了发布/订阅(publish/subscribe)模式。实现方式大致流程如下图:
首先是配置类 分为Redis配置类和Jackson配置类,主要是用于收发消息时序列化 Jackson的 package com.ruben.config; import java.text.SimpleDateFormat; import java.time.LocalDate; import java.time.LocalDateTime; import java.time.format.DateTimeFormatter; import org.springframework.context.ann
单点定时任务 JDK原生 自从JDK1.5之后,提供了ScheduledExecutorService代替TimerTask来执行定时任务,提供了不错的可靠性。 public class SomeScheduledExecutorService { public static void main(String[] args) { // 创建任务队列,共 10 个线程 ScheduledExecutorService scheduledExecutorService =
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
所有的订阅消息,都需要在这里进行注册绑定,new PatternTopic(“user”),表示发布的主题信息
消息队列一般都会想到kafka,rabbitmq,Rockermq, 其实,给你印像做缓存的Redis也是能做消息队列.
想必大家对SpringBoot可能已经很熟悉了,包括集成Redis这种常用的技术,之前一直用一贯的写法去集成Redis,写配置类没发现过任何问题,但是上周在给Redis配置类加了一个Bean之后就出现了很难发现的问题。
注:Redis版本是4.0;Spring版本4.3.11;Redis client版本2.9.0。
如下如所示, 定义了2个Linstener, 模拟2个应用监听同一个通道. 根据发送和接收的数据类型我们可以选择合适的数据序列化和反序列化方式, 默认序列化方式为RedisSerializer.java(). 对于普通的Bean来说使用json()和java()的序列方式都可以.不同点在于:
在电商和其他涉及到在线支付的应用中,通常需要实现一个功能:如果用户在生成订单后的一定时间内未完成支付,系统将自动取消该订单。本文将详细介绍基于Spring Boot框架实现订单30分钟内未支付自动取消的几种方案,并提供实例代码。
普通redis订阅,是以用container做容器,配置类配置文件方式直接在spring init的时候进行加载,不能进行动态添加。在程序运行时修改不起作用。
Receiver这是一个定义了一个接收消息的方法的类。当你把这个类作为一个消息监听器来注册后,你可以自定义消息接收的方法名。本例中采用“receiveMessage”作为接收消息的方法。
发布订阅模式(Publish-Subscribe Pattern)是一种消息传递模式,其基本原理是消息的发送者(发布者)不会直接发送消息给特定的接收者(订阅者),而是将消息分成不同的类别(频道),然后将消息发送给订阅了这些类别的所有接收者。发布订阅模式在分布式系统中广泛应用,例如实时消息推送、日志收集等。
Redis是一种高性能的内存数据存储系统,它支持多种数据结构和灵活的操作。除了提供常规的键值存储功能外,Redis还支持订阅/发布、事务、Lua脚本等高级功能,其中回调函数是Redis的一个重要特性之一。
说明:关于使用rabbitmq实现订单超时的部分说明有错误,首先mq是可以实现自定义超时时间的,我们可以在创建队列queue.ordercreate时不设置它的x-message-ttl参数,转而在代码里设置消息过期时间。
1,application.properties配置redis以及连接池 #redis spring.redis.host=localhost spring.redis.port=6379 #spring.redis.password= spring.redis.database=1 spring.redis.pool.max-active=8 spring.redis.pool.max-wait=-1 spring.redis.pool.max-idle=500 spring.redis.pool.min
上篇我写了一个通用的消息队列(redis,kafka,rabbitmq)--生产者篇,这次写一个消费者篇. 1.消费者的通用调用类:
前情提要 上一篇文章,我们为了解决实际场景中遇到的问题,使得其更像一个安全高效的邮件服务平台,我们引入了LinkedBlockingQueue队列对邮件发送进行流量削锋、间隔发送以及重复内容检测。 当然,文章末尾也就此方案提出了几点疑问,就比如邮件服务挂了,队列还没消费完怎么办? 怎么办?怎么办?还能怎么办,等着被老板扣工资吧!!! 有没有一种想屎的感觉的? 解决方案 由于LinkedBlockingQueue是进程内的队列,如果容器无情的挂掉以后,随之队列中的内容也便荡然无存。 其实你也可以不用去
上一篇文章,我们为了解决实际场景中遇到的问题,使得其更像一个安全高效的邮件服务平台,我们引入了LinkedBlockingQueue队列对邮件发送进行流量削锋、间隔发送以及重复内容检测。
这节讲的是用Redis来实现消息的发布和订阅,这里会使用Spring Data Redis来完成。
Pub/Sub(发布/订阅)是一种消息传递模式,它允许一个或多个订阅者监听一个特定的主题(频道),当有新的消息发布到该主题时,所有订阅者都会收到通知。
最近购物的时候遇到一个很奇妙的情况,我发现我只在天猫登录了,之后去淘宝买东西的时候,完全不虚要登录,这是为什么?
在电商、支付等领域,往往会有这样的场景,用户下单后放弃支付了,那这笔订单会在指定的时间段后进行关闭操作,细心的你一定发现了像某宝、某东都有这样的逻辑,而且时间很准确,误差在1s内;那他们是怎么实现的呢?
其实光从代码层面上讲,其实没有什么变化,主要是变化是关于Redis的配置需要更改为集群配置而已,之前接触过redis的话,那么就只需要看一下redis集群配置文件即可了。
业务中有类似等待一定时间之后执行某种行为的需求 , 比如 30 分钟之后关闭订单 . 网上有很多使用 Redis 过期监听的 Demo , 但是其实这是个大坑 , 因为 Redis 不能确保 key 在指定时间被删除 , 也就造成了通知的延期 . 不多说 , 跑个测试
领取专属 10元无门槛券
手把手带您无忧上云