分布式事务理解

实现分布式事务方式如下：

一. XA方式实现

• XA二阶段提交实现分布式事务
• 缺点一：同步性，一个全局的事务管理器协调和管理多个资源管理器（数据库连接），业务步骤执行顺序：A->B->C，因为是同步实现的，当C宕机后，A,B会一直等待C的回复一直把A,B服务拖垮。
• 缺点二：nosql，kafka等产品不支持XA，也就是说如果系统使用nosql产品XA是无法实现分布式事务的。
• 所以：需要强一致性的业务逻辑，可以选择XA方式实现分布式事务。（比如：用户抢购的业务逻辑，一旦用户抢购商品成功，商品库存就必须保证减一，否则会出现超卖现象）

二. TCC方式实现 (Try-Confirm-Cancel)

• TCC事务机制相对于传统XA事务机制，其特征在于它不依赖资源管理器(RM)对XA的支持
• 通过对 由业务系统提供的 业务逻辑的调度来实现分布式事务。
• TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑;

      [传统事务机制]的业务逻辑 = [TCC事务机制]的初步操作（Try） + [TCC事务机制]的确认逻辑（Confirm）。
  

• TCC事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其不良影响进行回撤。
• 使用业务程序代码实现的 Try/Confirm/Cancel, 需要与各个数据库的本地事务配合使用。
• 类似saga, 需要 可用性的业务逻辑,可以选择该方式实现;
• TCC事务机制简介
• 分布式事务 TCC 其实很简单
• 拜托，面试请不要再问我TCC分布式事务的实现原理

• 举例：
  1. 第一阶段：检查用户资金，如果资金充足，冻结用户本次交易资金，这笔资金被业务隔离，不允许除本事务之外的其它并发事务动用。
  2. 第二阶段：扣除第一阶段预冻结的用户资金，增加卖家资金，完成交易。

三. saga方式实现

• 一种消息驱动的本地事务序列；
• 通过消息，通过消息通知：本地事务A提交->本地事务B提交->本地事务C提交；
• 注意以上的提交commit,分别在各自的私有数据库内，如果C失败了，那么需要手动写代码实现事务回滚（补偿事务），手动写代码实现事务回滚，顺序是：C->B->A;
• 所以：需要 可用性的业务逻辑，可以选择该方式实现。比如:A代表收款成功，B代表发送用户短信，C代表增加用户积分，只要保证A成功，B/C即使真的失败的，也是可以容忍的（可以手工处理），但是保证了服务的可用性，对于用户来讲，系统没有阻塞，依然可以正常使用。