1.什么是分布式事务
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
2.为什么会产生分布式事务
场景举例：一个顾客访问某知名电商平台，进行商品购买，电商平台架构按照不同的功能进行了拆分，有订单、会员、库存子系统，在这个下单的过程中分布式事务就产生了。
如下图所示：顾客在创建一个订单的时候，要在订单库增加一个订单数据，同时会同步的在会员服务数据库增加积分和库存服务数据库减少库存。这种操作在单个数据库中完成是没有任何问题的。一旦涉及到了分布式的情况，比如下方三个独立数据库的情况，如何来保障数据全局提交，全局回滚，这就是分布式事务要做的事情了。
3.分布式事务工作流程
作为分布式事务，不论是阿里的Seata还是其他的方案，都要额外的增加一个特殊的角色，叫做事务的协调者。
事务协调者的主要作用：向具体的子项目下达请求提交和请求回滚的通知。
事务协调者工作流程：
1、有请求进来，事务协调者通知每一个服务开启事务。
2、服务接收到事务开始处理的请求后，就开始执行自己的业务逻辑，比如创建订单，增加积分，自己的业务逻辑执行完成之后，会通知事务协调者自己执行完成。
4、各个服务执行自己刚才数据库中未提交的操作，所有服务都本地提交完成之后，就完成了这个分布式事务操作。
在分布式事务架构中，有两种经典的分布式事务解决方案，二阶段提交和三阶段提交
这个就是简单的二段式事务提交过程
4.二阶段提交
第一个阶段：事务的协调者向各个服务发起事务操作的请求，然后每一个服务进行独立的处理，但是数据不提交。
第二个阶段：事务协调者收到完成的报告之后，再次下达一个命令，来进行数据的提交，这个时候数据才会发生真正的变更。
对于二阶段提交有一个致命问题：某个服务因为网络原因无法收到协调者下达的提交命令，则未提交的数据就会被长时间阻塞，可能导致系统崩溃。
以下图为例：如果在提交阶段，事务协调者与库存服务之间断网，提交指令无法下达，这会导致库存中飞科剃须刀，商品库存记录长期处于未提交的状态，因为这条数据被数据库排它锁长期独占，之后再有其他线程要访问飞科剃须刀库存数据，该线程就会长期处于阻塞状态，随着阻塞线程的不断增加，库存的服务会面临崩溃的风险。
这个问题要怎么解决呢？
在服务这一侧增加超时机制，过一段时间，被锁定的飞科剃须刀，因超时自动执行提交操作，释放锁定资源，尽管这样做会导致数据不一致，但也比线程挤压导致服务崩溃要好。出于此目的三阶段提交便应运而生。
5.三阶段提交
三阶段提交实质，是将二阶段中的提交阶段拆分为预提交阶段与提交阶段，同时在服务端都引入超时机制，保证数据库资源不会被长期锁定，下面是三阶段提交的示意过程。
3PC阶段一：事务预处理阶段
3PC的事务预处理阶段和2PC是一样的，用于处理本地事务，锁定数据库资源，当所有服务返回成功后，进入阶段二。
3PC阶段二：预提交阶段
3PC阶段三：提交阶段
3PC的提交阶段与2PC是一致的，在每一个数据库中，执行提交实现数据库的资源写入，如果协调者与服务通信中断导致无法提交，在服务端超时后，也会自动执行提交操作，来保障资源释放。
6.总结
通过对比我们发现，3阶段提交是2阶段提交的优化版本，主要通过加入预提交阶段，引入超时机制让数据库不会被长期锁定，但这也带来一个新问题，数据一致性也很可能因为超时后的强制提交被破坏。对于这个问题，各大软件公司都在各显神通，常见的做法有，增加异步的数据补偿任务，日中跑批前的数据补偿，更完善的业务数据完整性的校验代码，引入数据监控及时通知人工补录 这些都是不错的补救措施。
最后强调一下，无论是2PC还是3PC都是一种方案，是一种宏观的设计，如果要落地就要依托具体的软件产品。
转载请注明：西门飞冰的博客 » 分布式事务之二段式和三段式
