江苏龙网

  1. 首页 > 人文 > >

事务干货放送 细说分布式事务两阶段提交( 二 )


如果参与者在发送Ready T前失败 ， 则协调者认为该节点事务Abort ， 并开始abort流程 。
如果参与者在发送Ready T后失败 ， 证明参与者本地事务已经持久化 ， 协调者忽视参与者失败 ， 继续事务流程 。
2.如果参与者在事务提交过程中失败 ， 其恢复过程 ， 需要根据参与者日志内容 ， 决定本地事务状态 。
如果日志中包含日志 ， 证明事务已经成功提交 ， REDO(T) 。
如果日志中包含日志 ， 证明事务已经失败 ， UNDO(T) 。
如果日志中包含日志 ， 参与者P需向其它节点咨询当前事务状态 。
如果协调者正常 ， 则向告知参与者P ， 事务已经commit或是abort ， 参与者依此REDO(T)或UNDO(T) 。
如果协调者异常 ， 则向其它参与者询问事务状态 。
a.如果其他参与者收到信息 ， 并已知事务是commit还是abort状态 ， 需回复参与者P事务状态 。
b.如果所有的参与者现在都不知道该事务的状态（事务上下文销毁了 ， 或者自己也处于未决状态） ， 那么该事务处于暂时既不能commit也不能abort 。 需要定期向其它节点问询事务状态 ， 直到得到答案 。 （这是2PC最不想遇到的一个场景）
c.如果日志中不包含上述几种日志 ， 说明该参与者在向协调者发送Ready T消息前就失败了 。 由于协调者没有收到参与者的回应 ， 会超时Abort ， 因此该参与者在恢复过程中 ， 遇到这种情况也需要abort 。
3.如果协调者在事务提交过程中失败 。 参与者需要根据全局事务状态（通过与其它参与者通信）决定本地行为 。
事务状态已经形成决议：
如果至少有一个参与者中事务T已经提交（参与者包含日志） ， 说明T必须要提交 。
如果至少有一个参与者中事务T已经Abort（参与者包含日志） ， 说明T必须要Abort 。
事务状态未形成决议：
如果至少有一个参与者没有进入Ready状态（参与者不包含日志） 。 说明全局还未就提交与否达成协议 。 有两种选择：（1）等待协调者恢复 。 （2）参与者自行abort 。 为了减少资源占用时间 ， 选择后者居多 。
如果所有参与者都进入了Ready状态 ， 且都没有或日志（事实上 ， 即使有这些日志 ， 查日志也是一种比较费的操作 ， 还需要考虑日志回收的问题） ， 这种情况下 ， 参与者谁都不知道现在事务的状态 ， 只能死等协调者恢复 。 （又到了这个最不想遇到的场景）
当参与者均进入ready状态 ， 等待协调者的下一步指令 ， 协调者在这个时候出现异常 ， 那么参与者将一直持有系统资源 ， 如果基于锁实现的并发控制 ， 还会一直持有锁 ， 导致其他事务等待 。
这种情况如果持续较旧 ， 会对系统产生巨大的影响 。 因此2PC最大的问题就是协调者失败 ， 可能会导致事务阻塞 ， 未决事务的最终状态 ， 只能等待协调者恢复后才确定 。 同时在这种情况下 ， 参与者宕机重启 ， 回放到这类未决事务 ， 重启回放完本地WAL ， 还是会有一个未决的事务不知道怎么处理 ， 事务持有的资源也不能释放 。
缓解2PC blocking思路
三阶段提交是两阶段提交的延伸 ， 目的是解决2PC block的问题 ， 但是也引入了其它问题 。 它的解决方式是为参与者引入timeout机制 ， 如果参与者成功PreCommit后 ， 一直收不到协调者最后的DoCommit请求 ， 等待超时自动提交 ， 显然这样会引入一致性问题 。
例如 ， 协调者收到一个参与者PreCommit失败 ， 打算发abort请求给其它参与者时宕机 ， 显然此时该分布式事务应该失败 ， 但一些参与者可能因为超时而提交 。
为了解决这个问题 ， 3PC多引进了一个阶段 ， 就是第一个阶段CanCommit阶段 ， 协调者询问所有参与者是否可以提交 ， 参与者如果状态正常 ， 就会回应可以提交 ， 但此时并不会占用任何系统资源 。 如果协调者及时收到了所有参与者ok的回应 ， 便会认为各个参与者正常 ， 之后的提交应该不会失败 。 但是实质上 ， 仍有小概率失败的可能：某参与者PreCommit失败后 ， 协调者和参与者都宕机 ， 其它参与者超时自动提交 ， 产生不一致 。


推荐阅读


上一篇：互联网平台：亚马逊限时免费移除库存促销开始啦

下一篇：中年人造食品风口来了？这家人造奶企业再获上亿美元融资