背景

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

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

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

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

UNKNOWN 事務的處理

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

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

如何處理unknown事務呢？

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

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則說明失敗了，那么整個事務重新發(fā)起即可。如果prepare xact存在，說明prepare xact成功了。

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

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

3、非兩階段事務，commit unknown處理，極度嚴謹?shù)膱鼍?，程序可以設計事務狀態(tài)可回溯，例如：

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

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

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

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