分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同分布式系统的不同节点之上。其核心目标是保障跨多个资源或服务节点操作的ACID属性（原子性、一致性、隔离性、持久性），确保这些分布在不同节点上的小操作要么全部成功，要么全部失败。
理论基础
在分布式场景下，由于网络分区、节点故障等因素，严格保证ACID面临挑战，因此衍生出了以下核心理论：
CAP理论：指出分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance），开发者需要在一致性和可用性之间做出权衡。
BASE理论：作为CAP理论的延伸，强调基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventual Consistency）。它允许系统在一段时间内存在中间状态，但最终达到数据一致。
主流解决方案
为了应对分布式环境下的数据一致性挑战，业界发展出了多种解决方案：
2PC（两阶段提交）与3PC（三阶段提交）：基于XA协议的经典刚性事务方案。2PC通过准备和提交两个阶段由事务协调者统一管理；3PC在此基础上增加了预提交阶段和超时机制，试图解决2PC的单点故障和资源锁定问题。
TCC（Try-Confirm-Cancel）：一种柔性事务方案，将事务操作分解为Try（资源检查与锁定）、Confirm（确认执行）和Cancel（取消/补偿）三个阶段，由业务逻辑控制资源。
Saga模式：将长事务拆分为多个本地事务，如果某一步失败，则通过执行预先定义的补偿操作来撤销之前的步骤，从而实现最终一致性。
本地消息表：通过在数据库中记录消息来实现异步补偿，保障数据的最终一致性。
典型框架：Seata
随着微服务架构的普及，业界出现了集成多种模式的分布式事务框架，其中代表性的是阿里开源的 Seata。Seata通过事务协调器（TC）、事务管理器（TM）和资源管理器（RM）的协同工作，提供了AT、TCC、Saga和XA等多种事务模式。其默认的AT模式基于SQL解析实现两阶段提交，对业务代码无侵入，大幅降低了分布式事务的落地难度。
虽然BASE理论应用广泛，但在落地时必须明确边界，遵循以下最佳实践原则：
明确不适用场景：金融核心账务系统（如账户余额管理、资金划转）、与钱相关的核心交易场景，以及对数据一致性要求极高、不允许出现任何数据不一致的场景，必须使用ACID强一致性事务。
能不用分布式事务就不用：优先通过业务设计（如将相关数据放到同一数据库）使用本地ACID事务，这是最高效、最可靠的方案。
坚守三大底线：
幂等性前置：所有的写操作和柔性事务接口，必须先实现幂等性再开发业务逻辑。
完善可观测性：必须有完整的日志、链路追踪和监控告警，确保异常时能第一时间发现。
兜底补偿机制：必须设计定时对账、人工干预或补偿接口等兜底方案，确保即使自动处理失败，也能通过人工介入保障数据的最终一致性。
