背景

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

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

這里存在幾種可能，導(dǎo)致客戶端不知道執(zhí)行到底怎么樣了？

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

UNKNOWN 事務(wù)的處理

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

多節(jié)點(quorum based sync replication)與單節(jié)點都可能出現(xiàn)UNKNOWN事務(wù)，效果、形態(tài)一致。

如何處理unknown事務(wù)呢？

unknown事務(wù)分為以下幾種情況.

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

1、兩階段解決unknown狀態(tài)問題

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

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

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

3、非兩階段事務(wù)，commit unknown處理，極度嚴謹?shù)膱鼍埃绦蚩梢栽O(shè)計事務(wù)狀態(tài)可回溯，例如：

事務(wù)開始時，記錄事務(wù)號或唯一流水號，事務(wù)號在數(shù)據(jù)庫中是一個唯一的流水，可以根據(jù)事務(wù)號查詢它的狀態(tài)，比如postgresql。

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

使用業(yè)務(wù)流水實現(xiàn)事務(wù)狀態(tài)判斷的例子：

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