背景

數據庫的事務是原子操作，要么成功，要么失敗。但是實際上在客戶端的視角，可能有第三種狀態：unknown狀態。

當客戶端提交事務結束（rollback , commit , prepare xact , rollback pxact , commit pxact）的請求后，數據庫收到請求，數據庫可能執行失敗，也可能執行成功，不管怎樣都要寫對于的WAL日志，還有CLOG，然后數據庫要將執行結果返回給客戶端ACK。

這里存在幾種可能，導致客戶端不知道執行到底怎么樣了？

收到客戶端請求后，數據庫沒有返回任何ACK給客戶端，客戶端對這次請求很茫然，它只能人為數據庫處于UNKNOWN的狀態。

UNKNOWN 事務的處理

unknown事務，就是客戶端沒有收到commit/rollback ACK的事務。不知道是成功還是失敗。

多節點(quorum based sync replication)與單節點都可能出現UNKNOWN事務，效果、形態一致。

如何處理unknown事務呢？

unknown事務分為以下幾種情況.

rollback , commit , prepare xact , rollback pxact , commit pxact 幾種情況的unknown處理方法：

1、兩階段解決unknown狀態問題

prepare 階段unknown, 切換leader后，客戶端通過pg_prepared_xacts視圖檢查prepare xact狀態，如果沒有prepare xact則說明失敗了，那么整個事務重新發起即可。如果prepare xact存在，說明prepare xact成功了。

commit or rollback prepare xact階段unknown, 切換后檢查prepare xact狀態，存在則重試commit or rollback prepare xact。不存在則說明已經成功（我們認為2PC是一定成功的），無須處理。

2、非兩階段事務，rollback unknown無須處理，rollback失敗或成功對于客戶端來說結果是一樣的。因為不管怎樣都會回滾掉，這是數據庫原子性保障的。

3、非兩階段事務，commit unknown處理，極度嚴謹的場景，程序可以設計事務狀態可回溯，例如：

事務開始時，記錄事務號或唯一流水號，事務號在數據庫中是一個唯一的流水，可以根據事務號查詢它的狀態，比如postgresql。

但是并不是所有數據庫都有這種接口，比如非物理流式復制的數據庫，則可以在事務中增加全局唯一流水號來查看事務是否提交。這里利用了事務的原子特性，既要么全成功要么全失敗。可以舉個使用例子。

使用業務流水實現事務狀態判斷的例子：

begin; 
生成唯一業務流水ID, 寫入到某個流水表，同時在程序或其他數據庫中記錄這個流水號，備查。 
執行事務 
提交事務； 
 
-- 出現unknown 
 
通過唯一業務流水ID，查詢數據庫中是否存在這條記錄。 
如果不存在，說明事務提交失敗。 
如果存在，說明事務提交成功。（因為數據庫的事務是原子操作）