两阶段提交协议的异常处理
详见:http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt371
两阶段提交的协议大家都比较熟悉了,解释一下每个阶段的异常处理。首先,我们需要持久化协议过程中的状态,这样如果server宕机,那么恢复的时候还能通过日志知道宕机前处于那个阶段。同时,所有对数据的修改都会先写write ahead log,保证宕机重启的之后数据也不会丢失。写日志的顺序假定为:写write ahead log-修改缓冲区-写commit/abort log。
在这个前提下,我们根据如下的时序图来讨论异常情况和处理方法。
两阶段提交协议时序
-
过程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消息,保证事务的正常提交。