【分布式】分布式事务的解决方案

开篇词：

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
基于CAP定理可以知道，我们要么采用强一致性方案，要么采用弱一致性方案
所谓强一致性方案：是指通过第三方事务管理来协调多个节点的事务性，保证每个节点达到同时成功或者同时失败，为了实现这个需求，我们会引入X/OPEN DTP模型提供的XA协议，基于2阶段提交或者3阶段提交的方式去实现，但是全局事务管理器中多个节点中任一一个节点，在提交事务确认的时候，由于网络通信延迟导致了阻塞就会影响到所有节点事务的提交，而这个阻塞过程也会影响到用户的请求线程，这对用户体验和整体性能影响非常大
所谓弱一致性方案：是针对强一致性方案所衍生出来的性能和数据一致性平衡的一个方案，简单来说就是损失掉强一致性，数据在某一时刻会存在不一致的状态，但是最终会达成一致，好处是提升了系统的性能，常见解决方案有：第一个分布式消息队列实现最终一致性 、 第二个基于TCC事务，通过演进版本的二阶段提交实现最终一致性 、第三个使用seata事务框架，它使用了多种事务模型，比如AT，XA，Saga，TCC，不同模型提供了强一致性或者弱一致性的支持

干货篇：

1. CAP定理

Consistency (一致性)：所有节点在同一时间的数据完全一致，这就是分布式的一致性
Availability (可用性):即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
Partition Tolerance (分区容错性):即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务

2. XA

XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器™和(局部)资源管理器(RM)之间的接口。本地的数据库如mysql在XA中扮演的是RM角色
XA一共分为两阶段：
第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。
第二阶段 (commit/rollback)：当事务管理者™确认所有参与者(RM)都ready后，向所有参与者发送commit命令。目前主流的数据库基本都支持XA事务，包括mysql、oracle、sqlserver、postgre
XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。
XA事务的特点是：简单易理解，开发较容易对资源进行了长时间的锁定，并发度低

3. Sega

Saga核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
SAGA事务的特点：
并发度高，不用像XA事务那样长期锁定资源
需要定义正常操作以及补偿操作，开发量比XA大
一致性较弱，对于转账，可能发生A用户已扣款，最后转账又失败的情况

4. TCC

TCC分为3个阶段
Try 阶段：尝试执行，完成所有业务检查（一致性）, 预留必须业务资源（准隔离性）
Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作要求具备幂等设计，Confirm 失败后需要进行重试。
Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，要求满足幂等设计。
TCC特点如下：
并发度较高，无长期资源锁定。
开发量较大，需要提供Try/Confirm/Cancel接口。
一致性较好，不会发生SAGA已扣款最后又转账失败的情况
TCC适用于订单类业务，对中间状态有约束的业务

5. AT-强一致性

Seata 将为用户提供了 AT、TCC(类似2PC)、SAGA（长事务解决方案、基于状态机）
为用户打造一站式的分布式解决方案。
AT模式同tx-lcn类似，通过代理底层数据库连接，控制数据库事务的提交与回滚（必须依赖数据库）；
当然seate由于是由阿里维护的，同时支持多种注册中心，zookeeper、eureka等。

我是杰叔叔，一名沪漂的码农，下期再会！