分布式事务-2阶段提交

分布式事务

何为分布式事务？
随着互联网的发展与技术的更新，单机服务器已经不能满足业务的需求，所以就诞生了分布式的概念，既然有分布式的诞生，那么以前的事务的参与者，支持者也要考虑在不同节点上如何完整的运行。（分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。）

2阶段提交

以最常见的订单、支付系统来举例说明，首先先说明两个概念：
1、TM（Transaction Manager）事务管理器，负责协调和管理事务。
2、RM（Resource Manager）资源管理器，可以理解为一个 数据库系统。

上图所示为2阶段提交，

1PC：提交事务请求

（1）事务询问，协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各个参与者节点的响应。
（2）执行事务，参与者节点执行询问发起的所有事务操作，并将undo信息和redo信息写入日志。
（3）反馈响应，各个参与者节点响应协调者节点发起的询问，如果参与者节点的事务操作实际执行成功，则返回一个“确认”消息；如果参与者节点的事务操作实际执行失败，则返回一个“停止”消息。

2PC：执行事务提交

如果第一阶段各个参与者节点返回的都是“确认”消息
（1）发送提交请求，协调者节点向所有参与者节点发出“commit”请求。
（2）事务提交，参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
（3）反馈事务提交结果，各个参与者节点向协调者节点发送“完成”消息。
如果第一阶段参与者节点返回的“停止”消息，或者协调者节点在第一阶段的询问超时之前无法获取各所有参与者节点的响应消息时
（1）发起回滚请求，协调者节点向所有参与者节点发出“rollback”请求。
（2）事务回滚，参与者节点用之前写入的undo信息执行回滚，并释放在整个事务期间内占用的资源。
（3）反馈事务回滚结果，参与者节点向协调者节点发送“回滚完成”消息。
（4）中断事务，协调者节点受到所有参与者节点反馈的“回滚完成”消息后，取消事务。
注：不管最后结果如何，第二阶段都会结束当前事务
一些问题：如果TM单点故障，会导致程序失效，阻塞资源，性能变低，导致最后数据不一致
第二阶段发commit后，有一个执行失败，则无法回滚
所以，针对这些问题，要引入补偿机制（人工补偿，定时任务，脚本补偿）