一、背景

筆者和團隊在崑崙分散式資料庫中的兩階段提交方式，可以成功避免經典的兩階段提交演算法的缺陷。

而在此分散式事務處理兩階段提交機制和原理上，筆者和團隊增強其容災能力和錯誤處理能力，可以做到任意時刻崑崙資料庫叢集的任意節點當機或者網路故障、超時等都不會導致叢集管理的資料發生不一致或者丟失等錯誤。

本文會詳述分散式事務對於兩階段提交演算法的錯誤處理原理和機制及延時損耗~

二、崑崙資料庫如何對兩階段提交演算法錯誤處理？

在生產環境的分散式資料庫叢集的工作場景中，通常只有不到0.01%的分散式事務提交會發生錯誤，但是我們仍然需要處理所有可能發生的錯誤。

因為哪怕執行了100億筆事務，只要有1筆發生了提交錯誤，都會導致使用者資料出錯。

資料庫系統就是要確保事務永遠正確地提交，ACID保障始終成立，沒有例外。

這對於分散式資料庫系統來說，會比單機資料庫更加複雜，因為可能的錯誤來源更多（多個計算節點和多個儲存節點，及其之間的網路連線）。

這也是為什麼資料庫系統的設計和實現會如此複雜，而分散式資料庫系統的設計和實現更加複雜 。

下面，我們就看一下崑崙分散式資料庫叢集如何處理分散式事務提交過程中發生的錯誤。我們分別講述 兩階段提交的每個階段的錯誤處理，以及批量寫入commit log 的錯誤處理。

分散式事務對於兩階段提交的錯誤處理

圖1. 第一階段提交失敗的處理

如果prepare 階段發生語句錯誤，網路斷連或者超時，那麼GTM 會提交rollback 記錄請求給GTSS ，並且不等待其返回結果就立刻傳送rollback 命令給出錯的節點並且斷連超時的連線，然後返回錯誤給客戶端，告知客戶端該事務GT 被回滾。

GTSS 會在commit log 中記錄GT 的提交指令為ROLLBACK, 這樣cluster_mgr 隨後處理GT 的prepared 事務分支時會回滾它們。

分散式事務對於兩階段提交的錯誤處理

圖2. commit log 寫入失敗的處理

如果GTSS 寫入commit log 出錯或者超時，那麼GTM 會回滾GT 的所有preapred 事務分支，也就是傳送XA ROLLBACK 給GT 寫入的所有儲存叢集，然後不論其結果如何都返回‘Aborted ’給客戶端標明GT 被回滾了。

即使XA ROLLBACK 傳送失敗了那麼這個事務分支仍然會按預期被cluster_mgr 回滾。

分散式事務對於兩階段提交的錯誤處理

圖3. 第二階段提交失敗的處理

如果第二階段發生網路錯誤或者超時，那麼仍然返回提交成功給客戶端。

這是因為只要記錄了commit log提交的任何分散式事務，都必須完成提交。

如果執行第二階段期間任何計算、儲存節點發生當機或者網路故障，那麼cluster_mgr程式會根據commit log的指令，來處理這些事務分支 --- 如果指令是提交那麼就提交GT的所有事務分支。

如果指令是回滾或者無法找到GT的commit log，那麼就回滾GT的所有事務分支。

如果第二階段進行過程中計算節點當機或者斷網了那麼這個事務仍將提交，此時應用系統後端（也就是資料庫的客戶端）會發現自己的commit 語句沒有返回直到資料庫連線超時（通常應用層也會讓終端使用者連線超時）或者返回了斷連錯誤。

由於兩階段提交的prepare 和commit 階段都需要等待儲存引擎flush WAL 日誌，並且在兩個階段之間還需要等待commit log 寫入後設資料叢集，所以兩階段提交的時耗一定比執行相同的SQL DML 語句但做一階段條會增加一些。

根據這個效能報告：http://www.zettadb.com/blogs/perf-cmp1，崑崙資料庫的兩階段提交在普通的伺服器硬體配置和千兆網路情況下會增加約30毫秒的延時。

在商用伺服器硬體和網路環境下，這個延時增加會少於30毫秒。這個30毫秒包括了commitlog的寫入，多執行一個階段的等待時間以及所有增加的網路通訊時間開銷等。

崑崙分散式資料庫的分散式事務處理機制，確保了分散式事務執行和提交的一致性和容災能力，在事務提交期間任何節點、網路故障都不會導致事務的ACID保障失效，從而確保了使用者資料正確。

在0.9版本中，崑崙資料庫將支援全域性MVCC一致性，那時將另外撰文介紹崑崙分散式資料庫的全域性MVCC的工作機制（敬請期待~）。