詳見：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消息，保證事務的正常提交。

總結

以上是生活随笔為你收集整理的两阶段提交协议的异常处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。