分布式事务产生的原因：
-
数据库分库分表
-
应用的SOA化。就是业务的服务化(面向服务架构)
分布式事务的解决方案：
1、两阶段提交协议2PC
这里的两阶段提交和redolog binlog的两阶段提交不是一个东西，redo log和bin log的两阶段提交保证的是什么？
第一阶段：表决阶段，所有的参与者（本地资源管理器）都将本事务能否成功的信息反馈给协调者(事务协调器)
第二阶段：执行阶段，协调者根据所有参与者的反馈，通知所有的参与者，步调一致地在所有分支上提交或者回滚
这里衍生出两个角色：协调者和参与者
2、补偿事务方案TCC
两阶段提交的一种改进，TCC方案在点商和金融领域使用较多。其将整个业务的每个分支显式的分成try、confirm、cancel三个操作。Try操作完成业务的准备工作，Confirm操作完成业务的提交，Cancel操作完成事务的回滚。
3、Seata分布式事务框架
经过阿里双11的检测。
Seata三大模块，TM RM TC。
TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
AT模式(重点需要了解AT模式，目前使用的最多)
AT模式是一种无侵入的分布式事务解决方案。在AT模式下，用户只需要关注自己的业务sql，用户的业务sql作为一阶段，Seata框架会自动生成事务的二阶段提交和回滚操作。
AT模式一阶段：
在一阶段，Seata会拦截业务sql，首先解析sql语义，找到业务sql要更新的业务数据，在业务数据被更新前，将其保存成before image，然后执行业务sql更新业务数据，在业务数据更新之后，再将其保存成after image，最后生成行锁。
AT模式二阶段：
二阶段要么提交，要么回滚。
提交:
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
回滚：
二阶段如果是回滚的话，Seata就需要回滚一阶段已经执行的业务sql，所以直接使用before image回滚，但是回滚前还需要做一次校验，对比当前数据库的业务数据和after image是不是完全一致，如果是就说明没有脏写，可以还原业务数据。如果不一致，人工处理。
after image vs 数据库数据 —》还原数据 --》删除中间数据
TCC模式
2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。
TCC 三个方法描述：
- Try：资源的检测和预留；
- Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；
- Cancel：预留资源释放；
以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完成的扣钱操作，拆成两阶段，实现成三个方法，并且保证一阶段 Try 成功的话 二阶段 Confirm 一定能成功。
如上图所示，
Try 方法作为一阶段准备方法，需要做资源的检查和预留。在扣钱场景下，Try 要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结 A 账户的 转账资金。Try 方法执行之后，账号 A 余额虽然还是 100，但是其中 30 元已经被冻结了，不能被其他事务使用。
二阶段 Confirm 方法执行真正的扣钱操作。Confirm 会使用 Try 阶段冻结的资金，执行账号扣款。Confirm 方法执行之后，账号 A 在一阶段中冻结的 30 元已经被扣除，账号 A 余额变成 70 元 。
如果二阶段是回滚的话，就需要在 Cancel 方法内释放一阶段 Try 冻结的 30 元，使账号 A 的回到初始状态，100 元全部可用。
用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。
-hive分区表与分桶表)
