rocketmq核心源码分析第二十六篇一事务消息一broker端处理

已于 2022-02-11 21:10:47 修改
阅读量917 收藏 1
点赞数
分类专栏： rocketmq源码分析 文章标签： rocketmq
于 2022-02-11 20:00:59 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35529969/article/details/122887702
版权

文章目录

消息存储

原理图

  • 事务消息包括half消息,提交消息以及回滚消息
  • 分别由SendMessageProcessor和EndTransactionProcessor处理
  • half消息发送至RMQ_SYS_TRANS_HALF_TOPIC
  • 提交消息则发送至业务侧定义topic,并删除half消息
  • 回滚消息仅删除half消息,删除的实质是发送消息至RMQ_SYS_TRANS_OP_HALF_TOPIC
  • 删除是为了协助消息回查RMQ_SYS_TRANS_HALF_TOPIC避免二次处理

在这里插入图片描述

源码分析[half消息]一SendMessageProcessor.sendMessage

  • 如果消息sysflag携带事务标记
  • 则交由TransactionalMessageService处理
  • 调用桥接器进行存储
  • 进行消息topic转换后通过store.putMessage存储消息
private RemotingCommand sendMessage(final ChannelHandlerContext ctx,
                                        final RemotingCommand request,
                                        final SendMessageContext sendMessageContext,
                                        final SendMessageRequestHeader requestHeader) throws RemotingCommandException {
    ...... 删除其他代码
    处理事务消息还是普通消息
    if (traFlag != null && Boolean.parseBoolean(traFlag)
        处理事务消息 内部会将topic转化成事务topic
        putMessageResult = this.brokerController.getTransactionalMessageService().prepareMessage(msgInner);
    return handlePutMessageResult(putMessageResult, response, request, msgInner, responseHeader, sendMessageContext, ctx, queueIdInt);

}


public PutMessageResult prepareMessage(MessageExtBrokerInner messageInner) {
    通过桥接器[桥接DefaultMessageStore]进行存储
    return transactionalMessageBridge.putHalfMessage(messageInner);
}

源码分析一parseHalfMessageInner

  • 通过Msg Property属性进行topic转换
  • 将消息发送至RMQ_SYS_TRANS_HALF_TOPIC
  • 将原topic存储至PROPERTY_REAL_TOPIC
private MessageExtBrokerInner parseHalfMessageInner(MessageExtBrokerInner msgInner) {
    记住自己真实的topic和队列用于将来转换
    MessageAccessor.putProperty(msgInner, MessageConst.PROPERTY_REAL_TOPIC, msgInner.getTopic());
    MessageAccessor.putProperty(msgInner, MessageConst.PROPERTY_REAL_QUEUE_ID,
        String.valueOf(msgInner.getQueueId()));

    此时在设置类型为普通消息 [构建逻辑队列的时候如果是事务类型消息会跳过  这里转一下 用户构建逻辑队列]
    msgInner.setSysFlag(
        MessageSysFlag.resetTransactionValue(msgInner.getSysFlag(), MessageSysFlag.TRANSACTION_NOT_TYPE));
    设置到事务消息topic: RMQ_SYS_TRANS_HALF_TOPIC  half队列名称
    msgInner.setTopic(TransactionalMessageUtil.buildHalfTopic());
    half消息只有一个队列 设置成0
    msgInner.setQueueId(0);
    msgInner.setPropertiesString(MessageDecoder.messageProperties2String(msgInner.getProperties()));
    return msgInner;
}

源码分析[commit|rollback]一EndTransactionProcessor.processRequest

  • 区分请求为提交消息请求还是回滚消息请求
  • commit请求: 查询消息,还原消息转存到原topic
  • commit请求: 删除half topic上消息,转储到RMQ_SYS_TRANS_OP_HALF_TOPIC
  • rollback请求: 删除half topic上消息,转储到RMQ_SYS_TRANS_OP_HALF_TOPIC
public RemotingCommand processRequest(ChannelHandlerContext ctx, RemotingCommand request) throws
        RemotingCommandException {
    ...... 删除其他代码
    
    OperationResult result = new OperationResult();
    if (MessageSysFlag.TRANSACTION_COMMIT_TYPE == requestHeader.getCommitOrRollback()) {
        查询消息
        result = this.brokerController.getTransactionalMessageService().commitMessage(requestHeader);
        if (result.getResponseCode() == ResponseCode.SUCCESS) {
            检查消息
            RemotingCommand res = checkPrepareMessage(result.getPrepareMessage(), requestHeader);
            还原消息
            if (res.getCode() == ResponseCode.SUCCESS) {
                MessageExtBrokerInner msgInner = endMessageTransaction(result.getPrepareMessage());
                msgInner.setSysFlag(MessageSysFlag.resetTransactionValue(msgInner.getSysFlag(), requestHeader.getCommitOrRollback()));
                msgInner.setQueueOffset(requestHeader.getTranStateTableOffset());
                msgInner.setPreparedTransactionOffset(requestHeader.getCommitLogOffset());
                msgInner.setStoreTimestamp(result.getPrepareMessage().getStoreTimestamp());
                MessageAccessor.clearProperty(msgInner, MessageConst.PROPERTY_TRANSACTION_PREPARED);
                落盘commit消息 [消费者可消费] 发送到真实主题
                RemotingCommand sendResult = sendFinalMessage(msgInner);
                删除prepare消息[注意commitlog是appendOnly的操作  这里的删除实现如下]
                消息放入RMQ_SYS_TRANS_OP_HALF_TOPIC的主题 ， OP_HALF_TOPIC与half_topic一对一
                消息内容为half消息 的queueoffset 并设置TAGS的属性为'd'
                if (sendResult.getCode() == ResponseCode.SUCCESS) {
                    this.brokerController.getTransactionalMessageService().deletePrepareMessage(result.getPrepareMessage());
                }
                return sendResult;
            }
            return res;
        }
    } else if (MessageSysFlag.TRANSACTION_ROLLBACK_TYPE == requestHeader.getCommitOrRollback()) {
        rollback 逻辑
        result = this.brokerController.getTransactionalMessageService().rollbackMessage(requestHeader);
        if (result.getResponseCode() == ResponseCode.SUCCESS) {
            RemotingCommand res = checkPrepareMessage(result.getPrepareMessage(), requestHeader);
            if (res.getCode() == ResponseCode.SUCCESS) {
                插入op halftopic  但是没有还原真实消息落盘 所以rollback消息永远不会被消费
                this.brokerController.getTransactionalMessageService().deletePrepareMessage(result.getPrepareMessage());
            }
            return res;
        }
    }
    response.setCode(result.getResponseCode());
    response.setRemark(result.getResponseRemark());
    return response;
}

deletePrepareMessage

  • 三部曲:通过桥接器删除消息
  • 构建MessageQueue信息并执行topic消息存储
  • 写入Op主题RMQ_SYS_TRANS_OP_HALF_TOPIC
public boolean deletePrepareMessage(MessageExt msgExt) {
    处理Op消息
    if (this.transactionalMessageBridge.putOpMessage(msgExt, TransactionalMessageUtil.REMOVETAG)) {
        return true;
    } 
}

public boolean putOpMessage(MessageExt messageExt, String opType) {
    MessageQueue messageQueue = new MessageQueue(messageExt.getTopic(),
        this.brokerController.getBrokerConfig().getBrokerName(), messageExt.getQueueId());
    if (TransactionalMessageUtil.REMOVETAG.equals(opType)) {
        添加到Op主题RMQ_SYS_TRANS_OP_HALF_TOPIC
        return addRemoveTagInTransactionOp(messageExt, messageQueue);
    }
    return true;
}



 private boolean addRemoveTagInTransactionOp(MessageExt messageExt, MessageQueue messageQueue) {
    构建RMQ_SYS_TRANS_OP_HALF_TOPIC主题
    Message message = new Message(TransactionalMessageUtil.buildOpTopic(), TransactionalMessageUtil.REMOVETAG,
        String.valueOf(messageExt.getQueueOffset()).getBytes(TransactionalMessageUtil.charset));
    写入Op消息到messageQueue [底层调用store.putMessage]
    writeOp(message, messageQueue);
    return true;
}

消息回查

  • 回查线程每一分钟执行一次
  • 处理超过6秒未回查消息
  • 超过15次则丢弃消息
public class TransactionalMessageCheckService extends ServiceThread {
    @Override
    public void run() {
        while (!this.isStopped()) {
            1分钟等待
            this.waitForRunning(checkInterval);
        }
    }
    等待结束则执行回查
    @Override
    protected void onWaitEnd() {
        超过6秒需要回查
        long timeout = brokerController.getBrokerConfig().getTransactionTimeOut();
        // 最多回查15次 超过则执行rollback
        int checkMax = brokerController.getBrokerConfig().getTransactionCheckMax();
        long begin = System.currentTimeMillis();
            事务消息回查
        this.brokerController.getTransactionalMessageService().check(timeout, checkMax, this.brokerController.getTransactionalMessageCheckListener());
    }
}

源码分析一check

  • 根据transactionTimeout,transactionCheckMax以及用户自定义checkImmunityTimeStr来决定是否回查消息
  • 回查消息通过异步调用请求触发生产者TransactionListener.checkLocalTransaction
  • 生产者则再次发送相关请求至EndTransactionProcessor
  • 超过15次回查则丢弃消息至TRANS_CHECK_MAX_TIME_TOPIC
  • 通过RMQ_SYS_TRANS_OP_HALF_TOPIC判断消息是否已经被删除,删除则无需处理
  • 一次仅拉取32条RMQ_SYS_TRANS_OP_HALF_TOPIC,如果存在未成功匹配,则多次拉取
public void check(long transactionTimeout, int transactionCheckMax,
    AbstractTransactionalMessageCheckListener listener) {
    try {
        String topic = MixAll.RMQ_SYS_TRANS_HALF_TOPIC;
        Set<MessageQueue> msgQueues = transactionalMessageBridge.fetchMessageQueues(topic);
        if (msgQueues == null || msgQueues.size() == 0) {
            log.warn("The queue of topic is empty :" + topic);
            return;
        }
        log.debug("Check topic={}, queues={}", topic, msgQueues);
        // 系统的事务halftopic只有一个队列  所以这里是单循环
        for (MessageQueue messageQueue : msgQueues) {
            long startTime = System.currentTimeMillis();
            // 根据half的mq 获取op 的mq
            MessageQueue opQueue = getOpQueue(messageQueue);
            //  获取两者消费进度
            long halfOffset = transactionalMessageBridge.fetchConsumeOffset(messageQueue);
            long opOffset = transactionalMessageBridge.fetchConsumeOffset(opQueue);
            log.info("Before check, the queue={} msgOffset={} opOffset={}", messageQueue, halfOffset, opOffset);
            if (halfOffset < 0 || opOffset < 0) {
                log.error("MessageQueue: {} illegal offset read: {}, op offset: {},skip this queue", messageQueue,
                    halfOffset, opOffset);
                continue;
            }
            List<Long> doneOpOffset = new ArrayList<>();
            HashMap<Long, Long> removeMap = new HashMap<>();
            // 填充
            PullResult pullResult = fillOpRemoveMap(removeMap, opQueue, opOffset, halfOffset, doneOpOffset);
            if (null == pullResult) {
                log.error("The queue={} check msgOffset={} with opOffset={} failed, pullResult is null",
                    messageQueue, halfOffset, opOffset);
                continue;
            }
            // single thread
            int getMessageNullCount = 1; // 获取空消息的次数。
            long newOffset = halfOffset; //       i：当前处理消息的队列偏移量，其主题依然为RMQ_SYS_TRANS_HALF_TOPIC。

            long i = halfOffset;
            // 判断消息符合回查条件
            while (true) {
                // 如果执行的时间超过60s则中断
                if (System.currentTimeMillis() - startTime > MAX_PROCESS_TIME_LIMIT) {
                    log.info("Queue={} process time reach max={}", messageQueue, MAX_PROCESS_TIME_LIMIT);
                    break;
                }
                // 如果removeMap中包含当前处理的消息，则继续下一条，removeMap中是从RMQ_SYS_TRANS_OP_HALF_TOPIC主题中拉取32条，
                // 如果拉取的消息队列偏移量大于等于RMQ_SYS_TRANS_HALF_TOPIC#queueId当前的处理进度时，会添加到removeMap中，表示已处理过

                if (removeMap.containsKey(i)) {
                    log.info("Half offset {} has been committed/rolled back", i);
                    Long removedOpOffset = removeMap.remove(i);
                    doneOpOffset.add(removedOpOffset);
                } else {
                    GetResult getResult = getHalfMsg(messageQueue, i);
                    MessageExt msgExt = getResult.getMsg();
                    if (msgExt == null) {
                        if (getMessageNullCount++ > MAX_RETRY_COUNT_WHEN_HALF_NULL) {
                            break;
                        }
                        if (getResult.getPullResult().getPullStatus() == PullStatus.NO_NEW_MSG) {
                            log.debug("No new msg, the miss offset={} in={}, continue check={}, pull result={}", i,
                                messageQueue, getMessageNullCount, getResult.getPullResult());
                            break;
                        } else {
                            log.info("Illegal offset, the miss offset={} in={}, continue check={}, pull result={}",
                                i, messageQueue, getMessageNullCount, getResult.getPullResult());
                            i = getResult.getPullResult().getNextBeginOffset();
                            newOffset = i;
                            continue;
                        }
                    }
                    // 如果该消息回查的次数超过允许的最大回查次数15，则该消息将被丢弃
                    // 如果事务消息超过文件的过期时间72h,则跳过该消息
                    if (needDiscard(msgExt, transactionCheckMax) || needSkip(msgExt)) {
                        listener.resolveDiscardMsg(msgExt);
                        newOffset = i + 1;
                        i++;
                        continue;
                    }
                    if (msgExt.getStoreTimestamp() >= startTime) {
                        log.debug("Fresh stored. the miss offset={}, check it later, store={}", i,
                            new Date(msgExt.getStoreTimestamp()));
                        break;
                    }
                    // 该消息已存储的时间,等于系统当前时间减去消息存储的时间戳
                    long valueOfCurrentMinusBorn = System.currentTimeMillis() - msgExt.getBornTimestamp();
                    // 应用程序在发送事务消息后，事务在一段时间不会马上提交，
                    // 则这段时间不应该发送回查请求。
                    long checkImmunityTime = transactionTimeout;
                    String checkImmunityTimeStr = msgExt.getUserProperty(MessageConst.PROPERTY_CHECK_IMMUNITY_TIME_IN_SECONDS);
                    // 如果消息指定了事务消息过期时间属性（PROPERTY_CHECK_IMMUNITY_TIME_IN_SECONDS），如果当前时间已超过该值
                    if (null != checkImmunityTimeStr) {
                        // transactionTimeout为事务消息的超时时间
                        checkImmunityTime = getImmunityTime(checkImmunityTimeStr, transactionTimeout);
                        // 未超过一段时间则不应该发送回查请求
                        if (valueOfCurrentMinusBorn < checkImmunityTime) {
                            // 将这个msg推进至新的offset
                            if (checkPrepareQueueOffset(removeMap, doneOpOffset, msgExt)) {
                                newOffset = i + 1;
                                i++;
                                continue;
                            }
                        }
                    } else {
                        // 未配置checkImmunityTimeStr 如果当前存储时间小于transactionTimeout，等下一次再试。
                        if ((0 <= valueOfCurrentMinusBorn) && (valueOfCurrentMinusBorn < checkImmunityTime)) {
                            log.debug("New arrived, the miss offset={}, check it later checkImmunity={}, born={}", i,
                                checkImmunityTime, new Date(msgExt.getBornTimestamp()));
                            break;
                        }
                    }
                    List<MessageExt> opMsg = pullResult.getMsgFoundList();
                    // 判断是否需要回查
                    boolean isNeedCheck = (opMsg == null && valueOfCurrentMinusBorn > checkImmunityTime)
                        || (opMsg != null && (opMsg.get(opMsg.size() - 1).getBornTimestamp() - startTime > transactionTimeout))
                        || (valueOfCurrentMinusBorn <= -1);

                    if (isNeedCheck) {
                        // 如果需要发送事务状态回查消息，则先将消息再次发送到RMQ_SYS_TRANS_HALF_TOPIC主题中，发送成功则返回true，否则返回false
                        if (!putBackHalfMsgQueue(msgExt, i)) {
                            continue;
                        }
                        //线程池来异步发送回查消息 调用生产者【TransactionListener.checkLocalTransaction】
                        listener.resolveHalfMsg(msgExt);
                    } else {
                        // 如果无法判断是否发送回查消息，则加载更多的已处理消息进行刷选
                        pullResult = fillOpRemoveMap(removeMap, opQueue, pullResult.getNextBeginOffset(), halfOffset, doneOpOffset);
                        log.debug("The miss offset:{} in messageQueue:{} need to get more opMsg, result is:{}", i,
                            messageQueue, pullResult);
                        continue;
                    }
                }
                newOffset = i + 1;
                i++;
            }
            if (newOffset != halfOffset) {
                // 更新half topic 的消费位点
                transactionalMessageBridge.updateConsumeOffset(messageQueue, newOffset);
            }
            // 更新op half topic 的消费位点
            long newOpOffset = calculateOpOffset(doneOpOffset, opOffset);
            if (newOpOffset != opOffset) {
                transactionalMessageBridge.updateConsumeOffset(opQueue, newOpOffset);
            }
        }
    } catch (Throwable e) {
        log.error("Check error", e);
    }
}

总结

  • 事务消息通过生产者主动发送以及broker回查共同完成
  • 回查最大次数为15次
  • 回查需要RMQ_SYS_TRANS_OP_HALF_TOPIC和RMQ_SYS_TRANS_HALF_TOPIC协助工作
  • 消息最开始发送至half队列,等待commit提交完成后发送至业务队列供消费者消费
RocketMQ源码分析之RocketMQ事务消息实现原理中篇----事务消息状态回查
m0_61043185的博客
03-29 621
这份《“java高分面试指南”-25分类227页1000+题50w+字解析》同样可分享给有需要的朋友，感兴趣的伙伴们可挑战一下自我，在不看答案解析的情况，测试测试自己的解题水平，这样也能达到事半功倍的效果！（好东西要大家一起看才香）的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！**由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新。
一定能看懂的RocketMQ事务消息源码分析(干货)
gotobat的博客
07-14 1089
前言 得益于MQ削峰填谷，系统解耦，操作异步等功能特性，在互联网行业，可以说有分布式服务的地方，MQ都往往不会缺席。由阿里自研的RocketMQ更是经历了多年的双十一高并发挑战，其中4.3.0版本推出了事务消息的新特性，本文对RocketMQ 4.5.0版本事务消息相关的源码跟踪介绍，通过阅读读者可以知道： 事务消息解决什么样的问题 事务消息的实现原理及其设计亮点 解决什么问题 假设我所在的系...
RocketMQ源码解析之broker（事务消息处理）
猿上生活
12-06 754
原创不易，转载请注明出处 文章目录前言1.broker事务消息处理流程2.源码分析2.1 broker事务消息处理组件初始化2.2 接收事务消息2.3 提交事务或者是回滚事务2.4 定时检查本地事务执行结果总结 前言 我们在《RocketMQ源码解析之消息生产者（事务消息原理篇）》一文中介绍过RocketMQ事务消息的原理，但是主要是介绍的消息生产者使用事务消息最佳姿势以及事务消息设计思想，并没有对broker处理事务消息这块进行深入的解读，然后本文就是为了补上broker对事务消息处理这块的，主要是.
RocketMQ的事务消息原理及源码解读
慢一拍的coder
11-04 711
目录 1：实现思想 2：事务消息发送流程 3：消息提交，回滚 4：回查事务状态 5：总结 1：实现思想 RocketMQ事务消息的实现原理是基于两阶段提交（可以去了解一下XA）和定时事务状态回查来决定消息最终是提交还是回滚。一般地，应用程序在事务内完成相应的DB后，需要同步来调用mq相关的接口来发送消息，发送状态为prepare的消息（笔者称之为预消息），消息发送成功后，Roc...
RocketMQ事务消息
Charge8的博客
06-03 760
一、RocketMQ事务消息 RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。 注意：主要针对消息发送者。 RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。 1、RocketMQ事务消息流程概要 上图说明了事务消息的大致方案，其中分为两个流程： 正常事务消息的发送及提交 事务消息的补偿流程。 1.1 正常事务流程 (1) 发送消息
RocketMQ源码解析之Broker消息存储（消息存储）
fengwuya的博客
09-30 270
接上篇RocketMQ源码解析之Broker消息存储(消息接收) DefaultMessageStore#asyncPutMessage /** * 进行存储 * * @param msg MessageInstance to store * @return */ @Override public CompletableFuture<PutMessageResult> as...
RocketMQ源码分析之Message拉取与消费（上Broker把消息推送到对应的消费队列）
1Q84emo的博客
02-04 2469
消费逻辑图： 消费者队列根据Topic、QueueId分别存储相应的消息在CommitLog中的位置信息（offset、size、tagsCode），因此Consume Queue并没有存储实际要消费的信息，而是需要通过实际存储的CommitLog中的位置信息在找一遍真正的要消费的信息 消费顺序简图 ConsumeQueue存储消息 主要有两个服务组件： - Reput
轻松解读RocketMQ5.3.0核心源码
最新发布
roykingw的专栏
10-24 931
同步刷盘，异步刷盘？同步同步，异步同步？零拷贝，顺序写？你是不是曾经在各种各样的流量短视频和博客中听说过跟RocketMQ相关的这些亮瞎眼的高大上的技术名词？你有没有想过自己去RocketMQ中看看这些概念背后的Java代码是什么样的？如果你有过这样的想法，那么，楼兰到你到RocketMQ的源码当中逛逛，看看RocketMQ的大神们，是如何用简单常见的MVC思想开发出RocketMQ这样的神作的。
RocketMQ源码分析之顺序消费
1Q84emo的博客
02-13 768
概述RocketMQ按照顺序消费有两种顺序级别，一种是普通顺序消息。另外一种是更完全严格顺序 普通顺序消息指的是Producer将消息发送到相对应的消息队列上面 完全严格顺序：在普通顺序消息的基础上，Consumer严格进行顺序消费 在绝大部分情况下只需要用到普通顺序消息，大部分的应用都能容忍短暂的乱序；官方文档给出的说明中表示目前只有数据库的Binlog同步会强依赖完全严格顺序（要保证数据库事务
消息中间件 RocketMQ 源码解析：Message 发送&接收
热门推荐
芋艿V
04-30 1万+
1、概述 Producer 发送消息。主要是同步发送消息源码，涉及到 异步/Oneway发送消息，事务消息会跳过。 Broker 接收消息。(存储消息在《RocketMQ源码解析：Message存储》解析) 2、Producer 发送消息 DefaultMQProducer#send(Message) 1: @Override 2: public SendResult send(Me
RocketMQ 事务消息使用与分析
Silence的博客
11-07 1264
解决本地事务执行与消息发送的原子性问题。即解决Producer执行业务逻辑成功之后投递消息可能失败的场景。
rocketmq-事务消息
少爷
09-26 315
前言 之前有转载过一篇关于分布式事务最终一致的MQ实现的文章，当时也是碰到了分布式事务的情形，最后按照文章的思路利用rmq实现了数据的最终一致。不太清楚分布式事务的，可以先看下这边文章了解下。 PS：本篇默认你已经了解rmq的一些基础并看过部分源代码，建议在看该篇时，先看下官方的文档RocketMQ事务消息。 牵涉到的分布式的话题一般都会提到CAP，从知乎上打捞来一份比较好解释。 P 意指分区容...
不知道事务消息吗,这篇文章帮你全面扫盲
hdx柿子的博客
04-02 256
感谢参考原文-http://bjbsair.com/2020-04-01/tech-info/18460.html 为什么需要事务消息？ 很多同学可能不知道事务消息是什么，没关系，举一个真实业务场景，先来带你了解一下普通的消息存在问题。 上面业务场景中，当用户支付成功，将会更新支付订单，然后发送 MQ 消息。手续费系统将会通过拉取消息，计算手续费然后保存到另外一个手续费数据库中。 由于计算手续费...
还不知道事务消息吗？这篇文章带你全面扫...
heima201907的博客
04-08 130
在分布式系统中，为了保证数据一致性是必须使用分布式事务。分布式事务实现方式就很多种，今天主要介绍一下使用 RocketMQ 事务消息，实现分布事务。 文末有彩蛋，看完再走 为什么需要事务消息？ 很多同学可能不知道事务消息是什么，没关系，举一个真实业务场景，先来带你了解一下普通的消息存在问题。 上面业务场景中，当用户支付成功，将会更新支付订单，然后发送 MQ 消息。手续费系统将会通过...
ROCKETMQ事务消息原理
weixin_33697898的博客
12-20 415
2019独角兽企业重金招聘Python工程师标准>>> ...
RocketMQ源码解析十三（事务消息流程）
指尖凉的博客
09-28 208
代码示例
RocketMQ特性--Broker是如何存储事务消息的？
m0_71777195的博客
08-17 199
在中，事务消息的初始化是通过方法执行的。这里有三个核心的初始化变量。
RocketMQ源码理解之事务消息
fengwuya的博客
04-24 326
二提交阶段 RocketMQ的事务消息总体也可认为是采用二提交阶段： 在事务开始的时候，先发送一个 事务消息 RocketMQ使用 事务消息发送 构建half 消息 Broker事务消息提交/回滚流程 后台有个EndTransactionProcessor 线程用来处理事务提交/回滚消息，该线程会在BrokerController#registerProcessor方法中进行注册，在...
分布式事务-RocketMQ事务消息源码分析
hosaos的博客
05-16 2211
前言 上篇文章介绍了RocketMQ事务消息的基本原理，对大致的流程及设计思路有个大致的了解 分布式事务-RocketMQ消息事务设计思路及Demo 文章最后，也提出了几个问题 为什么prepare消息在发送后不会被消费？ 事务消息又是如何提交、回滚的？ 定时回查本地事务状态的机制又是怎么样？ 废话不多说，直接盘源码，从源码中找问题答案，源码中都加了todo注释，方便大家查看 发送流程 先从事...
RocketMQ4.0源码分析：事务消息机制解析
"这篇分析文章主要探讨了RocketMQ 4.0版本中的事务消息实现，作者赵彬基于GitHub上的Fork版本进行了解析。事务消息是RocketMQ的一个关键特性，用于处理分布式环境中的事务一致性问题。文章通过Bob-Smith转账场景展示...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值