分布式事务解决方案—本地消息表-CSDN博客

本文链接：https://blog.csdn.net/jakeswang/article/details/147305140

在微服务环境下，分布式事务是我们开发中经常的遇到的问题，下面我们来聊聊如何使用本地消息表机制来解决分布式事务的问题。

本地消息表是Base理论的应用，核心思路就是将分布式事务拆解为本地事务和发送MQ消息来实现分布式系统下数据的最终一致性的方案。

本地消息表方案适用于对数据一致性要求较高、可容忍一定的数据一致性延迟、业务场景相对简单的分布式系统。所以在实际应用中，需要根据具体的业务需求和系统架构特点，合理选择解决分布式事务的方案。

分布式事务中的本地消息表方案及异步任务消息表是一种基于最终一致性的解决方案，适用于需要跨服务协调且允许短暂延迟的场景。以下是该方案的详细解析：

核心思想

将分布式事务拆分为本地事务和消息处理，利用本地数据库事务保证业务操作与消息存储的原子性，通过异步任务和消息队列确保消息可靠传递，最终实现各服务的数据一致性。

流程步骤

本地事务与消息记录

- 服务A执行业务操作时，在同一个数据库事务中插入业务数据及消息到本地消息表。
- 关键点：利用数据库事务保证业务操作与消息记录的原子性（同成功或同失败）。

异步消息发送

- 定时任务（如Quartz）或独立服务轮询消息表，将状态为“待发送”的消息投递到消息队列（如Kafka/RocketMQ）。
- 投递成功后更新消息状态为“已发送”，失败则重试（需设置最大重试次数）。

消息消费与处理

- 服务B订阅消息队列，消费消息后执行业务逻辑。
- 处理成功：返回ACK确认，并可选回调服务A更新消息状态为“已完成”。
- 处理失败：消息队列重试（需消费者实现幂等性）或标记为“失败”进入人工干预流程。

补偿与对账机制（可选）

- 定时检查长时间未完成的消息，触发补偿流程（如回滚业务或重试）。
- 对账系统定期比对服务间数据，修复不一致状态。

实战详细设计示例：

本地消息表方案是分布式服务中最常用的数据一致性解决方案之一，如下是本地消息表的实现流程图：

（1）系统A首先写入实际的业务，同时将通知消息保存到专门的消息表中，因为消息表和业务表在一个库中，可以保证事务的同时生效，即在同一个事务中执行业务操作并将消息写入消息表中（消息表字段设计为主键id、消息内容、目标系统和当前消息的状态、创建时间、更新时间）；当事务提交后，业务数据和消息记录（消息的状态为待发送）都会被持久化到数据库。

（2）系统A发送消息给消息中间件（如RocketMQ），并且要获取到消息发送成功的响应。

（3）MQ消息发送成功后，修改系统A对应的数据库中消息表的状态（如记录状态为消息发送成功）。

（4）定时任务定期查询消息表中消息记录的状态为待发送的数据，然后做补偿消息的操作，即重新发送消息到消息队列中。

（5）系统B监听消息，然后消费队列中的消息数据做自己的业务，这里系统B收到消息之后需要确保幂等性操作，因为消息可能会被重复处理。

消息表设计

CREATE TABLE local_message (
    id BIGINT PRIMARY KEY COMMENT '唯一ID',
    biz_type VARCHAR(50) NOT NULL COMMENT '业务类型（如订单创建）',
    content TEXT NOT NULL COMMENT '消息内容（JSON格式）',
    status ENUM('pending', 'sent', 'completed', 'failed') DEFAULT 'pending' COMMENT '状态',
    retry_count INT DEFAULT 0 COMMENT '重试次数',
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL
);

索引优化：对status和created_at字段加索引，提升轮询效率。

关键问题与解决方案

消息重复消费

- 消费者幂等性：通过唯一ID（如业务主键）或数据库唯一约束避免重复处理。
- 例如：扣减库存时检查订单ID是否已记录。

消息丢失

- 可靠投递：消息队列需支持持久化；生产者确认机制（如MQ的ACK）。
- 重试机制：定时任务重新扫描“发送失败”的消息，限制最大重试次数。

数据库性能

- 读写分离：消息表单独部署或在主库中通过索引优化查询。
- 分库分表：按业务类型或时间分片，减少单表压力。

事务延迟

- 缩短轮询间隔：如从分钟级调整为秒级（需权衡数据库负载）。
- 实时触发：业务提交后立即触发一次消息发送，而非等待定时任务。

适用场景

最终一致性允许：如电商下单（订单创建后异步扣库存）、支付成功通知等。
跨服务调用：服务间解耦，通过消息通信而非强一致性协议（如2PC）。
中低并发量：高频写入场景需优化消息表性能（如分库分表）。

优缺点对比

优点	缺点
实现简单，依赖数据库事务	消息表与业务库耦合，可能影响性能
无需额外中间件（如Seata）	不适合实时性要求高的场景
天然支持重试与补偿机制	消费者需实现幂等性，增加复杂度