这周RocketMQ发布了4.3.0版本,New Feature中最受关注的一点就是支持了事务消息: 今天花了点时间看了下具体的实现内容,下面是简单的总结. RocketMQ事务消息概要 通过冯嘉发布的<RocketMQ 4.3正式发布,支持分布式事务>一文可以看到RocketMQ采用了2PC的方案来提交事务消息,同时增加一个补偿逻辑来处理二阶段超时或者失败的消息. 这张图说明了事务消息的大致方案,分为两个逻辑:正常事务消息的发送及提交.事务消息的补偿流程 事务消息发送及提交: 发送消息(ha

一.背景 MQ组件是系统架构里必不可少的一门利器,设计层面可以降低系统耦合度,高并发场景又可以起到削峰填谷的作用,从单体应用到集群部署方案,再到现在的微服务架构,MQ凭借其优秀的性能和高可靠性,得到了广泛的认可. 随着数据量增多,系统压力变大,开始出现这种现象:数据库已经更新了,但消息没发出来,或者消息先发了,但后来数据库更新失败了,结果研发童鞋各种数据修复,这种生产问题出现的概率不大,但让人很郁闷.这个其实就是数据库事务与MQ消息的一致性问题,简单来讲,数据库的事务跟普通MQ消息发送无法直接绑

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

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

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

幂等(idempotent.idempotence)是一个数学与计算机学概念,常见于抽象代数中. 在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同. 首先我们了解一下什么是幂等,以及何为消息幂等. 什么是幂等 百度对 “幂等” 解释如下 设f为一由X映射至X的一元运算,则f为幂等的,当对于所有在X内的x,f(f(x)) = f(x).特别的是,恒等函数一定是幂等的,且任一常数函数也都是幂等的. 这里的关键是 f(f(x)) = f(x), 翻译成通俗的解释就是: 如果

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?

RocketMQ 事务消息在实现上充分利用了 RocketMQ 本身机制,在实现零依赖的基础上,同样实现了高性能.可扩展.全异步等一系列特性. 在具体实现上,RocketMQ 通过使用 Half Topic 以及 Operation Topic 两个内部队列来存储事务消息推进状态,如下图所示: 其中,Half Topic 对应队列中存放着 prepare 消息,Operation Topic 对应的队列则存放了 prepare message 对应的 commit/rollback 消息,消息体

系列文章 RocketMQ入门篇 RocketMQ生产者流程篇 RocketMQ生产者消息篇 前言 上文RocketMQ生产者流程篇中详细介绍了生产者发送消息的流程,本文将重点介绍发送消息的通信模式以及各种不同的消息类型. 通信模式 RocketMQ提供了三种通讯模式,分别是:同步,异步和单向:可以查看内部类CommunicationMode: public enum CommunicationMode { SYNC, ASYNC, ONEWAY, } 下面分别看一下三种通讯模式如何使用 1.同

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

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--事务消息--解决分布式事务的最佳实践

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

在前面学习ActiveMQ时,看到ActiveMQ可以是队列消息模式,也可以是订阅发布模式. 同样,在RocketMQ中,也存在两种消息模式,即是集群消费模式和广播消费模式. 1. 集群消费模式 跟AciiveMQ一样,当存在多个消费者时,消息通过一定负载均衡策略,将消息分发到多个consumer中. 如图: 在RockeMQ中,通过ConsumeGroup的机制,实现了天然的消息负载均衡!通俗点来说,RocketMQ中的消息通过ConsumeGroup实现了将消息分发到C1/C2/C3/……的

说明 周五的时候发了篇:Rocketmq4.3支持事务啦!!!,趁着周末的时候把相关内容看了下,下面的主要内容就是关于RocketMQ事务相关内容介绍了. 说明: 今天这篇仅仅是入门介绍,并没有涉及到很多细节,先把大概流程说明白,后续再具体细节进行开篇说明. 主题 引出分布式事务相关内容. RocketMQ事务消息. RocketMQ事务消息如何使用. RocketMQ事务消息是怎么实现的. 为什么需要事务消息会查机制. RocketMQ是怎么进行事务消息会查的. RocketMQ对于分布式事务

事务消息 通过消息的异步事务,可以保证本地事务和消息发送同时执行成功或失败,从而保证了数据的最终一致性. 发送端执行如下几步: 发送prepare消息,该消息对Consumer不可见 执行本地事务(如 update DB) 若本地事务执行成功,则向MQ提交消息确认发送指令:若本地事务执行失败,则向MQ发送取消指令(取消prepared消息) 若MQ长时间未收到确认发送或取消发送的指令,则向业务系统询问本地事务状态,并做补偿处理.( RocketMQ第一阶段发送Prepared消息时,会拿到消息的

TransactionProducer(事务消息): 在分布式系统中,我们时常会遇到分布式事务的问题,除了常规的解决方案之外,我们还可以利用RocketMQ的事务性消息来解决分布式事务的问题.RocketMQ和其他消息中间件最大的一个区别是支持了事务消息,这也是分布式事务里面的基于消息的最终一致性方案. RocketMQ消息的事务架构设计: 生产者执行本地事务,修改订单支付状态,并且提交事务 生产者发送事务消息到broker上,消息发送到broker上在没有确认之前,消息对于consumer是不

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

前言 通过之前文章的阅读,有关RocketMQ的底层原理相信小伙伴们已经有了一个比较清晰的认识. 那么接下来王子想跟大家讨论一个话题,如果我们的项目中引入了MQ,势必要面对的一个问题,就是消息丢失问题,今天我们就来聊聊消息是怎么丢失的. 现在假设我们的业务是这样的,用户通过订单系统下了一个订单,订单系统完成支付后会发送消息给RocketMQ,然后积分系统会从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

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