分布式事务 本地消息表

最新推荐文章于 2025-09-13 15:58:14 发布
原创 最新推荐文章于 2025-09-13 15:58:14 发布 · 370 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

  1. 主要依赖本地的消息表来保证数据的一致性
  2. 例如  系统A和系统B需要同步修改数据        
  • 系统A增加本地消息表、系统B也增加本地消息表
  • 在A系统的本地事务中，需要处理A系统处理逻辑 与 A系统消息表插入一条消息数据
  • 接着 A 系统将这个消息发送到 MQ 中去；
  • B系统则消费这个MQ消息，在本地事务中处理B系统的逻辑，以及插入B系统的消息表一条数据
  • B系统处理成功之后，则更新B系统的消息表状态，和A系统的消息表状态
  • B系统处理失败，就不会更新A系统的消息表状态，则通过定时任务扫描A系统的消息表状态，来重新发送MQ消息。
  • 如果B系统一直处理失败，则A会一直发送MQ消息，以确保一定要成功
分布式事务 - 本地消息表
Eddie'Blog
02-06 349
文章目录分布式事务本地消息准备工作原理本地消息表数据库设计支付接口订单接口定时任务测试流程 分布式事务 本地消息 本节主要记录订单号，订单状态，重试次数。 准备工作 使用的基础代码 原理 采用BASE原理, 保证事务最终一致 允许部分成功、部分失败 在一致性方面，允许一段时间内的不一致，但最终会一致 在实际的系统当中，要根据具体情况，判断是否采用 基于本地消息表的方案中，将本事务外操作，记录在消息表中 例子：在电商平台中, 订单和支付两个产生两个事务，订单是在自己系统当中, 而支付是在第三方平
分布式事务：本地消息表
Quan
06-23 1140
本地消息表是一种基于数据库的分布式事务解决方案，通过将分布式事务拆分为本地事务和消息事件来实现最终一致性。其核心流程包括：事务发起方完成本地业务操作并存储消息到数据库；定时任务扫描并发送未处理消息；接收方处理消息后发送确认。该方案优点包括简化编程模型、提高系统吞吐量、保证可靠性，但存在实时性不高、开发成本较高等缺点。适用于电商订单、资金转账等对最终一致性要求高但对实时性要求不高的场景，实现时需考虑消息表设计、幂等处理及异常重试机制。
从 0 到 1 吃透 Java 分布式事务：Seata/TCC/ 本地消息表的终极选型指南
最新发布
果酱 の 博客
09-13 912
分布式事务解决方案对比：本地消息表、TCC模式与Seata 本文深入分析了三种主流分布式事务解决方案的特点和适用场景： 本地消息表 特点：基于最终一致性原理，通过消息队列实现 优点：实现简单、可靠性高、兼容性好 缺点：强依赖消息队列、数据库负担重 适用场景：电商下单、物流跟踪等异步流程 TCC模式 特点：Try-Confirm-Cancel三阶段事务 优点：性能高、灵活性好、一致性保证强 缺点：开发成本高、业务侵入性强
本地消息表实现分布式事务—可靠消息最终一致性解决方案
刘皇叔说Java的博客
12-23 2700
本地消息表：这是ebay研发出的一种分布式事务解决方案，通过将消息表存储在数据库中，实现了消息的一致性。它的核心思想就将分布式事务拆分成本地事务进行处理本地消息表是利用各系统本地事务来实现分布式事务。业务系统的执行和消息均放入本地消息表中,确保本地业务执行和消息表的操作在一个事务中。不尝机制重试读取本地消息表,调用远程应用操作。需要加入重试机制、最大执行次数、报警机制。本地消息表容忍数据暂时不一致，期望数据的最终一致性。
分布式事务之本地消息表
weixin_34327223的博客
12-15 3117
什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 为什么我们要反反复复的强调一致性？ 因为，一致性就...
分布式事务——本地消息表和MQ消息事务
一蓑烟雨任平生
03-14 2451
本地消息表的方案最初由ebay的工程师提出，核心思想是将分布式事务拆分成本地事务进行处理。本地消息表实现最终一致性。
基于本地事务表+MQ实现分布式事务
jike11231的博客
01-24 1825
分布式事务解决方案有许多比如二阶段提交、TCC、最大努力通知、Saga事务等，本文介绍本地消息表+MQ这种方式解决分布式事务消息最总一致性问题。目前利用本地消息表+MQ方案实现最终消息一致性的比较多，它的核心思想是，将分布式事务拆分成本地事务进行处理，不同事务之间通过消息表和MQ通信，最后通过定时任务扫描失败的数据进行重试，当在有效重试次数限制内，再次重试回调失败的数据，最终实现消息重复发送，达到一致性。本地消息表实现最终一致性。将rocketmq-dashboard导入到idea中，在idea编译启动。
本地消息表的分布式事务解决方案Demo
工作随记
12-28 969
本地消息表的分布式事务解决方案是一种基于可靠消息最终一致性的方案，它利用了本地数据库事务和消息队列的特性，来保证分布式系统中的数据一致性。
分布式事务之本地消息表实践
Lamb_IT的博客
09-22 1400
分布式系统之前除了同步方式通过RPC框架调用接口，还有很多通讯是异步的方式通过MQ中间件完成的。本文主要介绍后者实现分布式事务的一种方案，核心思想是通过记录本地消息日志表的方式，借助本地事务和MQ消息中间件的可靠性来实现分布式系统中多个节点间状态的最终一致。
分布式事务-本地消息表
07-15 3020
需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。
分布式事务-本地消息表（异步确保）
lujiangui的专栏
10-04 905
本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路来源于eBay 工作流程： 1、消息生产方，需要额外一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交。也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重新发送。 2、消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务
分布式事物--本地消息表
东境物语
05-27 3877
本地消息表 这种实现方式的思路，其实是源于 ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅，借助关系型数据库中的表即可实现。 举个经典的跨行转账的例子来描述。 第一步伪代码如下，扣款 1W，通过本地事务保证了凭证消息插入到消息表中。 第二步，通知对方银行账户上加 1W 了。那问题来了，如何通知到对...
使用消息表解决分布式事务
test1444509256的博客
03-23 3034
场景如下：订单系统收到第三方支付平台支付成功的通知后，需要进行1：更新订单的状态为已支付  2：扣减商品库存订单库：订单表order：orderID、userID、status商品库：商品库存表productStock：productStockID、productID、stock出库单outStockBill：outStockBillID、orderID、stock正常流程为：支付成功后根据ord...
分布式事务解决方案之本地消息表
岁月静好
09-27 4722
描述分布式事务之前，先了解下事务是什么。事务就是一组操作构成的可靠的独立的工作单元，要么全部执行成功，要么全部执行失败。分布式就是一个业务由多个操作完成，这些操作又分布在不同的服务器上。简单来说，分布式事务就是分布式系统中的事务。本文描述了本地消息表如何解决分布式事务的关键流程，在具体业务操作时候，可能还有会一些问题，比如消息发送失败、下游业务处理失败等问题，这些都需要具体问题具体分析。在遇到分布式一致性问题的时候，结合实际的业务情况选择最适合的分布式事务解决方案。
mysql分布式事务本地消息,分布式事务-本地消息表
weixin_30571837的博客
03-23 537
本地消息表(经典的ebay模式)该方案的核心思想在于分布式系统在处理任务时通过消息日志的方式来异步执行。消息日志可以存储至本地文本、数据库或消息队列，然后再通过业务规则定时任务或人工自动重试。以在线支付系统的跨行转账为例：第一步第一步，伪代码如下，对用户id为A的账户扣款1000元，通过本地事务将事务消息(包括本地事务id、支付账户、收款账户、金额、状态等)插入至消息表：Begin transac...
分布式事务之《本地消息表》解决方案
weixin_50055999的博客
07-22 1061
本文介绍了基于本地消息表的分布式事务解决方案。该方案通过将业务操作与消息记录在同一个本地事务中实现原子性，利用定时任务异步派发消息保证最终一致性。系统包含订单表、消息表、库存表等核心表结构，通过订单服务创建订单并记录消息，定时任务扫描未处理消息并调用库存服务进行处理，库存服务通过消息ID实现幂等控制。方案优点在于实现简单、高性能和解耦服务，适合对强一致性要求不高的场景（如电商订单）。文章详细说明了业务流程、代码实现和常见问题处理，并指出该方案能有效保证分布式系统的可靠性与可控一致性。
基于本地消息的分布式事务
chengxuan7399的博客
08-03 321
如果消息中间件没有提供事务消息，如何保证分布式事务？ 本地消息表(经典的ebay模式) 核心思想在于分布式系统在处理任务时通过消息日志的方式来异步执行。消息日志可以存储在本地文件，数据库。然后在通过业务规则定时任务或者人工重试。 解决方案： 1.Producer端准备一张消息表，...
分布式事务-本地消息表实现方案
shine0312的专栏
02-27 4293
一、背景 用单下单的时候需要先锁库存，然后再生成订单，库存所在的库和订单是两个库，这里就涉及到了分布式事务的处理，下面说下两种解决方案吧 二、方案 1、定时任务+本地消息表 这种方案还有一个优化点就是： 可以去掉消息的定时任务，然后就是在生成订单的事务中如果失败，那么就再开启一个事务（事务中会强制走主库查询）查询下该订单是否存在，如果存在就正常进行流程，如果不存在那么就直接设置消息的...
分布式事务 本地消息
03-26
### 分布式事务中本地消息表的最佳实践及实现方案 #### 1. 核心概念 分布式事务的核心目标是在多节点或多服务之间保持数据一致性和系统稳定性。通过引入本地消息表的方式，可以有效解决跨数据库或资源操作中的强一致性问题[^2]。 #### 2. 设计原理 本地消息表的设计主要围绕以下几个方面展开： - **本地事务保障**：将业务逻辑与消息发送封装在同一本地事务中。只有当本地事务提交成功时，才会记录消息到本地消息表中。 - **异步处理**：通过定时任务或消息队列消费本地消息表中的待发消息，将其传递给下游服务。 - **幂等性支持**：确保接收方对接收到的消息具有幂等能力，即使多次接收到相同消息也不会影响最终状态[^3]。 #### 3. 技术实现细节 以下是基于本地消息表实现分布式事务的具体技术要点： ##### (1) 数据库结构设计 在订单服务的数据库中新增一张 `local_message` 表用于存储待发送的消息。该表通常包含以下字段： | 字段名 | 类型 | 描述 | |----------------|------------|--------------------------| | id | BIGINT | 主键 | | biz_id | VARCHAR | 业务唯一标识 | | status | TINYINT | 消息状态 | | payload | TEXT | 待发送的实际消息内容 | | create_time | DATETIME | 创建时间 | | update_time | DATETIME | 更新时间 | 其中，`status` 的取值可定义如下： - 0: 初始状态（未发送） - 1: 发送中 - 2: 成功 - 3: 失败并等待重试 ##### (2) 流程描述 流程分为两个阶段完成： - **写入本地消息表**：在创建订单的同时，向 `local_message` 表插入一条初始状态为“未发送”的消息记录。此过程由同一个本地事务管理，确保要么两者都成功，要么都不发生。 - **消息投递**：启动独立线程池或者调度器定期扫描 `local_message` 表中处于“未发送”状态的消息，并尝试将其推送到目标服务。推送完成后更新对应记录的状态为“成功”。如果失败，则标记为“失败并等待重试”，并通过指数退避策略或其他方式进行后续重试[^1]。 ##### (3) 幂等性控制 由于网络波动等原因可能导致重复消息被消费者端接受，在这种情况下需要依赖于全局唯一的 `biz_id` 来判断当前请求是否已经处理过。例如库存扣减接口可以根据传入参数构建缓存key，查询Redis确认是否存在；若存在则直接返回成功响应而不做实际修改操作。 ```python def process_order(order_payload): order_id = generate_unique_order_id() try: with db.transaction(): save_order_to_db(order_payload, order_id) insert_local_message(order_id=order_id, payload=json.dumps(order_payload)) except Exception as e: handle_exception(e) def send_messages(): while True: messages = fetch_unsent_messages_from_table(limit=100) for msg in messages: if deliver_message(msg.payload): mark_as_sent(msg.id) else: schedule_for_retry(msg.id) time.sleep(5) # 控制轮询频率 ``` #### 4. 注意事项 - 需要合理设置超时时间和最大重试次数以防止无限循环消耗资源。 - 对高并发场景下的性能瓶颈进行优化，比如分片读取消息、批量提交等措施提升吞吐量。 - 定期清理已完成的历史消息以免占用过多磁盘空间。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值