以 Linux 非同步 I/O（io_uring）技術最佳化資料庫持久性 （★
103 分）
作者在文章中探討了一種以 Linux 非同步 I/O 技術 io_uring 優化資料庫持久性的方法。他先以一個簡單的鍵值資料庫為實驗平台，利用記憶體內雜湊表和附加寫入日誌（即寫前日誌，WAL）配合每次寫入後使用 fsync 執行同步輸出以確保持久性，但這種傳統方法在效能上受限。為了突破這一瓶頸，作者開始研究 io_uring，其通過提交佇列（SQ）與完成佇列（CQ）兩個共享環形緩衝區，能夠一次提交多個 I/O 操作，從而充分利用現代硬體（例如 NVMe SSD）所具備的高度並行處理能力。
利用 io_uring，作者嘗試將同步的寫前日誌操作改為非同步模式，初步實驗結果顯示在吞吐量上能立刻提升約 10 倍。然而，非同步 I/O 在資料持久性上帶來挑戰：由於回應可能在資料真正寫入穩定儲存空間前就已發出，客戶端收到成功訊息後若遇到系統崩潰，部分操作可能無法正確復原。為此，他提出一種雙重寫前日誌設計，將原本一體化的日誌拆分成「意圖日誌」與「完成日誌」，分別用以記錄操作發起與完成，只有在兩者都成功非同步寫入後，系統才回應成功訊號。
在設計上，作者使用了 Zig 語言來實作該機制，並採用環形緩衝區批次處理方式以降低系統呼叫成本，充分發揮硬體並行特性。復原過程中，系統先讀取全部意圖記錄，再比對完成記錄，僅重放兩筆記錄都有且通過檢查碼驗證的操作，以確保資料一致性與完整性。這種機制突破了傳統同步 fsync 模型，讓資料庫在效能與一致性間取得更好的平衡。
在 Hacker News 的討論中，網友對此設計提出了多項質疑與建議。有評論指出，若系統在客戶端接收到成功訊息前，兩筆非同步寫入操作尚未完全落盤，則可能導致在災難性故障後部分資料無法復原，進而動搖了系統的 ACID 保證。另有意見認為，效能提升的關鍵在於避免傳統 fsync 的延遲，而非單純靠拆分寫前日誌來實現。此外，也有網友要求提供更多實驗數據，來證明在高並發場景下這種雙重日誌機制能否真正兼顧性能與可靠性。整體而言，討論熱烈地探究了如何在非同步 I/O 應用中，在提升資料庫交易效能的同時，仍保持足夠的持久性保證。
👥
32 則討論、評論 💬
https://news.ycombinator.com/item?id=44622454