分布式事务

简介

随着业务的不断增多，涉及的服务及数据也越来越多，越来越复杂。传统的系统难以支撑，出现了应用和数据库等的分布式系统。分布式系统又带来了数据一致性的问题，从而产生了分布式事务。事务是基于对数据的操作，保证数据的一致性。

分布式事务关键点
事务的原子性：多个节点上操作的原子性

事务的一致性：多个节点上数据的一致性（网络故障等因素导致数据不一致）

事务的隔离性：多个节点上并发事务可能一部分已提交，一部分还未提交

CAP理论的可用性与一致性冲突(网络不是100%可靠，故只能选择CP / AP)。CAP 理论是忽略延时的，但是现实中不可能没有延时存在。因此CP是实现最终一致性。

方案

分布式事务中需要引入一个协调者来协调管理各节点事务，各节点称为参与者。

XA协议： 包括2PC 和 3PC：

· 二阶段提交协议(2PC,Two-phase Commit)

阶段一：准备阶段
协调者向参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复

参与者执行事务操作把undo信息和redo信息写入事务日志(不提交事务)，反馈执行结果

阶段二：提交/回滚
协调者收到成功消息或超时将向参与者发送fallback，否则commit

参与者收到消息后执行rollback 或 commit 操作

缺点：
提交阶段事务同步阻塞，性能瓶颈
协调者单点故障问题
网络问题可能导致部分参与者没接收到commit/rollback指令，导致数据一致性问题

· 三阶段提交协议(3PC,Three-phase Commit)

XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求，会自动进行本地commit。这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问题仍然没有根本解决。

TCC

TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC 是服务化的二阶段编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现：

Try 操作作为一阶段，负责资源的检查和预留。
Confirm 操作作为二阶段提交操作，执行真正的业务。
Cancel 是预留资源的取消。

MQ事务

利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。

Seata
Seata 是阿里一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。