邯郸建设网站的公司,站点搭建,厦门seo网站推广优化,公司网站建设公司好在上一篇文章中#xff0c;我们详细介绍了分布式事务中的两阶段提交#xff0c;以及知道了两阶段提交存在一定的问题
深入理解分布式事务中的两阶段提交#xff08;2PC#xff09;#xff0c;什么是2PC#xff0c;2PC原理是怎样#xff1f;2PC有没有什么问题#xff1…在上一篇文章中我们详细介绍了分布式事务中的两阶段提交以及知道了两阶段提交存在一定的问题
深入理解分布式事务中的两阶段提交2PC什么是2PC2PC原理是怎样2PC有没有什么问题解决方案无法解决的情况 同步阻塞问题执行过程中所有节点都是事务阻塞型的当参与者占有公共资源时其他第三方节点访问公共资源不得不处于阻塞状态也就是说从投票阶段到提交阶段完成这段时间资源是被锁住的 单点故障协调者的故障会导致整个事务无法继续参与者会一直阻塞等待协调者回应否则无法完成这次协议整个系统就会进入阻塞态
三阶段提交协议是二阶段提交协议的改进版本把两阶段提交协议的准备阶段一分为二这样就有了 CanCommit、PreCommit、DoCommit 三个阶段
三阶段提交3PC 三阶段提交在两阶段提交的基础上增加了一个准备阶段分为三个阶段
CanCommit阶段协调者询问参与者是否可以提交事务参与者返回 Yes 或 No。PreCommit阶段协调者根据参与者返回的结果分为两种情况 如果参与者有返回 No 或者等待超时后协调者就向所有参与者发送 abort 请求所有参与者收到 abort 请求或者超时未收到请求执行事务的中断如果所有参与者都返回 Yes协调者发送 PreCommit 预提交请求参与者执行事务并记录日志如果都执行成功则会返回 ACK 相应给协调者 DoCommit阶段协调者根据参与者返回的结果也分为两种情况 任一参与者未发送 ACK 报文或者发送的不是 ACK 报文或者相应超时那么协调者就会向所有参与者发送 abort 中断请求所有参与者接收到之后执行事务回滚操作并释放所有的事务资源完成事务回滚后再发送 ACK 消息协调者接收到后执行事务中断协调者接收到所有参与者发送的 ACK 后会发送 DoCommit 提交请求参与者正式提交事务并释放所有事物资源提交完成后再向协调者发送 ACK 报文
三阶段提交协议的优化
同步阻塞问题优化
三阶段提交协议在第一个询问阶段时是并不锁定资源的
在两阶段提交协议中想象一下如果有 10 个参与者和 1 个协调者协调者在准备阶段发送 Prepare 消息有 9 个 参与者正常返回同意有一个返回中止或者超时不回然后协调者就向所有参与者发送回滚请求这不就浪费了很多的资源么毕竟这期间 9 个参与者是锁定了资源的
同时三阶段提交协议为参与者也增加了超时机制两阶段提交中只有协调者有超时机制一旦发生协调者宕机整个系统就处于阻塞态了。
在进入第三阶段如果参与者没有收到协调者发来的请求会默认提交事务而不会一直持有事务资源并处于阻塞状态
但是这种机制会出现数据一致性问题如果协调者发送的是 abort 请求那没收到的参与者就与收到的参与者的数据不一致了
总结
从协调者收到一次事务请求、发起提议到事务完成两阶段提交协议是 2 次 RTT即准备阶段和提交阶段而三阶段提交协议是 3 次 RTTCanCommitPreCommitDocommit但是允许参与者自主决策防止协调者宕机后整个系统处于阻塞态增加了系统的可用性对一些现实业务场景是非常值得的
**不论两阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。**在极端情况下会出现事务预提交成功但事务确认提交失败的情况事务管理器会记录事务日志根据事务日志进行恢复人工干预环节是无法避免的。
