前言篇: 为了节约成本,决定通过自研来改造rocketmq,添加任意时间延迟的延时队列,开源版本的rocketmq只有支持18个等级的延迟时间, 其实对于大部分的功能是够用了的,但是以前的项目,全部都是使用了阿里云的rocketmq,原因是不同的供应商的订单的延时时间是不同的 (部分供应商的订单未支付30分钟取消,有些1个半小时取消,各种时间都有), 所以使用了大量的延时队列,但是开源版本不支持任意时间延时(希望官方支持这个功能) 为了实现这个功能,网上查询了不少资料,查询到不少相关的文章,主要

背景 在业务发展过程中,会出现一些需要延时处理的场景,比如: a.订单下单之后超过30分钟用户未支付,需要取消订单 b.订单一些评论,如果48h用户未对商家评论,系统会自动产生一条默认评论 c.点我达订单下单后,超过一定时间订单未派出,需要超时取消订单等... 处理这类需求,比较直接简单的方式就是定时任务轮训扫表.这种处理方式在数据量不大的场景下是完全没问题,但是当数据量大的时候高频的轮训数据库就会比较的耗资源,导致数据库的慢查或者查询超时.所以在处理这类需求时候,采用了延时队列来完成. 几种延

背景 在业务发展过程中,会出现一些需要延时处理的场景,比如: a.订单下单之后超过30分钟用户未支付,需要取消订单b.订单一些评论,如果48h用户未对商家评论,系统会自动产生一条默认评论c.点我达订单下单后,超过一定时间订单未派出,需要超时取消订单等... 处理这类需求,比较直接简单的方式就是定时任务轮训扫表.这种处理方式在数据量不大的场景下是完全没问题,但是当数据量大的时候高频的轮训数据库就会比较的耗资源,导致数据库的慢查或者查询超时.所以在处理这类需求时候,采用了延时队列来完成. 几种延时队

前言 传统处理超时订单 采取定时任务轮训数据库订单,并且批量处理.其弊端也是显而易见的:对服务器.数据库性会有很大的要求,并且当处理大量订单起来会很力不从心,而且实时性也不是特别好 当然传统的手法还可以再优化一下,即存入订单的时候就算出订单的过期时间插入数据库,设置定时任务查询数据库的时候就只需要查询过期了的订单,然后再做其他的业务操作 jdk延迟队列 DelayQueue 采取jdk自带的延迟队列能很好的优化传统的处理方案,但是该方案的弊.端也是非常致命的,所有的消息数据都是存于内存之中,一旦

小结: 1. https://mp.weixin.qq.com/s/v6NM3UgX-qTI7yO1QPCJrw 滴滴出行基于RocketMQ构建企业级消息队列服务的实践 原创: 江海挺 阿里巴巴中间件 2018-11-01  

导读 目前很多互联网公司的系统都在朝着微服务化.分布式化系统的方向在演进,这带来了很多好处,也带来了一些棘手的问题,其中最棘手的莫过于数据一致性问题了.早期我们的软件功能都在一个进程中,数据的一致性可以通过数据库本地事务来加以控制.而在分布式架构下,原本比较完整的本地功能可能被拆分成了多个独立的服务进程.与之前相比,同样一笔业务订单此时可能会经历很多服务模块的处理,调用链路会变得很长,例如某电商平台,一笔购物订单可能会经过:商品中心.订单.支付.物流等多个服务的调用,而这可能还只是比较粗粒度的划

目录 一.业务场景 二.Redis延时队列 一.业务场景 所谓延时队列就是延时的消息队列,下面说一下一些业务场景比较好理解 1.1 实践场景 订单支付失败,每隔一段时间提醒用户 用户并发量的情况,可以延时2分钟给用户发短信 ... 1.2 实现方式 这些情况都可以使用延时队列来做,实现延时队列比较场景的有使用消息队列MQ来实现,比如RocketMQ等等,也可以使用Redis来实现,本博客主要介绍一下Redis实现延时队列 二.Redis延时队列 2.1 Redis列表实现 Redis实现延时队列

应用场景 1)7天自动收货 a.用户支付完成以后,把订单ID插入到内存的一个DelayQueue中,同时插入到Redis中. b.7天之内,用户点击了确认收货,则从DelayQueue中删除,从Redis中删除. c.超过7天,DelayQueue中的订单ID出队,查询数据库,改状态为自动收货,删除redis. d.如果7天之内,web服务器重启过,则web服务器启动以后,从redis中读取待收货的订单,插入到DelayQueue. 2)30分钟未付款自动取消订单 一.写一个JedisUtil,

本文整理自李样兵在北京站 RocketMQ meetup分享美菜网使用 RocketMQ 过程中的一些心得和经验,偏重于实践. 嘉宾李样兵,现就职于美菜网基础服务平台组,负责 MQ ,配置中心和任务调度等基础组件开发工作. 今天主要从三个方面进行分享: 美菜网消息队列的历史 基于 RocketMQ 我们做了那些事情 同城双活的选型和思考 美菜网消息队列的历史 美菜网历史上是多套 MQ 并存,Kafka 用于大数据团队:NSQ 和 RocketMQ 用于线上业务. 多套集群存在的问题:1.维护和资

最近项目里需要在延时队列,但是开源版本rocketmq不支持任意时间延时,造成有些任务无法执行 参考了网上的不少文章,但是都么有实现,所以再开源的基础上改造了个支持任意时间延时的队列. 源码地址: https://gitee.com/venus-suite/rocketmq-with-delivery-time 概念介绍 开源版本中,只有RocketMQ支持延迟消息,且只支持18个特定级别的延迟付费版本中,阿里云和腾讯云上的MQ产品都支持精度为秒级别的延迟消息 定时消息:Producer将消息发

这是Live555源码阅读的第一部分,包括了时间类,延时队列类,处理程序描述类,哈希表类这四个大类. 本文由乌合之众 lym瞎编,欢迎转载 www.cnblogs.com/oloroso/ 本文由乌合之众 lym瞎编,欢迎转载 my.oschina.net/oloroso DelayQueue 延时队列类 这个类的设计不是很复杂,但是要清楚的知道其设计的思路.先给个图 10_DelayQueue.png 这个链表的设计和前面不一样.其内部只有一个EventTime fLastSyncTime最后

这是Live555源码阅读的第一部分,包括了时间类,延时队列类,处理程序描述类,哈希表类这四个大类. 本文由乌合之众 lym瞎编,欢迎转载 http://www.cnblogs.com/oloroso/ DelayQueueEntry 延时队列节点类 entry的意思如下 entry n.进入,入场; 入口处,门口; 登记,记录; 参加比赛的人; 为什么说是节点类呢?这个通过阅读代码就可以知道了. DelayQueueEntry类含有四个数据成员,其中fNext和fPrev说明了其是一个链表的节

这是Live555源码阅读的第一部分,包括了时间类,延时队列类,处理程序描述类,哈希表类这四个大类. 本文由乌合之众 lym瞎编,欢迎转载 http://www.cnblogs.com/oloroso/ 延时队列相关类 延时队列相关类一共有两个,DelayQueue(延时队列)和DelayQueueEntry(延时队列节点).后面说到任务调度器(TaskScheduler)的时候会使用到. DelayQueue是DelayQueueEntry的派生类,同时也是它的友元类.其定义在live555s

HQueue:基于HBase的消息队列   凌柏   ​1. HQueue简介 HQueue是一淘搜索网页抓取离线系统团队基于HBase开发的一套分布式.持久化消息队列.它利用HTable存储消息数据,借助HBase Coprocessor将原始的KeyValue数据封装成消息数据格式进行存储,并基于HBase Client API封装了HQueue Client API用于消息存取. HQueue可以有效使用在需要存储时间序列数据.作为MapReduce Job和iStream等输入.输出供上

http://www.cnblogs.com/nightwatcher/archive/2011/04/10/2011158.html 最近在看LIVE555的源码,感觉其中的延时队列写的不错,于是就总结一下.    首先描述一下LIVE555中的延时队列的设计理念.首先,如下图,A,B,C分别为时间轴上的三个事件点,而head表示当前时间点. 假如我们要描述一个事件发生的时间,可以有两种方法:一种方法直接描述事件发生的绝对时间:另一种方法则是可以描述和另一事件发生的相对时间.而 LIVE555

一.概述 队列,又称为伫列(queue),是先进先出(FIFO, First-In-First-Out)的线性表.在具体应用中通常用链表或者数组来实现.队列只允许在后端(称为rear)进行插入操作,在前端(称为front)进行删除操作.队列的操作方式和堆栈类似,唯一的区别在于队列只允许新数据在后端进行添加. 在Java中队列又可以分为两个大类,一种是阻塞队列和非阻塞队列. 1.没有实现阻塞接口: 1)实现java.util.Queue的LinkList, 2)实现java.util.Abstra

现实业务中经常遇到需要队列处理的问题. 问题场景: 客户端记录设备运行数据,传输给服务器.在传输中可能存在延迟或中断情况.当中断时,系统传输数据可能因为无法传输或电脑重启,会导致服务器数据记录不连续. 设想的解决方案: 当客户端采集到设备数据后,将数据先插入处理队列.另一个服务程序从队列中取出数据发送到服务器.数据记录与数据上传做到完全独立,并且是异步操作.数据记录在硬盘上,保障了数据的连续性和可靠性.如果一直无法上传到服务器,会导致队列中等待处理的数据积攒过多. 现有解决方案: 使用数据库做队

导读 在之前的文章中我们介绍了如何基于RocketMQ搭建生产级消息集群,以及2PC.3PC和TCC等与分布式事务相关的基本概念(没有读过的读者详见

https://www.cnblogs.com/wt645631686/p/8454021.html 我们平时习惯于使用 Rabbitmq 和 Kafka 作为消息队列中间件,来给应用程序之间增加 异步消息传递功能.这两个中间件都是专业的消息队列中间件,特性之多超出了大多数人的理 解能力. 使用过 Rabbitmq 的同学知道它使用起来有多复杂,发消息之前要创建 Exchange,再创 建 Queue,还要将 Queue 和 Exchange 通过某种规则绑定起来,发消息的时候要指定 routi

Redis实现简单延队列, 利用zset有序的数据结构, score设置为延时的时间戳. 实现思路: 1.使用命令 [zrangebyscore keyName socreMin socreMax] 会返回已score排序由小到大的一个list 2.list非空则使用[zrem keyName value]  删除第一个元素, 删除成功即代表消费成功, 可以解决多线程并发消费的问题. 使用jedis实现代码: package com.nancy.utils; import com.alibaba