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

最新推荐文章于 2025-03-27 10:27:10 发布
转载 最新推荐文章于 2025-03-27 10:27:10 发布 · 1.4k 阅读 · 3 ·
CC 4.0 BY-SA版权
原文链接：https://www.bbsmax.com/A/obzbM9QVdE/
文章标签：

#分布式事务

本文阐述了通过消息队列(MQ)确保分布式事务最终一致性的方法。详细介绍了生产者和消费者的逻辑流程，包括消息的投递确认、消息状态更新及定时重发机制，以及如何处理消息幂等性和重复投递问题。

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

使用MQ来保证分布式事务的最终一致性
参考URL：https://www.bbsmax.com/A/obzbM9QVdE/

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

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

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

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

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

分布式事务解决方案-可靠消息最终一致性
wry的博客
06-20 687
分布式事务解决方案之可靠消息最终一致性 什么是可靠消息最终一致性事务 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能 够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图： 事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件 之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事 务问题。
分布式事务的解决方案，mq消息队列如何保证数据一致性
weixin_45574792的博客
08-10 5534
分布式事务 用户在支付完成后会调用选课表添加学生选课记录。选课记录添加完成学习即可在线开始学习。 如果更新支付表成功，远程调用添加选课成功（选课数据库commit成功），最后更新支付表commit失败，此时出现操作不一致。 上边的问题涉及到分布式事务控制。 1、什么是分布式系统？ 部署在不同结点上的系统通过网络交互来完成协同工作的系统。 比如：充值加积分的业务，用户在充值系统向自己的账户充钱，在积分系统中自己积分相应的增加。充值系统和积分系统是两个不同的系统，一次充值加积分的业务就需要这两个系统协同工作来完
Rabbitmq实现多系统间的分布式事务，保证数据一致性
STIll_ly的博客
01-30 3763
Rabbitmq实现多系统间的分布式事务，保证数据一致性一、实验环境二、实验目的三、实验方案四、实验步骤1、消息队列2、数据库准备2.1订单表2.2 消息发送状态表2.3 运单表3、订单中心3.1 订单中心分析3.2 编写代码3.2.1 Springboot整合rabbitmq和mysql数据库3.2.1.1依赖如下：3.2.1.2配置文件内容：3.2.2 订单中心代码3.3 订单中心测试3.3....
MQ如何保证分布式事务的最终一致性
mischen520的博客
10-19 3105
分布式事务：业务相关的多个操作，保证他们同时成功或者同时失败 最终一致性：与之对应的就是强一致性 MQ中要保证事务的最终一致性，就需要做到两点 1.生产者要保证100%的消息投递。事务消息机制 2.消费者这一端需要保证幂等消费。唯一ID+业务自己实现的幂等 分布式MQ的三种语义： at least once at most once exactly once:RocketMQ并不能保证exactly once。商业版本当中提供了exactly once的实现机制。 Kafka:在最新版本的源码当中，提供了e
我说分布式事务之消息最终一致性事务（一）：原理及实现
程序猿DD
01-08 2337
来源：https://0x9.me/YgaUc在之前的文章中，我们已经学习总结了分布式事务的两种解决方案。我说分布式事务之TCC我说分布式事务之最大努力通知型事务本文我们...
分布式事务最终一致性mysql_分布式事务最终一致性方案案例
weixin_39858245的博客
02-05 471
前言：以下以网上课程购买流程举一个例子：如何实现两个分布式服务(订单服务、学习服务)共同完成一件事即订单支付成功自动添加学生选课的需求，这里的关键是如何保证两个分布式服务的事务的一致性。订单支付结果通知方法{1)更新支付表中支付状态为成功。2)远程调用选课接口添加记录(Feign调用)}​ 尝试解决上边的需求，在订单服务中远程调用选课接口，伪代码如下：1.更新支付表状态为本地数据库操作。2.远程调...
分布式事务,基于MQ实现最终一致性分布式事务
qq_41714882的博客
02-15 4061
什么是分布式事务 传统的事务是基于项目耦合并且是单数据库的本地事务，简单的来说，分布式事务就是实现跨服务器和数据库的事务支持 CAP 定理，又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)，CAP 就是你的入门理论。 C (一致性)：对某个指定的客户端来说，读操作能返回最新的写操作。 对于数据分布在不同节点上的数据来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数...
消息队列与分布式事务：探讨不同MQ如何实现可靠消息最终一致性
Apple_Boy的博客
08-17 1732
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。
基于本地消息表实现分布式事务保证最终一致性
我是臭鱼阿祥
12-27 1188
尤其是我们这个场景中，积分的增加其实不需要强一致性，只需要保证几秒钟之后积分增加成功就行，而且是一旦下单成功，积分增加必须成功，所以就比较适合使用可靠消息来保证最终一致性。在事务中写入本地业务数据+本地消息，然后在事务外发MQ消息，如果发送失败了，也不影响事务的commit如果发送成功了，把本地消息表的状态推进一下。这样我们就在一个事务中，创建两条数据库记录，因为加了事务，那么就可以保证，如果order创建成功，message也一定能写入成功。因为不是所有的MQ都支持事务消息，所以这里我们选择本地消息表。
分布式事务实现方案——MQ最终一致性（RocketMQ）
qq_35599414的博客
11-26 5262
什么是可靠消息最终一致性事务 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能 够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图： 事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件 之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事 务问题。 因此可靠消息...
MQ 如何保证数据一致性？
03-27 875
上个月，我们有个电商系统出了个灵异事件：用户支付成功了，但订单状态死活不改成“已发货”。折腾了半天才定位到问题：订单服务的MQ消息，像人间蒸发一样消失了。这个Bug让我明白：（MQ）消息队列的数据一致性设计，绝对能排进分布式系统三大噩梦之一！今天这篇文章跟大家一起聊聊，MQ如何保证数据一致性？希望对你会有所帮助。最近准备面试的小伙伴，可以看一下这个宝藏网站（Java突击队）：www.susan.net.cn，里面：面试八股文、面试真题、工作内推什么都有。
3种使用MQ实现分布式事务的方式
温安适的专栏
12-10 2114
撸了今年阿里、头条和美团的面试，我有一个重要发现.......>>> 1.保证消息传递与一致性 1.1生产者确保消息自主性 当生产者发送一条消息时，它必须完成他的所有业务操作。 如下图： 这保证消费者接受到消息时，生产者已处理完毕相关业务，也就是1PC的基础。 1.2 MQ保存并转发消息 消息标记为持久化，MQ将会利用保存并转发机制，来履行它与发送者之间的契...
分布式事务，通过MQ保持事务一致性
John_desheng的博客
06-03 314
A（存在DB操作）、B（存在DB操作）两方需要保证分布式事务一致性，通过引入中间层MQ，A和MQ保持事务一致性（异常情况下通过MQ反查A接口实现check），B和MQ保证事务一致（通过重试），从而达到最终事务一致性。 作者：彦帧 链接：https://www.jianshu.com/p/2838890f3284 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 ...
rabbitmq 怎么保证幂等性，数据一致性问题
shrek11的专栏
10-14 8462
mq的作用主要是用来解耦，削峰，异步， 增加MQ,系统的复杂性也会增加很多， 也会带来其他的问题，比如MQ挂了怎么办，怎么保持数据的幂等性 幂等性问题通俗点讲就是保证数据不被重复消费，同时数据也不能少， 也就是数据一致性问题。 下面是MQ丢失的3种情况 1，生产者发送消息至MQ的数据丢失 解决方法:在生产者端开启comfirm 确认模式，你每次写的消息都会分配一个唯一的 id， ...
SpringBoot中使用RocketMQ实现事务消息来保证分布式事务的一致性(有代码)
qq_21561833的博客
05-09 1739
分布式事务是分布式系统中非常常见的问题。是非常必要钱常见的。实现的方式也是多种多样。今天这个视频主要来分享一下RocketMQ实现事务消息来保证分布式事务的一致性。不知道大家使用过这种方式没有。这种分布式事务的原理其实和本地消息表一样。
分布式事务 - RocketMQ 实现事务的最终一致
小水牛的博客
01-18 742
RocketMQ实现事务的最终一致
MQ最终一致性理论与实践
qq_41124175的博客
02-20 1612
分布式事务无论是2PC&3PC还是TCC，基本都遵守XA协议的思想，但全局事务方案并发性较差；最终一致性方案指的是将最有可能出错的业务以本地事务的方式完成后，采用不断重试的方式（不限于消息系统）来促使同一个分布式事务中的其他关联业务全部完成，不遵从XA协议。
系统设计 | 数据库事务与 MQ 发送一致性
雨下一整晚real的博客
09-02 2911
实际上在 producer.sendMessage 执行的时候，消息并没有通过网络发送出去，而仅仅是往业务 DB 同一个实例上的消息库插入一条记录，然后注册事务的回调。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。在 DDD 架构中，要实现领域事件驱动优化，需要将不同的领域消息进行抽象，使用 MQ 消息来进行事件驱动，完成事件的最终一致性。以 MySQL 为例，在同一实例中的不同 db ，如果共享同一个 Connection 的话，是可以在同一个事务中的。
MQ分布式环境下保持数据一致性
写代码的蜗牛
06-25 5294
业务场景: 支付宝的余额系统与蚂蚁金服的余额宝是两个对立的平台，相互之间通过ActiveMQ进行通信。当用户把1000块钱从余额存进余额宝的时候，余额系统数据库减1000，然后发送一个消息到MQ，余额宝端接收到这个消息后，在其数据库中加1000. 可能存在的问题： 1. 消息丢失问题。用户发起1000块钱的转账，支付宝余额平台减了1000，触发消息放到了队列，余额宝端成功消费了消息，但是...
分布式事务的最终一致性如何实现？
最新发布
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、付费专栏及课程。

余额充值