使用MQ来保证分布式事务的最终一致性

最新推荐文章于 2025-03-27 10:27:10 发布
最新推荐文章于 2025-03-27 10:27:10 发布
阅读量543 收藏 1
点赞数
本文探讨了微服务架构中如何通过消息队列(MQ)实现最终一致性，解决分布式事务问题。详细介绍了生产者与消费者逻辑流程，及保障消息投递与幂等性的关键措施。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

前言

之前我们讨论了如何拆分一个订单下单的一个服务（https://www.cnblogs.com/linkstar/p/9610268.html）
从单体到微服务的拆分，当时我们只是对原来的整个服务做了一个简单的拆分，但是在实际中肯定会遇到很多问题，所以我们这里解决一个最容易也是最有可能在实际中遇到的问题，事务。

在单体架构中，我们很容易去维护一个事务，我们想要对一个事务操作回滚也很容易，而在分离成微服务之后，我们想要在多个服务上去维护一个事务就比较困难了。这里我们不再讨论分步事务的实现，转而讨论一个我们常常听到的，最终一致性。

简单的说，很多在实际中的应用多数情况下，想要保证的是只要最后的最结果是对的，中间的过程可能几经周折都没有关系。

我们继续拿下单这个例子，想要保证的是，只要最后钱扣了，订单生产了，就对了。假设其中的一个服务挂了，可能经过不断的重试，最终等服务正常之后，结果还是对了，也就满意。针对这样的情况，我们称为“最终一致性”。（这里对于它不再过多解释）

使用MQ的原因

那么针对最终一致性为什么要使用mq呢？我想很多人也知道网上很多人在说mq实现最终一致性，但是从来没有仔细想想为什么要用mq。我列出这几个原因来供你参考：
1、mq可以解决http请求出现异常的时候带来的一系列问题
2、mq可以有多个消费者，完全契合微服务
3、mq本质是队列，在高并发下，可以保证你的数据正常
...

逻辑流程图



生产者的逻辑
1、订单入库
2、消息记录入库
3、发送消息（采用确认模式）
4、mq收到消息之后给生产端一个确认消息
5、生产端监听这个确认消息
6、根据监听结果操作消息表的状态
7、定时任务定时去操作消息状态为1未发送的记录，就是那些没有监听到结果的记录进行重新发送

消费者的逻辑
1、将收到消息的消息入库
2、处理消息失败消息记录的状态就为未处理
3、处理消息成功修改消息记录的状态为处理成功
4、收到相同的消息id的消息直接丢弃
5、定时任务去操作那些未处理，并且已经经过一段时间的消息
6、针对那些一直处理失败的，且很长一段时间都没办法处理成功的消息交由人工或者其他途径处理

需要注意的问题

1、消息的100%投递
首先我们需要保证的就是消息一定要投递出去，要是我们消息都不能保证投递成功，那么后面的逻辑就走不下去了。

2、我们需要保证幂等性（无论多少次操作，最后造成的结果和只执行一次造成的结果是一样的。）
消息肯定会出现重复投递的问题，这里应该由消费端去保证，重复的消息不能进行消费

而保证这两个问题的方式就藏在上面的逻辑流程图中，请仔细揣摩其中的用意。

代码实现

https://github.com/LinkinStars/MicroServiceExample/tree/distributed-transaction

参考博客

https://segmentfault.com/a/1190000012762869

具体其他细节这里讲的很清楚，这里不再赘述，针对分布式事务，一直都是一个难题，当前的解决方案有很多，适应不同的应用场景，所以需要根据实际项目使用场景来选取。

 

RocketMQ NameServer保障数据一致性分析
如切如磋，如琢如磨
12-11 2277
文章目录路由注册角度路由剔除路由发现 路由注册角度 路由剔除 路由发现
【103期】RabbitMQ 实现多系统间的分布式事务，保证数据一致性
2401_84048398的博客
04-05 635
光给面试题不给答案不是我的风格。这里面的面试题也只是凤毛麟角，还有答案的话会极大的增加文章的篇幅，减少文章的可读性光给面试题不给答案不是我的风格。这里面的面试题也只是凤毛麟角，还有答案的话会极大的增加文章的篇幅，减少文章的可读性。
使用RabbitMQ+延迟队列实现分布式事务的最终一致性方案
04-13
使用RabbitMQ+延迟队列实现分布式事务的最终一致性方案，demo以典型的订单+库存系统为例
RabbitMQ实现分布式事务(最终一致性)
AAA821的专栏
10-16 7567
转自：https://www.jianshu.com/p/eb7a36d25b2a rabbitmq的发送过程如下 发送消息到消息服务 消息队列将消息发送给监听 消息监听接受并处理消息 我们来看看可能发送异常的四种 1 直接无法到达消息服务 网络断了，抛出异常(将RabbitMq服务器关了，会直接报异常)，业务直接回滚即可。如果出现connenction error，直接增加 conn...
分布式事务解决方案-可靠消息最终一致性
wry的博客
06-20 652
分布式事务解决方案之可靠消息最终一致性 什么是可靠消息最终一致性事务 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能 够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图： 事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件 之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事 务问题。
3种使用MQ实现分布式事务的方式
温安适的专栏
12-10 2081
撸了今年阿里、头条和美团的面试，我有一个重要发现.......>>> 1.保证消息传递与一致性 1.1生产者确保消息自主性 当生产者发送一条消息时，它必须完成他的所有业务操作。 如下图： 这保证消费者接受到消息时，生产者已处理完毕相关业务，也就是1PC的基础。 1.2 MQ保存并转发消息 消息标记为持久化，MQ将会利用保存并转发机制，来履行它与发送者之间的契...
MQ如何保证分布式事务的最终一致性
mischen520的博客
10-19 3090
分布式事务：业务相关的多个操作，保证他们同时成功或者同时失败 最终一致性：与之对应的就是强一致性 MQ中要保证事务的最终一致性，就需要做到两点 1.生产者要保证100%的消息投递。事务消息机制 2.消费者这一端需要保证幂等消费。唯一ID+业务自己实现的幂等 分布式MQ的三种语义： at least once at most once exactly once:RocketMQ并不能保证exactly once。商业版本当中提供了exactly once的实现机制。 Kafka:在最新版本的源码当中，提供了e
MQ分布式环境下保持数据一致性
写代码的蜗牛
06-25 5261
业务场景: 支付宝的余额系统与蚂蚁金服的余额宝是两个对立的平台，相互之间通过ActiveMQ进行通信。当用户把1000块钱从余额存进余额宝的时候，余额系统数据库减1000，然后发送一个消息到MQ，余额宝端接收到这个消息后，在其数据库中加1000. 可能存在的问题： 1. 消息丢失问题。用户发起1000块钱的转账，支付宝余额平台减了1000，触发消息放到了队列，余额宝端成功消费了消息，但是...
分布式事务最终一致性mysql_分布式事务最终一致性方案案例
weixin_39858245的博客
02-05 439
前言：以下以网上课程购买流程举一个例子：如何实现两个分布式服务(订单服务、学习服务)共同完成一件事即订单支付成功自动添加学生选课的需求，这里的关键是如何保证两个分布式服务的事务的一致性。订单支付结果通知方法{1)更新支付表中支付状态为成功。2)远程调用选课接口添加记录(Feign调用)}​ 尝试解决上边的需求，在订单服务中远程调用选课接口，伪代码如下：1.更新支付表状态为本地数据库操作。2.远程调...
分布式事务,基于MQ实现最终一致性分布式事务
qq_41714882的博客
02-15 4033
什么是分布式事务 传统的事务是基于项目耦合并且是单数据库的本地事务，简单的来说，分布式事务就是实现跨服务器和数据库的事务支持 CAP 定理，又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)，CAP 就是你的入门理论。 C (一致性)：对某个指定的客户端来说，读操作能返回最新的写操作。 对于数据分布在不同节点上的数据来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数...
消息队列与分布式事务：探讨不同MQ如何实现可靠消息最终一致性
Apple_Boy的博客
08-17 1597
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。
基于本地消息表实现分布式事务保证最终一致性
我是臭鱼阿祥
12-27 1109
尤其是我们这个场景中，积分的增加其实不需要强一致性，只需要保证几秒钟之后积分增加成功就行，而且是一旦下单成功，积分增加必须成功，所以就比较适合使用可靠消息来保证最终一致性。在事务中写入本地业务数据+本地消息，然后在事务外发MQ消息，如果发送失败了，也不影响事务的commit如果发送成功了，把本地消息表的状态推进一下。这样我们就在一个事务中，创建两条数据库记录，因为加了事务，那么就可以保证，如果order创建成功，message也一定能写入成功。因为不是所有的MQ都支持事务消息，所以这里我们选择本地消息表。
分布式事务大揭秘：使用MQ实现最终一致性
孤芳不自赏
06-09 1048
大家好，我是小米，一个热爱分享技术的29岁程序员。今天我们来聊聊分布式事务中的经典实现方式——MQ最终一致性。通过阿里的RocketMQ，我们可以实现消息事务，确保在分布式系统中的数据一致性。本文将详细介绍其核心机制和实现步骤，希望对你有所帮助。
MQ消息最终一致性解决方案
放羊的砍柴人
06-27 887
随着分布式服务架构的流行与普及，原来在单体应用中执行的多个逻辑操作，现在被拆分成了多个服务之间的远程调用。虽然服务化为我们的系统带来了水平伸缩的能力，然而随之而来挑战就是分布式事务问题，多个服务之间使用自己单独维护的数据库，它们彼此之间不在同一个事务中，假如A执行成功了，B执行却失败了，而A的事务此时已经提交，无法回滚，那么最终就会导致两边数据不一致性的问题；尽管很早之前就有基于两阶段提交的XA分布式事务，但是这类方案因为需要资源的全局锁定，导致性能极差；因此后面就逐渐衍生出了消息最终一致性、TCC等柔性事
RocketMQ分布式事务 -＞ 最终一致性实现
卷王: 乌-鸦的博客
07-21 1032
分布式事务的问题常在业务与面试中被提及, 近日摸鱼看到这篇文章, 阐述的非常通俗易懂, 固持久化下来我博客中, 也以便于我二刷转载源基于RocketMQ分布式事务 - 完整示例本文代码不只是简单的demo，考虑到一些异常情况、幂等性消费和死信队列等情况，尽量向可靠业务场景靠拢。目前已经完成了订单服务的业务逻辑。我们总结流程如下：第一次调用createOrder，发送事务消息。如果发送失败，导致报错，则将异常返回，此时不会涉及到任何数据安全。
MQ 如何保证数据一致性？
03-27 798
上个月，我们有个电商系统出了个灵异事件：用户支付成功了，但订单状态死活不改成“已发货”。折腾了半天才定位到问题：订单服务的MQ消息，像人间蒸发一样消失了。这个Bug让我明白：（MQ）消息队列的数据一致性设计，绝对能排进分布式系统三大噩梦之一！今天这篇文章跟大家一起聊聊，MQ如何保证数据一致性？希望对你会有所帮助。最近准备面试的小伙伴，可以看一下这个宝藏网站（Java突击队）：www.susan.net.cn，里面：面试八股文、面试真题、工作内推什么都有。
RabbitMQ保证消息的一致性解决方案
热门推荐
AstarCloud
05-07 1万+
RabbitMQ保证消息的一致性 一、采用confirm消息确认机制及return返回机制 确保消息发送成功 二、将队列以及消息设置持久化 保证rabbitmq突然宕机消息仍然存在 三、手动确认接收消息方式 消息处理失败拒收重回队列 1. yml配置 spring: rabbitmq: host: 10.134.22.232 port: 5672 username: guest password: guest #采用confirm以及r
分布式事务的解决方案，mq消息队列如何保证数据一致性
weixin_45574792的博客
08-10 5468
分布式事务 用户在支付完成后会调用选课表添加学生选课记录。选课记录添加完成学习即可在线开始学习。 如果更新支付表成功，远程调用添加选课成功（选课数据库commit成功），最后更新支付表commit失败，此时出现操作不一致。 上边的问题涉及到分布式事务控制。 1、什么是分布式系统？ 部署在不同结点上的系统通过网络交互来完成协同工作的系统。 比如：充值加积分的业务，用户在充值系统向自己的账户充钱，在积分系统中自己积分相应的增加。充值系统和积分系统是两个不同的系统，一次充值加积分的业务就需要这两个系统协同工作来完
MQ如何解决分布式事务？
m0_54187478的博客
03-05 1077
MQ（消息队列）解决分布式事务的关键在于利用消息的可靠性和最终一致性来保证分布式系统中不同服务间事务的一致性。和。
分布式事务的最终一致性如何实现？
最新发布
07-06
<think>我们正在讨论分布式事务的最终一致性实现方法。根据引用[1]和[2]，实现最终一致性的常用方法是基于消息队列，核心包括事务消息、幂等消费和对账机制。此外，引用[3]提到有6种方案，但未具体列出，因此我们主要依据引用[1][2]展开。 最终一致性的核心思想：允许系统在某个时间段内存在不一致状态，但通过异步补偿机制最终达到一致。适用于对强一致性要求不高，但需要高可用性和分区容错性的场景。 实现步骤： 1. 事务消息：确保消息的可靠发送和事务的原子性。 2. 幂等消费：确保消息被多次消费不会导致数据不一致。 3. 对账兜底：通过定时核对数据，修复不一致。 下面详细说明： 一、事务消息（以RocketMQ为例，RabbitMQ可通过插件或本地事务表实现类似机制） - 事务消息流程： 1. 生产者发送半消息（预提交消息）到MQ。 2. MQ返回半消息发送成功。 3. 生产者执行本地事务。 4. 生产者根据本地事务结果提交或回滚消息（提交则消息可见，回滚则删除）。 5. 若生产者未确认，MQ会回查事务状态。 二、幂等消费 - 原因：网络重传、生产者重试、消费者重试可能导致消息重复。 - 实现方式： 1. 唯一键：在业务表中增加唯一键（如业务ID+类型），插入重复时忽略。 2. 状态机：业务状态机设计，确保状态转换幂等（如订单状态从“未支付”到“已支付”只能发生一次）。 3. 去重表：记录已处理消息的唯一标识（如消息ID），处理前先查表。 三、对账机制 - 定时任务：扫描业务数据，与关联系统核对（如支付系统与订单系统对账）。 - 修复：发现不一致时，触发补偿操作（如补单、退款等）。 四、数学模型（最终一致性的理论基础） - 最终一致性可用概率模型描述。设系统在时间t达到一致性的概率为P(t)，则： $$ \lim_{t \to \infty} P(t) = 1 $$ - 消息队列的可靠性：设消息发送成功率为p，则n次重试后失败的概率为$(1-p)^n$，当n足够大时，失败概率趋近于0。 五、代码示例（使用RabbitMQ和Python） 步骤1：发送事务消息（使用本地事务表确保消息发送与业务操作原子性） 步骤2：消费端实现幂等 示例代码框架： 1. 生产者（使用本地事务表）： ```python # 伪代码，实际需结合具体框架 def execute_transaction(): # 1. 开启本地事务 try: # 2. 执行本地业务操作（如更新数据库） db.update("UPDATE account SET balance = balance - 100 WHERE user_id = 1") # 3. 记录消息到本地事务表（与业务操作在同一个事务中） db.insert("INSERT INTO transaction_log (msg_id, content, status) VALUES ('123', 'transfer', 'pending')") # 提交事务 db.commit() except: db.rollback() # 异步任务：扫描事务表，发送消息 def send_message_from_log(): messages = db.query("SELECT * FROM transaction_log WHERE status='pending'") for msg in messages: # 发送消息到RabbitMQ channel.basic_publish(exchange='', routing_key='transfer_queue', body=msg.content) # 更新状态为已发送 db.update("UPDATE transaction_log SET status='sent' WHERE msg_id=?", (msg.msg_id,)) ``` 2. 消费者（幂等消费）： ```python # 使用唯一消息ID确保幂等 processed_messages = set() # 实际应使用持久化存储（如Redis或数据库） def callback(ch, method, properties, body): msg_id = properties.message_id if msg_id in processed_messages: ch.basic_ack(delivery_tag=method.delivery_tag) # 已处理，直接确认 return # 处理业务（如更新账户） try: # 业务操作（注意：这里也要保证业务操作的幂等性，例如通过唯一键） db.update("UPDATE account SET balance = balance + 100 WHERE user_id = 2") # 记录已处理消息 processed_messages.add(msg_id) # 实际应持久化到数据库或Redis ch.basic_ack(delivery_tag=method.delivery_tag) # 确认消息 except: ch.basic_nack(delivery_tag=method.delivery_tag) # 处理失败，重试 ``` 六、实际应用场景 1. 电商支付：支付成功后，异步更新订单状态。 2. 跨行转账：银行A扣款，银行B加款，通过消息队列异步通知。 七、学习资源推荐（根据引用[1][2][3]） - 引用[1]：详细介绍了RabbitMQ实现最终一致性。 - 引用[2]：基于消息队列的设计与实现，包含事务消息、幂等消费和对账。 - 引用[3]：提到有6种分布式事务方案，可进一步学习（如TCC、Saga等）。 注意：最终一致性方案不适用于所有场景，强一致性场景需考虑2PC等方案。 相关问题： 1. 如何设计消息队列的事务消息机制？ 2. 幂等消费的具体实现有哪些技术细节？ 3. 对账机制如何保证分布式系统的数据一致性？</think>## 分布式事务最终一致性实现方法 最终一致性是分布式系统中保证数据可靠性的核心方案，其核心思想是**允许系统在某个时间段内存在不一致状态，但通过异步补偿机制最终达到一致**。以下是主流实现方法： --- ### 一、基于消息队列的实现（最常用） #### 核心流程 ```mermaid graph LR A[服务A] -->|1. 本地事务+发消息| B[MQ] B -->|2. 投递消息| C[服务B] C -->|3. 消费消息+本地事务| D[达成一致] ``` #### 关键组件 1. **事务消息**（以RocketMQ为例）： - 半消息机制：先发送预备消息，本地事务提交后再确认 - 事务回查：MQ主动查询未确认消息的状态 ```java // RocketMQ事务消息示例 TransactionSendResult result = producer.sendMessageInTransaction(msg, (Message msg, Object arg) -> { // 执行本地事务 if (doLocalTransaction(arg)) return LocalTransactionState.COMMIT_MESSAGE; else return LocalTransactionState.ROLLBACK_MESSAGE; }, null); ``` 2. **幂等消费**： - 唯一ID：每条消息携带全局唯一ID（如UUID） - 消费记录表： ```sql CREATE TABLE consumed_messages ( msg_id VARCHAR(64) PRIMARY KEY, status TINYINT, created_at TIMESTAMP ); ``` 3. **对账兜底**： - 定时扫描业务数据 - 修复策略（补单/退款/日志告警） #### 数学保证 最终一致性可用概率模型描述： $$ P(\text{一致}) = 1 - (1-p)^n $$ 其中 $p$=单次消息投递成功率，$n$=重试次数。当 $n \to \infty$ 时 $P(\text{一致}) \to 1$[^1][^2] --- ### 二、TCC模式（Try-Confirm-Cancel） #### 三阶段操作： 1. **Try**：资源预留（如冻结余额） ```sql UPDATE account SET frozen = 100 WHERE id = 1; ``` 2. **Confirm**：确认执行（实际扣款） 3. **Cancel**：回滚预留（释放冻结） #### 适用场景： - 资金交易等高敏感业务 - 需要强一致性保证的场景 --- ### 三、Saga事务模式 #### 执行方式： ```mermaid sequenceDiagram participant A as 服务A participant B as 服务B A->>B: 执行操作1 B-->>A: 成功 A->>B: 执行操作2 B->>A: 失败 A->>B: 触发操作1补偿 ``` #### 特点： - 每个操作需提供补偿接口 - 适合长事务（分钟级） - 实现复杂度低于TCC --- ### 四、本地消息表（经典方案） #### 实现步骤： 1. 业务与消息在同一个本地事务中提交 ```sql BEGIN; UPDATE orders SET status='paid'; INSERT INTO msg_table(msg_id,content); COMMIT; ``` 2. 独立进程轮询消息表并投递MQ 3. 下游服务消费并确认 --- ### 五、方案选型对比 | 方案 | 一致性强度 | 复杂度 | 适用场景 | |--------------|------------|--------|-------------------------| | 消息队列 | ★★☆ | ★★☆ | 通用场景（80%案例）[^2] | | TCC | ★★★ | ★★★ | 金融/资金交易 | | Saga | ★★☆ | ★★☆ | 跨系统长事务 | | 本地消息表 | ★★☆ | ★★☆ | 数据库无事务消息支持时 | > 实际应用中常组合使用，如：消息队列 + TCC 关键步骤 --- ### 六、最佳实践建议 1. **消息可靠性**： - 开启MQ持久化 - 设置合理重试次数（建议3-5次） 2. **监控关键指标**： ```math \text{不一致率} = \frac{\text{对账异常数}}{\text{总事务数}} \times 100\% ``` 3. **补偿策略**： - 自动补偿：程序自动修复 - 人工介入：超过阈值告警 > 据阿里云MVP玄剑的实践，电商系统通过消息队列+日对账可将不一致率控制在0.001%以下[^3]。 --- **相关问题**： 1. 如何设计高可靠的幂等消费机制？ 2. TCC模式中资源预留的常见实现方式有哪些？ 3. 分布式事务中对账系统的具体实现方案？ 4. 如何评估不同最终一致性方案的性能瓶颈？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值