經典的兩階段提交演算法原理及缺陷

背景

筆者在過去經典的兩階段提交演算法過程中，發現會遇上部分節點在執行事務提交期間發生故障，導致如下的錯誤，這些錯誤都會導致使用者資料丟失或者出錯。錯誤如下：

1、 一個分散式事務的一部分事務分支被提交，另一部分事務分支被回滾

2、 應答給客戶端事務提交成功，但是分散式事務所有分支全部被回滾

3、 應答給客戶端事務被回滾，但是分散式事務部分或者全部分支被提交

4、 儲存節點故障恢復時，某個儲存節點的事務分支不能被正確地恢復。

在上面這些錯誤源中，第 #4 類錯誤處理由儲存節點自身負責，分散式事務處理機制負責處理前 3 類錯誤，筆者會在下篇文章做主要討論。

對於第 #4 類錯誤，筆者曾經在 FOSDEM 2021 做過一次技術分享， ，國內影片連線在： 崑崙分散式資料庫 MySQL XA 事務處理的容災技術 （ ）以後也會陸續撰文詳述。

經典的兩階段提交演算法原理

兩階段提交演算法把事務的提交分為 preapre 和 commit 兩個階段。

第一階段事務管理器 GTM 傳送 prepare 命令給所有的 resourcemanager （ RM ），每個 RM 就 prepare 分散式事務的本地分支，也就是把它們的 WAL 日誌刷盤以便即使 RM 當機，恢復之後仍然可以提交（或者回滾）這些 prepared 狀態的事務。

prepare 一個事務之後，這個事務進入 prepared 狀態，之後既可以 commit 它，也可以 rollback 它。

如果 GTM 收到所有的 RM 返回的都是成功，那麼 GTM 傳送 commit 給每個參與的 RM ，於是 RM 就提交其 prepared 狀態的事務分支，這樣就完成了兩階段提交。

經典的兩階段提交演算法缺陷

如果兩階段提交流程中發生 GTM 或者 RM 當機等故障，那麼這個兩階段提交流程就可能中斷並且無法正確地繼續的問題。

如何最佳化避免其缺陷？

為避免此類事故發生，崑崙分散式資料庫的分散式事務處理機制基於經典的兩階段提交演算法，並在此基礎上增強了其容災能力和錯誤處理能力。

故此可以做到任意時刻崑崙資料庫叢集的任意節點當機或者網路故障、超時等都不會導致叢集管理的資料發生不一致或者丟失等錯誤。

一個崑崙分散式資料庫叢集包含若干個彼此獨立且功能相同的計算節點做分散式事務處理和分散式查詢處理（下篇文章做詳述）：

• 包含若干個儲存叢集儲存使用者資料分片，每個儲存叢集使用高可用機制確保節點當機資料不丟失。

• 一個結構與儲存叢集完全相同的後設資料叢集，它儲存著這個叢集的關鍵後設資料資訊，包括本文所說的 commit log 。

• 一個 cluster_mgr 模組 ,  負責維護叢集執行狀態，並且處理因為節點故障而殘留的 prepared  狀態的事務分支。

故此在上述的模組的有機配合下，經典的兩階段演算法提交的缺陷可以很好的避免！

總結

對於經典的兩階段提交演算法流程，筆者及團隊已經做了最佳化用於解決這些問題，從而達到堅不可摧的容災能力。對於最佳化的原理過程，筆者會在下文做詳述~

推薦閱讀