两阶段提交协议的异常处理-阿里云开发者社区

开发者社区> 云计算> 正文
登录阅读全文

两阶段提交协议的异常处理

简介:

两阶段提交的协议大家都比较熟悉了,解释一下每个阶段的异常处理。首先,我们需要持久化协议过程中的状态,这样如果server宕机,那么恢复的时候还能通过日志知道宕机前处于那个阶段。同时,所有对数据的修改都会先写write ahead log,保证宕机重启的之后数据也不会丢失。写日志的顺序假定为:写write ahead log-修改缓冲区-写commit/abort log。

在这个前提下,我们根据如下的时序图来讨论异常情况和处理方法。

两阶段提交协议时序

两阶段提交协议时序


  1. 过程a没有成功,即协调者没有收到部分参与者的回应。超时后,协调者发送abort消息给参与者取消事务。参与者存在两种情况:

  • 过程1失败,网络问题导致参与者没有收到vote request消息或者此时参与者宕机。参与者重启恢复后无需做任何事。

  • 过程2失败,参与者收到了vote request,网络问题协调者没有收到回复或此时参与者宕机。参与者宕机恢复或等待超时后广播DECISION_REQUEST消息向其他参与者询问是否收到commit/abort消息。

过程b没有成功,即协调者发送commit消息之后没有收到部分参与者的回应。协调者需要重试,确认参与者的提交完毕消息,如果多次尝试不能联系上,则等待参与者上线之后解决。参与者存在两种情况:

  • 过程3失败,网络问题导致参与者没有收到commit消息或此时参与者宕机。参与者上线发现在本地日志中发现尚未提交成功,因为到达这里,可以肯定本地已做好提交准备,但是不知道协调者是决定提交,所以向协调者询问,按协调者的回复来进行提交或回滚。如果无法联系上协调者,则向其他参与者询问事务状态,如果有某一个节点已经做了提交或异常终止(说明协调者已发送了相关消息),则做同样的操作。

  • 过程4失败,参与者完成了commit/rollback,但是网络问题协调者没有收到回应或者此时参与者宕机。参与者在本地日志中发现已完成本地提交,所以可能由于网络故障导致提交完成消息没有到达协调者。所以直接忽略。这时可能协调者在等待该参与者的提交完成回应消息,所以参与者主动联系协调者告知事务状态。

过程c没有成功,即参与者发送vote回应消息之后没有等到协调者的commit/rollback消息。这个过程参与者的异常处理已经讨论过了,这里讨论协调者的异常处理。存在两种情况:

  • 过程2失败,网络问题导致协调者没有收到回复或此时协调者宕机。协调者恢复重启后,发现并未做提交操作,保险操作(因为不知道它是否发送过准备消息,或其他参与者是否做好提交准备),直接发送abort消息给所有参与者,终止事务

  • 过程3失败,网络问题导致参与者没有收到commit/rollback消息或者此时协调者宕机。协调者恢复重启后,不能保证所有参与者都已收到了提交消息,所以给所有的参与者发送commit消息,保证事务的正常提交。

参考文献:

[1] 两阶段提交(2PC)协议, http://blog.chinaunix.net/uid-20761674-id-75164.html

原文链接:http://cxh.me/2014/07/07/two-process-commit-exceptions/

特别说明:尊重作者的劳动成果,转载请注明出处哦~~~http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt371

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: