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

上一节消息重试里面提到了重试的消息可以被延时消费,其实除此之外,用户发送的消息也可以指定延时时间(更准确的说是延时等级),然后在指定延时时间之后投递消息,然后被consumer消费.阿里云的ons还支持定时消息,而且延时消息是直接指定延时时间,其实阿里云的延时消息也是定时消息的另一种表述方式,都是通过设置消息被投递的时间来实现的,但是Apache RocketMQ在版本4.2.0中尚不支持指定时间的延时,只能通过配置延时等级和延时等级对应的时间来实现延时. 一个延时消息被发出到消费成功经历以下几

rocketmq提供一种延时消息的解决方案,就是在特定的时间到了,消息才会被投递出去供consumer消费. 总体来是简单的场景是满足了,但是需要注意的是延时的时间是需要按照默认配置的延时级别去配置的,而不是随意设置消息的延时时间. 如果想不受延时级别的约束 可以参考之前的一遍文章http://blog.seoui.com/2017/08/19/delayqueue/ 默认的延迟级别 messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m

rocketmq  的延时消息不能支持任意延时,她定义了18 个延时等级,并且我们可以指定这18 个延时等级的延时时间. 发送消息的时候只需在消息中指定 当前消息的 延时等级即可,并且这个延时消息不是立刻翻到目标消息队列的,rocketmq 定义了 18 个 不可见的 队列,延时消息都放在这里面(有点像  rabbitmq 的 死信队列),当这个消息延时到了以后才投递给正常队列. java 代码例子: 修改 18 个默认延时等级例子.

痛点背景 业务场景 假设有这么一个需求,用户下单后如果30分钟未支付,则该订单需要被关闭.你会怎么做? 之前方案 最简单的做法,可以服务端启动个定时器,隔个几秒扫描数据库中待支付的订单,如果(当前时间-订单创建时间)>30分钟,则关闭订单. 方案评估 优点:是实现简单,缺点呢? 缺点:定时扫描意味着隔个几秒就得查一次数据库,频率高的情况下,如果数据库中订单总量特别大,这种高频扫描会对数据库带来一定压力,待付款订单特别多时(做个爆品秒杀活动,或者啥促销活动),若一次性查到内存中,容易引起宕机,需要

主流消息队列选型对比分析 基础项对比 可用性.可靠性对比 功能性对比 对比分析 Kafka:系统间的流数据通道 RocketMQ:高性能的可靠消息传输 RabbitMQ:可靠消息传输 RocketMQ剖析 RocketMQ拓扑图 RocketMQ架构组成 Producer:消息发布的角色,支持分布式集群方式部署.Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递,投递的过程支持快速失败并且低延迟. Consumer:消息消费的角色,支持分布式集群方式部署.支持以pu

当我们说顺序时,我们在说什么? 日常思维中,顺序大部分情况会和时间关联起来,即时间的先后表示事件的顺序关系. 比如事件A发生在下午3点一刻,而事件B发生在下午4点,那么我们认为事件A发生在事件B之前,他们的顺序关系为先A后B. 上面的例子之所以成立是因为他们有相同的参考系,即他们的时间是对应的同一个物理时钟的时间.如果A发生的时间是北京时间,而B依赖的时间是东京时间,那么先A后B的顺序关系还成立吗? 如果没有一个绝对的时间参考,那么A和B之间还有顺序吗,或者说怎么断定A和B的顺序? 显而易见的,

RocketMQ简介 RocketMQ是一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时的.高可靠.万亿级容量.灵活可伸缩的消息发布与订阅服务. 它前身是MetaQ,是阿里基于Kafka的设计使用Java进行自主研发的.在2012年,阿里将其开源, 在2016年,阿里将其捐献给Apache软件基金会(Apache Software Foundation,简称为ASF),正式成为孵化项目.2017 年,Apache软件基金会宣布RocketMQ已孵化成为 Apache顶级项目(Top

在阅读本文前,若您对RocketMQ技术感兴趣,请加入 RocketMQ技术交流群 根据上文的描述,发送事务消息的入口为: TransactionMQProducer#sendMessageInTransaction: public TransactionSendResult sendMessageInTransaction(final Message msg, final Object arg) throws MQClientException { if (null == this.trans

一.为什么选择RocketMQ消息队列? 首先RocketMQ是阿里巴巴自研出来的,也已开源.其性能和稳定性从双11就能看出来,借用阿里的一句官方介绍:历年双 11 购物狂欢节零点千万级 TPS.万亿级数据洪峰,创造了全球最大的业务消息并发以及流转纪录(日志类消息除外): 在始终保证高性能前提下,支持亿级消息堆积,不影响集群的正常服务,在削峰填谷(蓄洪).微服务解耦的场景下尤为重要:这,就能说明RocketMQ的强大. 二.RocketMQ的特点和优势(可跳过看三的整合代码) 削峰填谷(主要解决

一,为什么要用延时消息来取消订单? 1,为什么要取消订单 在电商的下单过程中,需要在生成订单时扣减库存, 但有可能发生这种情况:用户下了单,临时改变主意不再支付, 则订单不能无限期的保留,因为还要把占用的库存数量释放出来, 所以通常会在用户下单后半小时(或其他时长)把未支付的订单取消不再保留. 2,取消订单的方法: 通常我们会在crond中创建一个定时运行的任务,每1分钟执行一次, 把下单时间超过半小时的取出来,检查订单状态是否还是未支付, 如果仍未支付,则修改订单状态为无效,同时把库存数量加回

rocketmq事务消息 参考: https://blog.csdn.net/u011686226/article/details/78106215 https://yq.aliyun.com/articles/55630 https://my.oschina.net/u/2950586/blog/760677 https://blog.csdn.net/chunlongyu/article/details/53844393 分布式消息队列RocketMQ--事务消息--解决分布式事务的最佳实践

文章首发于公众号<程序员果果> 地址 : https://mp.weixin.qq.com/s/dYqGd9zi2mNelsNNLIribg 消息发送示例 导入依赖: <dependency> <groupId>org.apache.rocketmq</groupId> <artifactId>rocketmq-spring-boot-starter</artifactId> <version>2.1.1</vers

问题背景 所谓"延时消息"是指当消息被发送以后,并不想让消费者立即拿到消息,而是等待指定时间后,消费者才拿到这个消息进行消费. 场景一:客户A在十二点下了一个订单,我想半个小时后来检查一下这个订单的付款状态,根据付款状态来作下一步的处理. a. 针对场景一,建议采用方案数据库保存+schedule的方式也许更合适. 场景二:mdc系统更新了一个A信息,我要通知给A门店信息发生了变化,通知他们回调API来读取最新的值. 如果拿到消息后立即回调,可能因为mdc事务.缓存.从库延迟等原因,拿

rocketmq总结(消息的顺序.重复.事务.消费模式) 参考: http://www.cnblogs.com/wxd0108/p/6038543.html https://www.cnblogs.com/520playboy/p/6750023.html https://blog.csdn.net/chunlongyu/article/details/53977819 https://blog.csdn.net/zhanglianhai555/article/details/77604582?

做支付平台的时候.需要实现接受上游支付消息,通知给下游渠道. 针对下游渠道:要实现 按通知次数 递进 延时通知 下游渠道的支付/签约/代扣的状态 可参考微信按照 15/15/30/180/1800/1800/1800/1800/3600 单位s 等5个level去通知下游业务端 当时采用rabbitmq死信队列实现延时消息的通知: 当一个消息过期后,会自动变成死信.如果消息绑定了dead letter change,那么消息过期后会被转发到相应队列.从而实现消息延迟消费            具

rocketmq总结(消息的高可用.中间件选型) 参考: https://blog.csdn.net/meilong_whpu/article/details/76922456 http://blog.51cto.com/sofar/1540874 https://blog.csdn.net/lunaqi/article/details/78517200 https://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247487688&idx

搞懂分布式技术19:使用RocketMQ事务消息解决分布式事务 初步认识RocketMQ的核心模块 rocketmq模块 rocketmq-broker:接受生产者发来的消息并存储(通过调用rocketmq-store),消费者从这里取得消息. rocketmq-client:提供发送.接受消息的客户端API. rocketmq-namesrv:NameServer,类似于Zookeeper,这里保存着消息的TopicName,队列等运行时的元信息.(有点NameNode的味道) rocketm

RocketMQ(1)-架构原理 RocketMQ是阿里开源的分布式消息中间件,跟其它中间件相比,RocketMQ的特点是纯JAVA实现:集群和HA实现相对简单:在发生宕机和其它故障时消息丢失率更低. 一.RocketMQ专业术语 先讲专业术语的含义,后面会画流程图来更好的去理解它们. Producer 消息生产者,位于用户的进程内,Producer通过NameServer获取所有Broker的路由信息,根据负载均衡策略选择将消息发到哪个Broker,然后调用Broker接口提交消息. Prod

摘要: RocketMQ源码分析之从官方示例窥探RocketMQ事务消息实现基本思想. 在阅读本文前,若您对RocketMQ技术感兴趣,请加入RocketMQ技术交流群 RocketMQ4.3.0版本开始支持事务消息,后续分享将开始将剖析事务消息的实现原理.首先从官方给出的Demo实例入手,以此通往RocketMQ事务消息的世界中. 官方版本未发布之前,从apache rocketmq第一个版本上线后,代码中存在与事务消息相关的代码,例如COMMIT.ROLLBACK.PREPARED,在事务消

前言 前面我们跟大家聊了聊什么是消息中间件,以及哪些场景使用哪些消息中间件更加合适. 我们了解到RocketMQ是java语言开发的,我们能更深入的阅读源码了解它的底层原理,而且它具有优秀的消息中间件高级功能.再换个角度想,对于面试MQ来说,其实我们需要深入的了解一个中间件来与面试官聊,其他的中间件了解基本原理就可以了(后文会讲解). 所以接下来我们就以RocketMQ为敲门砖,一点一点了解MQ的奥秘. 今天我们来聊一聊RocketMQ 的架构原理 RocketMQ是如何承受高并发的呢? 先聊一