分布式事务与本地事务的区别
与本地事务不同的是，分布式事务需要有网络IO的交互达到对一个或多个数据库读写的效果。
在经典的本地事务中，一般情况下我们只需要transaction注解即可实现：
begin transaction #数据库操作1 #数据库操作2 commit transaction
但是在分布式事务的情况下，数据库操作涉及网络通信。而这种时候我们再使用传统的本地事务，网络通信实现的数据库操作会难以回滚，即失去了事务的原子性。
理论方案：
CAP理论：即一致性，可用性，分区容忍性
一致性：即不管怎么访问都是最新数据，这里是强一致性而非最终一致性；
可用性：任何时候访问都会有数据可以看，但是不能保证是最新的
分区容忍性：分布式架构时由于IO异常导致请求中断，消息丢失。但系统仍会对外提供服务
CAP理论中P是必定满足的，CA只能满足一个，一般情况下我们会选择满足A，让C保持最终一致性即可
以AP为基础，又提出了BASE理论，即基本可用BA，软状态：S，最终一致性E
基本可用：当系统无法保证满足全部可用的时候，保证核心业务可用即可，比如XX充值系统蹦了，但是商城还是可以买皮肤的
软状态：指可存在的中间状态，例如：外卖配送中，打印中，生成中.....
最终一致性：一些操作可能会有延迟，但是绝对不会迟到。比如xx宝退款两小时内到账
技术实现：
实现CP，保证一致性：
seata提供的两种方法（XA就不提了）
- AT：rm（资源管理器）注册分支事务，做完SQL就提交，但是会生成undo-log。如果有问题需要回滚就启动undo-log，没问题就删除
- TCC：try-confirm-cancel，
- try：会尝试执行业务逻辑，同时预留必要的业务资源。try不会真正的提交事务，而是根据成功与否进入二阶段：Confirm OR cancel
- confirm：try是没问题的，释放try的资源，更新事务状态为已提交
- cancel：try是有问题的，撤销预留资源，更新事务状态为已撤回
实现AP，保证可用性：
- 利用MQ，发送失败后会自动重试，达到一定次数后转人工。
- 利用Task调度，定时执行数据同步