3PC在這種情況下會做什麼？

我們使用3PC（三階段承諾）進行分佈式事務。有4個節點，A，B，C，D，其中A是協調器。3PC在這種情況下會做什麼？

A從所有其他人收到OK並將準備提交消息發送給他們。
雖然C和D收到此消息並移動到準備狀態，但B發生崩潰並且未收到此消息（因此保持等待狀態）。
B超時，併發送中止給所有其他人，但只有D收到中止消息，而C收到中止消息之前崩潰。

現在的問題是：恢復後C會做什麼？根據http://courses.cs.vt.edu/~cs5204/fall00/distributedDBMS/sreenu/3pc.html，C將在失敗轉換後承諾恢復，而不是像D那樣中止。這不會導致不一致的狀態嗎？或者C有一些機制來檢測處於中止狀態的事務？

來源

2017-07-18 cntswj

我認爲在您對B節點行爲的問題上存在錯誤的假設？如果B在它移動到準備好的狀態之前崩潰，那麼它在重啓之後駐留在等待狀態，並且將被中止。

我期望C節點將被中止，因爲它將由協調員指令這樣做。我認爲這將與2PC類似。由協調員定期檢查丟失的節點是否再次可用。當C重新啓動時，協調器可以看到它並推動節點回滾，因爲中止消息將被重新發送。

來源

2017-07-19 13:24:12 chalda

對不起，有一個錯字。我在最後一段中將B改爲C.不知道協調器是否會在恢復後繼續檢查C並重新發送消息。 – cntswj

我明白你的觀點，我不確定如何區別對待。現在我找到一篇文章https://www.researchgate.net/publication/275154978_Three-Phase_Commit。我會從那裏引用：「注意，恢復的參與者即使參與者相對於事務處於預先提交狀態也不能提交事務，這是因爲操作 - 所有站點可能已決定在事務之後中止事務如果沒有一個參與者處於預先承諾狀態，參與者就失敗了，在這種情況下，參與者必須向其他站點詢問交易的最終狀態。「 – chalda

這一點事實是C正在恢復。 C可以通過等待指揮協調員來找到狀態。或者它可以要求其他參與者瞭解最終狀態。這取決於實施。 – chalda

3PC在這種情況下會做什麼？

回答

相關問題