技术复盘-分布式事务

分布式事务是随着系统架构复杂化，尤其是微服务架构普及后，为保证跨数据库、跨服务数据一致性的关键技术。以下从事务基础概念出发，逐步深入分布式事务的核心内容。

一、事务基础

事务是一组不可分割的操作集合，具备“要么全做，要么全不做”的特性，其核心特性为ACID：

• 原子性（Atomicity）：事务整体执行，操作要么全执行，要么全不执行。
• 一致性（Consistency）：事务使数据库从一个一致状态转变为另一个一致状态，中间状态不可见。
• 隔离性（Isolation）：并发事务间互不影响，执行效果如同串行。
• 持久性（Durability）：事务提交后，修改永久保存，不可逆转。

二、本地事务

本地事务主要涉及单数据库或多数据库场景下的数据一致性保障。

以游戏交易系统为例，玩家用金币购买道具，流程包括扣除金币和添加道具。若两表在同一数据库，单数据库事务可轻松保证一致性：

• 执行SQL扣除金币或添加道具时异常，回滚事务。
• 提交事务时异常，同样回滚事务。

玩家数量激增时，金币表与道具表分库存储。此时单数据库事务无法保证一致性，可采用后置提交事务策略：

• 先在两数据库执行SQL，最后统一提交。
• 执行SQL异常时，回滚对应数据库事务。
• 提交事务异常时，若一个事务已提交，另一个无法回滚，会导致数据不一致。

三、分布式事务

微服务架构下，业务流程常跨多个子系统，需分布式事务保证跨数据库操作一致性。分布式事务主要关注强一致性和最终一致性解决方案，典型方案包括两阶段提交、消息事务+最终一致性、TCC补偿模式。

XA协议由Tuxedo提出，含事务管理器和本地资源管理器。本地资源管理器由数据库实现，事务管理器负责全局调度。

• 原理：

  准备阶段：事务管理器向各资源管理器发送准备请求，资源管理器执行操作并反馈结果。

  提交阶段：若所有资源管理器准备成功，事务管理器发送提交请求；否则发送回滚请求。

• 优点：协议简单，商业数据库支持后成本低。
• 缺点：性能不理想，高并发场景不适用；MySQL的XA实现存在主备切换数据不一致问题；许多NoSQL不支持XA，应用场景受限。

消息事务基于消息中间件的两阶段提交，将本地事务和发消息放在同一分布式事务。以RocketMQ为例：

• 流程：

  A系统发送预备消息到消息中间件。

  消息中间件保存预备消息并返回成功。

  A执行本地事务。

  A发送提交消息给消息中间件。

• 异常处理：

  步骤一或二出错，整个事务失败，不执行A本地操作。

  步骤三出错，A系统实现回调接口，消息中间件检查事务执行情况，失败则回滚预备消息。

  步骤四出错，消息中间件通过回调接口检查到A执行成功，自动提交消息。

• 特点：适用于高并发场景，牺牲一致性换取性能提升，存在B执行不成功导致一致性破坏的风险。

TCC（Try-Confirm-Cancel）模型不依赖资源管理器对分布式事务的支持，通过分解业务逻辑实现分布式事务。

• 三段业务逻辑：

  Try：完成业务检查，预留资源。

  Confirm：执行业务逻辑，使用Try阶段预留资源，需满足幂等性。

  Cancel：释放Try阶段预留资源，也需满足幂等性。

• 组成部分：

  主业务服务：发起并完成业务活动，编排服务。

  从业务服务：提供TCC业务操作，实现Try、Confirm、Cancel接口。

  业务活动管理器：管理控制业务活动，记录维护事务状态，调用Confirm或Cancel操作。

• 流程：

  主业务服务开启本地事务，申请启动分布式事务。

  注册从业务活动，调用从业务服务Try接口。

  Try接口调用成功，提交本地事务；失败则回滚。

  根据本地事务提交或回滚情况，调用从业务服务Confirm或Cancel接口。

  所有操作完成，全局事务结束。

• 特点：是两阶段提交变种，通过代码实现，不同业务场景代码复杂度不同，难以复用。

四、分布式事务总结

分布式事务本质是对多个数据库事务统一控制，按控制力度分为不控制、部分控制和完全控制。

• 不控制：不引入分布式事务。
• 部分控制：如消息事务+最终一致性、TCC模式，并发量和性能好，但数据一致性减弱。
• 完全控制：完全实现两阶段提交，牺牲性能保障一致性。

选择分布式事务方案需结合业务场景，技术人员应注重技术为业务服务，根据业务需求进行合理技术选型。