Springboot与RabbitMQ消息超时时间、队列消息超时时间

一 TTL(过期时间)

TTL是 Time-To-Live 的缩写,RabbitMQ可以对消息和队列设置TTL(过期时间)。
RabbitMQ针对队列中的消息过期时间(Time To Live, TTL)有两种方法可以设置。
第一种方法是通过队列属性设置,队列中所有消息都有相同的过期时间。
第二种方法是对消息进行单独设置,每条消息TTL可以不同。如果上述两种方法同时使用,则消息的过期时间以两者之间TTL较小的那个数值为准。消息在队列的生存时间一旦超过设置的TTL值,就成为dead message,消费者将无法再收到该消息。

二 单条消息设置TTL(超时时间)

针对单条消息设置TTL的方法是MessagePostProcessor对象里setExpiration(过期时间)

  1. 当队列消息的TTL 和消息TTL都被设置,时间短的TTL设置生效。
  2. 为消息设置TTL有一个问题:RabbitMQ只对处于队头的消息判断是否过期(即不会扫描队列),所以,很可能队列中已存在死消息,但是队列并不知情。这会影响队列统计数据的正确性,妨碍队列及时释放资源。
rabbitTemplate.convertAndSend("timeOut.exchange.test","key.time.out",messageProperties,
   // 设置消息过期时间: 单位:毫秒
       message1 -> {
       message1.getMessageProperties().setExpiration("10000");// 过期时间
       message1.getMessageProperties().setDeliveryMode(MessageDeliveryMode.fromInt(2)); // 持久化
   // 返回消息对象
       return message1;
       },correlationData);

对消息设置过期时间

// 为消息设置过期时间
message1.getMessageProperties().setExpiration("10000");// 过期时间

每条消息的过期时间不同,如果要删除所有过期消息,势必要扫描整个队列,所以不如等到此消息即将被消费时再判定是否过期,如果过期,再进行删除。

三 队列设置TTL(超时时间)

通过队列属性设置消息TTL,在声明队列方法中加入x-message-ttl参数实现的,这个参数的单位是毫秒。

  • 过期时间单位也是毫秒,但是与消息TTL不同在于 队列TTL值必须大于零
/* 设置队列过期时间*/
@Bean
public Exchange queueTimeOutExchange(){
    return new DirectExchange("queueTimeOut.exchange.test",true,false);
}

// 声明过期的队列并定义队列名称
@Bean
public Queue queueTimeOutQueue(){
    // 消息过期 特殊的args
    Map<String,Object> args  = new HashMap<>(16);
    // 存活时间最大为 20 秒
    args.put("x-message-ttl",20000);
      // 设置队列可以存储的最大消息数量
    args.put("x-max-length", 10);
    return new Queue("queueTimeOut.queue.test"
            ,true,false,false,args);
}

@Bean
public Binding queueTimeOutBinding(){
    return new Binding("queueTimeOut.queue.test",
            Binding.DestinationType.QUEUE,
            "queueTimeOut.exchange.test",
            "key.queuetime.out",null);
}

对队列设置过期时间

@Bean
public Queue queueTimeOutQueue(){
    // 消息过期 特殊的args
    Map<String,Object> args  = new HashMap<>(16);
    // 存活时间最大为 20 秒
    args.put("x-message-ttl",20000);
      // 设置队列可以存储的最大消息数量
    args.put("x-max-length", 10);
    return new Queue("queueTimeOut.queue.test"
            ,true,false,false,args);
}

一旦消息过期,就会从队列中抹去。因为队列中已过期的消息肯定在队列头部,RabbitMQ只要定期从队头开始扫描是否有过期消息即可。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
Hyperf v2.1.4更新日志修复 #3165 修复方法 HyperfDatabaseSchemaMySqlBuilder::getColumnListing 在 MySQL 8.0 版本中无法正常使用的问题。 #3174 修复 hyperf/database 组件中 where 语句因为不严谨的代码编写,导致被绑定参数会被恶意替换的问题。 #3179 修复 json-rpc 客户端因对端服务重启,导致接收数据一直异常的问题。 #3189 修复 kafka 在集群模式下无法正常使用的问题。 #3191 修复 json-rpc 客户端因对端服务重启,导致连接池中的连接全部失效,新的请求进来时,首次使用皆会报错的问题。 新增 #3170 为 hyperf/watcher 组件新增了更加友好的驱动器 FindNewerDriver,支持 Mac Linux 和 Docker。 #3195 为 JsonRpcPoolTransporter 新增了重试机制, 当连接、发包、收包失败时,默认重试 2 次,收包超时不进行重试。 优化 #3169 优化了 ErrorExceptionHandler 中与 set_error_handler 相关的入参代码, 解决静态检测因入参不匹配导致报错的问题。 #3191 优化了 hyperf/json-rpc 组件, 当连接中断后,会先尝试重连。 变更 #3174 严格检查 hyperf/database 组件中 where 语句绑定参数。 新组件孵化 DAG 轻量级有向无环图任务编排库。 RPN 逆波兰表示法。Hyperf简介Hyperf 是基于 Swoole 4.4+ 实现的高性能、高灵活性的 PHP 协程框架,内置协程服务器及大量常用的组件,性能较传统基于 PHP-FPM 的框架有质的提升,提供超高性能的同时,也保持着极其灵活的可扩展性,标准组件均基于 PSR 标准 实现,基于强大的依赖注入设计,保证了绝大部分组件或类都是 可替换 与 可复用 的。框架组件库除了常见的协程版的 MySQL 客户端、Redis 客户端,还为您准备了协程版的 Eloquent ORM、WebSocket 服务端及客户端、JSON RPC 服务端及客户端、GRPC 服务端及客户端、OpenTracing(Zipkin, Jaeger) 客户端、Guzzle HTTP 客户端、Elasticsearch 客户端、Consul 客户端、ETCD 客户端、AMQP 组件、Nats 组件、Apollo、ETCD、Zookeeper 和阿里云 ACM 的配置中心、基于令牌桶算法的限流器、通用连接池、熔断器、Swagger 文档生成、Swoole Tracker、Blade、Smarty、Twig、Plates 和 ThinkTemplate 视图引擎、Snowflake 全局ID生成器、Prometheus 监控 等组件,省去了自己实现对应协程版本的麻烦。Hyperf 还提供了 基于 PSR-11 的依赖注入容器、注解、AOP 面向切面编程、基于 PSR-15 的中间件、自定义进程、基于 PSR-14 的事件管理器、Redis/RabbitMQ 消息队列、自动模型缓存、基于 PSR-16 的缓存、Crontab 秒级定时任务、Session、i18n 国际化、Validation 表单验证 等非常便捷的功能,满足丰富的技术场景和业务场景,开箱即用。Hyperf 功能特点框架初衷 尽管现在基于 PHP 语言开发的框架处于一个百花争鸣的时代,但仍旧未能看到一个优雅的设计与超高性能的共存的完美框架,亦没有看到一个真正为 PHP 微服务铺路的框架,此为 Hyperf 及其团队成员的初衷,我们将持续投入并为此付出努力,也欢迎你加入我们参与开源建设。设计理念 Hyperspeed + Flexibility = Hyperf,从名字上我们就将 超高速 和 灵活性 作为 Hyperf 的基因。对于超高速,我们基于 Swoole 协程并在框架设计上进行大量的优化以确保超高性能的输出。 对于灵活性,我们基于 Hyperf 强大的依赖注入组件,组件均基于 PSR 标准 的契约和由 Hyperf 定义的契约实现,达到框架内的绝大部分的组件或类都是可替换的。 基于以上的特点,Hyperf 将存在丰富的可能性,如实现 单体 Web 服务,API 服务,网关服务,分布式中间件,微服务架构,游戏服务器,物联网(IOT)等。文档齐全 我们投入了大量的时间用于文档的建设以提供高质量的文档体验,以解决各种因为文档缺失所带来的问题,文档上也提供了大量的示例,对新手同样友好。 Hyperf 官方开发文档生产可用 我们为组
202x java商城秒杀系统的设计与实战视频教程(springboot版) 演讲人 202x-11-11 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第1页。 01. 第1章课程整体介绍 02. 03. 目录 第2章微服务项目的搭建 第3章秒杀 务代码实战 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第2页。 01 第1章课程整体介绍 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第3页。 第1章课程整体介绍 1-1课程整体介绍课程整体介绍 1-2核心技术列表核心技术列表 1-3课程要求与收益课程要求与收益 1-4系统的整体演示系统的整体演示 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第4页。 02 第2章微服务项目的搭建 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第5页。 2-1springboot搭建多模块项目一springboot搭建多模块项目一 2-2springboot搭建多模块项目二springboot搭建多模块项目二 2-3体验mvc的开发流程体验mvc的开发流程 2-4秒杀系统整体业务流程介绍秒杀系统整体业务流程介绍 2-5数据库设计与mybatis逆向工程数据库设计与mybatis逆向工程 2-2SpringBoot搭建多模块项目二SpringBoot搭建多模块项目二 2-3体验MVC的开发流程体验MVC的开发流程 2-4秒杀系统整体业务流程介绍秒杀系统整体业务流程介绍 2-5数据库设计与Mybatis逆向工程数据库设计与Mybatis逆向工程 第2章微服务项目的搭建 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第6页。 03 第3章秒杀业务代码实战 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第7页。 第3章秒杀业务代码实战 3-1商品列表展示一商品列表展示一 3-2商品列表展示二商品列表展示二 3-3商品详情展示商品详情展示 3-4商品秒杀实战商品秒杀实战 3-5订单编号的生成方式订单编号的生成方式 3-6整合前端实现完整的秒杀逻辑整合前端实现完整的秒杀逻辑 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第8页。 3-7整合rabbitmq实现消息异步发送整合rabbitmq实现消息异步发送 3-8邮件服务发送通知信息实战邮件服务发送通知信息实战 3-9整体再次回顾秒杀的全过程整体再次回顾秒杀的全过程 3-10死信队列失效超时未支付的订单一死信队列失效超时未支付的订单一 3-11死信队列失效超时未支付的订单二死信队列失效超时未支付的订单二 3-8邮件服务发送通知信息实战邮件服务发送通知信息实战 3-9整体再次回顾秒杀的全过程整体再次回顾秒杀的全过程 3-10死信队列失效超时未支付的订单一死信队列失效超时未支付的订单一 3-11死信队列失效超时未支付的订单二死信队列失效超时未支付的订单二 第3章秒杀业务代码实战 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第9页。 感谢聆听 Java商城秒杀系统的设计与实战视频教程(SpringBoot版)课件PPT模板全文共10页,当前为第10页。 2 6 8 10
上传项目不支持Firefox,提示代码附件太大(1.4M),我写了30多分钟的描述全没了,太坑爹了。 10分有点贵,绝对原创,共2个代码文件300多行,下载请谨慎。你下载了,若绝对不爽在评论中说出来,不要让其他同学上当,如果觉得还可以也请留言。 代码采用多工作者多线程执行任务。通过暴露的方法往工作者传递消息,然后采用事件回调返回处理结果,实现的事件有OnThreadComplete,OnAddedTask,OnStart,OnSuccess,OnFailure,OnTimeout。 事件回调支持同步或异步,每工作者可以指定执行超时时间,避免线程阻塞死掉。队列采用线程安全的BlockingCollection,每组工作者用一个队列。委托采用Func来定义的,没有采用传统且不太好理解的Delegate。这让代码减少很多,也更容易理解。多线程应该采用消息中心来交换数据,这样就规避了线程同步交互,等待,阻塞等等,全部是异步调用,全部是接收消息工作,然后产生消息,线程间没有耦合,消息中心有很多成熟的方案如RabbitMQ, Redis(里面有简单的消息交换),微软有消息云服务等。如果应用不复杂,可以采用DB做个简单的消息中心,建议采用HTTP接口来获取与写入消息,方便将来升级重构消息中心。 开发环境VS2012,Framework4.0,代码注释量很大,如果你高兴这代码你可以随意蹂躏,如果你有建设性意见请告诉我。 下面是部分测试代码: //发送消息方法容器 var msgContainer = new Hashtable(); //创建并启动工作者 foreach (var key in workers.Keys) { //创建工作者 //启动5个线程,异步事件回调,方法执行20秒超时,程序跑起来有100个线程,由于引入超时控制,实际线程将达100+50 //下面的20个工作组,有5个是超时的,主要测试OnTimeout事件,你可以设置seleep的时间来控制 //我把sleep的时间设置的有点长,方便你测试 //测试的时候你会看见有异常,那是应为Timeout我采用的是Thread.Abort方法,这样才出发了ontimeout事件 var worker = new Sehui.Worker(5, key.ToString(), (Func)workers[key], false, new TimeSpan(0, 0, 20)); worker.OnStart += worker_OnEvent; worker.OnSuccess += worker_OnEvent; worker.OnFailure += worker_OnEvent; worker.OnTimeout += worker_OnEvent; //启动工作者 worker.Start(); //将增加消息方法放到Hashtable中 //这里我是偷懒,下面可以用循环的方式往线程中add message msgContainer.Add(key.ToString(), new Func(worker.AddTask)); } //向20个工作者发送消息,每个工作者发送20条消息 for (var i = 0; i < 20; i++) { for (var k = 0; k < 20; k++) { ((Func)msgContainer["SyncDb" + k])("[Work " + k + "] Message " + i); Console.WriteLine("send msg to worker{0},msgid:{1}", k, i); } }

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

讓丄帝愛伱

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值