分布式事务解决方案—本地消息表

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

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

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

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

核心思想

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

流程步骤

1. 本地事务与消息记录

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

1. 异步消息发送

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

1. 消息消费与处理

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

1. 补偿与对账机制（可选）

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

实战详细设计示例：

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

（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字段加索引，提升轮询效率。

关键问题与解决方案

1. 消息重复消费

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

1. 消息丢失

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

1. 数据库性能

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

1. 事务延迟

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

适用场景

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

优缺点对比

与其他方案对比

• TCC模式：需业务层实现Try/Confirm/Cancel接口，适合强一致性但实现复杂。
• Saga模式：通过事件链驱动事务，适合长流程业务，但需设计正向/逆向操作。
• 2PC：阻塞性强，性能低，适用于传统数据库集群。

总结

本地消息表方案通过结合本地事务与异步消息，在保证可靠性的同时实现系统解耦，是分布式事务中平衡复杂度与一致性的优选方案。实际应用中需结合业务场景，合理设计消息表结构、重试策略及补偿机制，以确保系统的最终一致性和高可用性。

（1）本地消息表通过在数据库中维护一张专门的消息表来管理与外部系统的交互状态更新，由于消息表的写入是与业务操作同在一个本地事务中完成的，天然具有同时成功和同时失败的特性。

（2）本地消息表机制是一种最大努力通知思想，在分布式服务中，虽然不能提供强一致性，但通过本地事务与消息表相结合，可以确保消息不会丢失，并最终实现事务的一致性。

（3）本地消息表机制的优点：

（a）实现简单：基于数据库的事务机制和消息队列，不需要引入复杂的分布式事务框架，降低了开发和维护的难度。

（b）数据一致性保障：通过本地消息表和消息队列的结合，确保了在分布式环境下，即使部分服务出现故障，也能通过消息的重发等机制保证数据的最终一致性。

（c）兼容性好：可以与各种不同的技术栈和系统进行集成，适用于多种业务场景

（4）本地消息表机制的缺点：

（a）消息表维护成本：需要额外维护本地消息表，包括消息的插入、更新和删除等操作，增加了数据库的负担和数据管理的复杂性。

（b）依赖消息队列：系统的可靠性依赖于消息队列的稳定性和可靠性，如果消息队列出现故障，可能会导致消息丢失或处理延迟，影响分布式事务的正常执行。

（c）性能问题：在高并发场景下，消息的发送和消费可能会成为性能瓶颈，需要对消息队列和相关服务进行优化。