# 29.3\. 異步提交 _異步提交_是一個允許事務更快完成的選項，如果數據庫崩潰時，最新的事務可能會丟失。 在大多數應用中這個是可以接受的交易。 如在前一節中所述，事務提交通常是_同步的_：服務器等待事務的WAL 記錄刷新到永久存儲區，然后返回一個成功提示到客戶端。客戶端因此保證報告提交的事務將被保存， 即使服務器立即崩潰。然而，對于簡短的事務，延遲是總事務時間的主要部分。選擇異步提交模式意味著， 在它產生的WAL記錄實際轉移到磁盤之前，一旦事務邏輯上完成之后服務器就返回成功。 這樣在小事務的吞吐量上可以提供一個顯著的推動作用。 異步提交引進了數據丟失的風險。在向客戶端報告事務完成和事務實際完成的時間點之間有一個很小的時間窗口 （也就是，保證如果服務器崩潰時不會丟失）。因此如果客戶端采取外部動作（前提是假設事務會被記下）， 此時不應使用異步提交。例如，一個銀行肯定不會為一個ATM分配現金的事務使用異步提交。但在多數情況下， 如事件日志記錄，不需要這種強力保證。 使用異步提交的風險在于數據丟失，而不是數據損壞。如果數據庫崩潰，那么它會根據刷入的最新的 WAL記錄來進行恢復。因此數據庫會被轉儲到一個一致的狀態， 但任何沒有寫入到磁盤的事務不能反映在這個狀態。因此最后的結果是丟失最新的幾個事務。 因為事務是以提交的順序進行重放，不會引入非一致狀態；例如，如果事務B所做的更改依賴于前一個事務A， 那么丟失A的效果，而B的效果被保留是不可能的。 用戶可以為每個事務選擇提交模式，因此可以同時使用同步和異步提交事務。 這樣就允許在性能和事務持久性之間做一個靈活的權衡。提交模式是由用戶可設定的參數 [synchronous_commit](#calibre_link-1216)控制的，可以用任意配置參數可以設置的方式改變。 用于任意一個事務的模式依賴于事務提交開始時`synchronous_commit`的值。 某些實用命令，如`DROP TABLE`，會強制使用同步提交，無論`synchronous_commit` 參數是怎么設置的。這是為了保證服務器文件系統和數據庫邏輯狀態之間的一致性。支持兩階段提交的命令， 如`PREPARE TRANSACTION`，也是使用同步提交。 如果在一個異步提交和寫事務的WAL記錄中間時發生數據庫崩潰， 在事務期間的修改_將_會丟失。風險的持續時間會被限制，因為"WAL writer" 后臺進程會每隔[wal_writer_delay](#calibre_link-1433)毫秒就向磁盤刷入未寫入的WAL記錄。 風險的實際最大持續時間是三倍的`wal_writer_delay`， 因為WAL寫進程被設計為支持在繁忙時一次寫入所有塊。 | **Caution** | |:--- | | IMMEDIATE模式的關閉等同于服務器崩潰，因此會造成哪些未刷入的異步提交的數據丟失。 | 異步提交不同于設置[fsync](#calibre_link-1214) = off。`fsync` 是一個用于更改所有事物行為的服務器端設置。它會禁用所有PostgreSQL 中嘗試向數據庫不同部分同步寫入的邏輯，因此，一次系統崩潰（硬件或操作系統崩潰， 而不是PostgreSQL本身出問題）會導致數據庫狀態不可預知的崩潰。 在多數情況下，通過關閉`fsync`，異步提交會提高性能，但是不會有數據崩潰的風險。 看起來，[commit_delay](#calibre_link-1621)與異步提交很相似，但實際上它是一種同步提交方法 （事實上，異步提交時會忽略`commit_delay`）。在一次異步提交嘗試向磁盤刷入 WAL之前，`commit_delay`會造成延遲， 希望在一個這樣的事務中執行一個單獨的刷入可以用于同一時間的其他事務提交。 這個設置可以看做一種在可以加入一個關于參與單次刷入的組中的事務中提高時間窗口的方式， 來分攤多個事務刷新的開銷。