本地事务表+普通mq实现最终一致性

最新推荐文章于 2025-04-20 17:46:40 发布
原创 最新推荐文章于 2025-04-20 17:46:40 发布 · 2.1k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #kafka

本文详细描述了一套业务处理流程，涉及本地数据事务、消息队列通信、幂等性保障及错误重试机制。特别强调了在处理异常情况时，如何确保消息一致性，尤其是在消息消费和确认阶段的挑战与解决方案。

主要流程步骤

  1. 1，本地业务数据处理
  2. 2.1本地消息数据处理(1+2.1需要在同一个事务)，要么成功，要么失败
  3. 2.2 发送消息给mq
  4. 3，消息投递到Consumer消费端
  5. 4,消费端服务处理业务数据
  6. 5，业务端业务数据消费成功，反馈给comsumer
  7. 6，comsumer返回ack非消息中间件MQ
  8. 7,发送ack消息，更新本地消息表，表示已经完成或者消费成功，修改消息状态
  9. 8，恢复系统定时轮询消息表，找出没有消费成功ack的消息
  10. 9，重新发送没有消费成功的消息

bad case

  1. 如果1，2.1出错，本地事务回滚，业务数据，消息都没有变化，啥都没做
  2. 如果2.2 发送失败，定时任务系统会查询消息表，依据状态重新发送
  3. 3-7步骤出错，也没法ack本地消息表，都会重新发送消息
  4. 既然会重新发送消息，那消费端就要考虑重复消息的问题，也就是幂等，尤其是在7.1/7.2确认过程中失败了，一旦重复发送，如果不幂等，业务逻辑就会重复执行，如果是减库存或者支付场景，就会出现多加或者多减数据，出现不一致

最终一致性之本地消息表、消息事务
hosaos的博客
10-18 3128
互联网大背景下，微服务盛行，平时开发中难免会遇到分布式事务问题。大家经常会听到CAP原理，即一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三个指标不可能同时满足，而一致性是其中一个最大的难题。本文会从分布式事务产生背景开始，介绍常见分布式事务解决方案，最后会详细介绍基于消息中间件实现最终一致性的两种方案 文章目录分布式事务产生背景数据库水平拆分微服务拆分分布式事务解决方案TCCXA事务(2PC)最终一致性(消息事务)错误场景一错误
分布式事务：本地消息表
最新发布
Quan
06-23 1156
本地消息表是一种基于数据库的分布式事务解决方案，通过将分布式事务拆分为本地事务和消息事件来实现最终一致性。其核心流程包括：事务发起方完成本地业务操作并存储消息到数据库；定时任务扫描并发送未处理消息；接收方处理消息后发送确认。该方案优点包括简化编程模型、提高系统吞吐量、保证可靠性，但存在实时性不高、开发成本较高等缺点。适用于电商订单、资金转账等对最终一致性要求高但对实时性要求不高的场景，实现时需考虑消息表设计、幂等处理及异常重试机制。
JAVA面试题分享五百六十三：如何通过本地消息表实现分布式事务
之乎者也·的博客
02-22 1244
单独创建一个后台线程或定时任务，定时扫描本地消息表中状态为待发送的消息，并将这些消息发送到消息队列。通过本地消息表（也称为可靠消息表）实现分布式事务是一种常见的做法，用于保证在分布式环境中消息的可靠传递和事务的一致性。如果本地事务失败，回滚本地事务和消息表的记录。在数据库中创建一个本地消息表，用于存储待发送的消息以及消息的发送状态和相关信息。• 生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。：在业务逻辑中，当需要发送消息时，首先将消息插入到本地消息表中，设置状态为待发送。
SpringCloud集成RocketMQ实现可靠消息最终一致性【本地消息表、RocketMQ 事务消息方案】
骏马逸动，心随你动的博客
10-29 1576
目录 一、可靠消息最终一致性事务概述 二、解决方案【本地消息表方案】 三、解决方案【RocketMQ事务消息方案】 四、RocketMQ实现可靠消息最终一致性事务 五、总结 一、可靠消息最终一致性事务概述 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图： 事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息..
MQ与本地事务一致性问题---RocketMQ事务型消息
ZHUSHANGLIN的博客
10-13 471
我们在下单的时候，经常会使用mq发送一个异步消息，然后扣减库存，那么在这个过程中可能会发生 异步消息发送失败，扣减库存执行失败，导致下单失败无法正确回补库存，针对这种不一致性问题，可以使用事务型消息。
消息队列与分布式事务：探讨不同MQ如何实现可靠消息最终一致性
Apple_Boy的博客
08-17 1731
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。
RocketMQ实现基于可靠消息的最终一致性
2301_79368422的博客
04-20 1185
查找订单表中是否有此订单，如果订单表中没有此订单，说明本地事务执行失败，所以直接提交消息；如果存在此订单，说明本地事务执行成功，所以回滚消息（缺陷：订单表中没有此订单，不代表本地事务已经将库存扣减了，可能还没扣减前就已经出错了，这是提交消息会造成库存多扣减（没有保证幂等性））实现事务监听接口（此接口有两个方法：执行本地事务和检查本地事务）的结构体（方法调用者），在其中加入自定义字段，存储接口中的方法结束后，需要返回的信息（直接将信息存储到方法调用者中的相应字段里，以便在新建订单方法中可以直接查看）
基于RabbitMQ实现下单减库存的最终一致性分布式事务
weixin_43741322的博客
11-02 1865
用户下单调用订单服务，我们直接把这个消息发给MQ的订单交换机，同时调用远程库存服务锁定库存。：发给订单交换机的消息自动转发给死信队列，死信队列经过30分钟后过期会自动转发给我们另一个普通的队列。：跟第二步的同时，调用了库存服务的锁库存方法后，库存服务也会给库存交换机发一条消息，交换机转发给死信队列，经过60分钟后过期再转发给另一个普通队列。
RocketMQ事务消息如何保证数据的最终一致性
天堂的博客
03-06 5057
前言 在面过的几家大厂中，几乎每轮的面试官(没写错，几乎是每轮面试官)都问了同样一个问题：你们的系统是分布式的系统吗？ 答：是。 面试官：那么你们分布式的系统是如何解决分布式事务这个问题的呢？也就是如何保证数据的一致性。 答：我们的系统中通过 RocketMQ 的事务消息来保证数据的最终一致性。 面试官：那你说说它是如何来保证数据的最终一致性的？ 答：分两部分来回答，第一部分先回答事务消息的实现流程，第二部分解释为什么它能保证数据的最终一致性。 事务消息的实现流程 [外链图片转存失败,源站可能有防盗链机
可靠消息最终一致性【本地消息表、RocketMQ 事务消息方案】
很多时候犯错都是在不知情的情况下发生的
02-23 1212
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。此方案是利用消息中间件完成，如下图：事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。因此可靠消息最终一致性方案要解决以下几个问题： 【1】
分布式事务解决方案——可靠消息最终一致性（本地消息表、MQ自身提供的可靠性保证）
保暖透气大裤衩LeoLee的博客
11-16 937
什么是可靠消息最终一致性 指的是当事务发起方执行完成本地事务后并发送一条消息，事务参与方（消息的消费者）一定可以收到该消息，并完成接下来的业务处理，保证事务的成功。在此方案中，强调的是最终一致性，这就要保证发送的消息是一定能被事务参与者接收到的。 完成消息通知是需要使用消息中间件：MQ 事务发起方执行业务开启事务，发送消息到消息中间件 事务参与者监听消息中间件的队列，从队列中获取消息 在消息的传递过程中，消息是必须可靠的，必须能被事务参与者获取到的，这就是消息的可靠性 在事务的参与者接收到消
大型项目改造实践经验篇----分布式事务之本地事务表
qq_27631217的博客
11-22 651
分布式系统中，分布式事务是避不开的问题。 理论知识不再过多赘述，CAP,BASE理论，这些都是面试避不开的话题，下面说一下自己的一些经验。 其实无论是单机事务，还是分布式事务，核心都是一个词，事务。在java语言的落地过程中，事务封装在Connection对象中，正常提交是commit()，异常回滚是rollback()。 最好的解决方案就是去掉分布式事务，接口粗化，避免分布式事务，数据一致性要求不高，甚至可以不用考虑，等应用场景多了之后，可以针对这些数据库应用做一个数据清洗程序，定时清洗即可。 但
本地消息表实现最终一致性-案例
ligeforrent的专栏
09-16 846
作者提供本地消息表案例，解决最终一致性问题。 link:https://segmentfault.com/a/1190000012415698 以下为原文。 背景 传统的单体应用不会横跨多个数据库，可以通过单机事务保证一致性。然而在海量数据的场景下，我需要对数据库做拆分，即分库分表，而Cobar、MyCat这类分库分表中间件并不提供分布式事务的特性，并且基于二阶段提交的分布式事务性能较差，对于大多数业务场景来说，并不需要强一致，只需要保证最终一致性即可。 实践 下面我们举个下订单的场景，总共有.
分布式事务解决方案（本地事件+mq）
越自律越自由
05-01 1849
分布式事务消息 常见解决方案有：两阶段提交(2PC)、补偿事务(TCC)、本地事件表加消息队列、mq事务消息等。 两阶段提交原理： 最终一致性解决方案 以新用户注册新增一条积分记录为例，所需考虑的场景： 1、保存用户记录后没来得及想消息队列发送消息就宕机了，如何保证mq消息发送？ 2、积分系统收到消息后没来得及保存记录就宕机了，如何保证系统重启后不丢失积分记录？ 需要在db1和db2中分...
MQ本地消息事务表
风团团
05-27 1351
这个方案就是新增了一张本地消息表，记录消息发送失败的日志，且随当前业务事务一块提交。等到业务事务执行完毕后，在执行发送MQ逻辑，此时如果MQ发送失败了也不打紧，本地表兜着底呢，后面可以通过定时扫表的方式进行MQ消息的重新发送如果还不懂这套方案童鞋可以先去搞懂一下，再来阅读本文效果更佳事务方法失效场景。即必须通过代理对象进行的方法调用事务才会生效。声明式事务整个的代理对象是如何创建、事务运行的整套流程全面解读spring注解事务失效场景，伪代码+图文深度解析spring源码运行过程。
事务消息及本地消息事务表
zjc348的博客
03-06 3211
什么是MQ? 1.1 为什么要用MQ？ 1.2 场景一 1.3 场景二 事务消息 2.1 本地消息事务表 2.2 RocketMQ事务消息 1. 什么是MQ? MQ(Message Quene) : 翻译为 消息队列,通过典型的 生产者和消费者模型，生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入,轻松的实现系统间解耦。 别名为 消息中间件 通过利用高效可靠的消息传递机制进行平台无关的..
分布式事务消息中间最终一致性（本地方式、RocketMQ）
linhaibing009的博客
11-15 173
分布式事务——本地消息表和MQ消息事务
一蓑烟雨任平生
03-14 2457
本地消息表的方案最初由ebay的工程师提出，核心思想是将分布式事务拆分成本地事务进行处理。本地消息表实现最终一致性。
分布式事务之本地事务
Coder_ljw的博客
07-31 784
分布式事务之本地事务，undo log 记录更新前数据，用于保证事务原子性redo log 记录更新后数据，用于保证事务的持久性redo log 写入到buffer缓冲区，事务提交时写入磁盘redo log 持久化到了硬盘之后，事务可提交redo log会在事务提交之前，或者redo log buffer满了的时候写入磁盘数据写入到内存的redo log日志文件中，不过为了避免出现内存中与磁盘数据不一致的情况，事务提交后也会将内存数据刷入磁盘。
MQ的事务消息机制
04-27
<think>好的，我需要回答用户关于MQ事务消息的机制和实现方式的问题。首先，我需要回忆之前提供的引用内容，看看有哪些相关信息可以整合。 用户提到了RocketMQ的事务消息流程，所以我要重点参考引用中的内容。根据引用[1]，事务消息的流程分为几个步骤，包括发送半消息、执行本地事务、根据结果提交或回滚。引用[4]详细说明了三步流程，这可以作为结构的基础。 然后，机制方面需要解释如何保证事务的一致性。这里引用[2]提到分布式事务中MQ的作用，将大事务分解为小事务，结合两阶段提交（2PC）可能相关。不过RocketMQ的事务消息实现可能不是标准的2PC，而是类似但优化的机制。需要确认这一点，根据引用[3]和[4]，RocketMQ使用了半消息和事务状态回查的机制，确保本地事务和消息发送的一致性。 实现方式方面，引用[3]指出需要注册TransactionListener，并实现执行本地事务和回查的逻辑。Producer发送半消息后自动触发本地事务执行，Broker在未收到确认时会发起回查。这部分需要详细说明。 可能还需要比较其他MQ的事务消息实现，但用户可能主要关注RocketMQ，所以重点放在它上面。此外，要确保使用正确的LaTeX格式，如独立公式用$$，行内用$，比如在提到事务状态时可能有数学模型，但如果没有具体公式，可能不需要数学表达，但要注意用户的指令。 最后，生成相关问题时要涵盖机制、实现细节、与其他技术的对比、性能优化和实际应用等。需要检查引用是否覆盖了这些方面，并确保问题相关且合理。</think>### MQ事务消息机制与实现原理解析 #### 一、事务消息核心机制 MQ事务消息通过**两阶段提交思想**实现分布式事务一致性，核心目标是保证**本地事务执行与消息投递的原子性**。以RocketMQ为例，其机制包含以下关键步骤： 1. **半消息（Half Message）阶段** 生产者向Broker发送半消息（标记为`TRANSACTION_PREPARED`状态），此时消息对消费者不可见[^4]。半消息用于记录事务执行前的消息状态，类似数据库事务的预提交。 2. **本地事务执行** 生产者执行本地事务（如数据库操作），并根据结果向Broker发送**提交（COMMIT）**或**回滚（ROLLBACK）**指令。 若未收到明确指令，Broker会触发**事务状态回查（Transaction Check）**机制[^3]。 3. **事务状态确认** - 若本地事务成功，Broker将半消息转为普通消息（状态`COMMIT_MESSAGE`），消费者可消费 - 若本地事务失败或超时未确认，Broker删除半消息（状态`ROLLBACK_MESSAGE`）[^4] $$状态转换公式：TRANSACTION\_PREPARED \xrightarrow{COMMIT} COMMIT\_MESSAGE \quad \xrightarrow{ROLLBACK} \varnothing$$ #### 二、实现方式与关键技术 1. **事务监听器（TransactionListener）** 开发者需实现两个核心方法： - `executeLocalTransaction`：执行本地事务并返回执行状态 - `checkLocalTransaction`：处理Broker的事务回查请求[^3] ```java // RocketMQ事务消息生产者示例 TransactionMQProducer producer = new TransactionMQProducer("group"); producer.setTransactionListener(new TransactionListener() { @Override public LocalTransactionState executeLocalTransaction(Message msg, Object arg) { return doBusiness() ? LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE; } @Override public LocalTransactionState checkLocalTransaction(MessageExt msg) { return checkTransactionStatus(msg.getTransactionId()); } }); ``` 2. **事务回查机制** Broker通过定时任务扫描未完成事务，若超时未确认（默认60秒），则回调生产者的`checkLocalTransaction`方法[^4]。该机制解决了网络分区或生产者宕机导致的状态不一致问题。 3. **消息存储优化** - 半消息存储于特殊Topic（`RMQ_SYS_TRANS_HALF_TOPIC`） - 提交后转移至目标Topic，通过写时复制（Copy-On-Write）保证原子性[^1] #### 三、与其他方案的对比 | 方案 | 一致性保障 | 性能消耗 | 适用场景 | |---------------|------------|----------|----------------------| | MQ事务消息 | 最终一致 | 中等 | 跨服务异步事务 | | 2PC协议 | 强一致 | 高 | 同构数据库场景 | | TCC模式 | 最终一致 | 高 | 复杂业务补偿场景 | #### 四、典型应用场景 1. **订单支付场景** 用户支付成功后，异步通知库存系统扣减库存[^2] 2. **跨系统数据同步** 保证数据库操作与ES索引更新的最终一致性 3. **金融转账场景** 主账户扣款与子账户入账的异步解耦
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值