分布式事务：理论方案与技术实现

分布式事务与本地事务的区别

与本地事务不同的是，分布式事务需要有网络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调度，定时执行数据同步