這篇文章主要給大家介紹了PostgreSQL數據庫事務出現未知狀態的處理方法,需要的朋友可以參考下
背景
數據庫的事務是原子操作，要麼成功，要麼失敗。但是實際上在客戶端的視角，可能有第三種狀態：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，查詢數據庫中是否存在這條記錄。
如果不存在，說明事務提交失敗。
如果存在，說明事務提交成功。（因爲數據庫的事務是原子操作）