DAOS API 支援分散式事務，允許將針對屬於同一 Container 的物件的任何更新操作組合到單個 ACID 事務中。分散式一致性是通過基於多版本時間戳排序的無鎖樂觀併發控制機制提供的。DAOS 事務是可序列化的，可以在特定的基礎上獲取部分需要的資料集。 DAOS 版本控制機制允許建立持久的 Container 快照，該快照提供 Container 的實時分佈一致性檢視，該檢視可用於構建生產者-消費者管道。 # Epoch 和時間戳 每個 DAOS I/O 操作都有一個稱為 epoch 的時間戳。epoch 是一個 64 位整數，它集成了邏輯和物理時鐘（詳見 [HLC paper](https://cse.buffalo.edu/tech-reports/2014-04.pdf)）。DAOS API 提供了輔助函式，用於將 epoch 轉換為傳統的 POSIX 時間（即 `struct timespec`，詳見 `clock_gettime(3)`）。 # Container 快照 如下圖所示，Container 的內容可以隨時快照。  DAOS 快照非常輕量級，並且使用與建立快照的時間相關聯的 epoch 進行標記。一旦建立成功，快照將一直保持可讀性，直到它被顯式銷燬。在特定快照未被銷燬前，Container 的內容可以回滾到該快照。 Container 快照功能支援本機生產者/消費者管道：  一旦成功寫入資料集的一致版本，生產者 (Producer) 將生成一個快照。使用者 (Consumer) 的應用程式可以訂閱 Container 快照事件，以便在生產者提交更新時可以處理新的更新。 快照的不變性保證了使用者可以看到一致的資料，即使生產者繼續進行新的更新。生產者和消費者實際上都在 Container 的不同版本上操作，不需要任何序列化操作。一旦生產者生成了資料集的新版本，使用者就可以查詢兩個快照之間的差異，並且只處理增量修改。 # 分散式事務 與 POSIX 不同，DAOS API 不強制執行最壞情況下的併發控制機制來處理衝突的 I/O 操作。相反，各個 I/O 操作被標記為不同的 epoch，並按照 epoch 的順序應用，而不管執行順序如何。這個基準模型為不產生衝突的 I/O 工作負載的資料模型和應用程式提供了最大的可伸縮性和最高的效能。典型的例子是 MPI-IO 集合操作、POSIX 檔案讀/寫操作和 HDF5 資料集讀/寫操作。 對於需要將衝突序列化的部分資料模型，DAOS 提供了基於多版本併發控制的分散式可序列化事務。當不同的使用者程序要覆蓋與 dkey/akey 關聯的值時，通常需要該事務。例如 DAOS 上的 SQL 資料庫，或者由非一致的客戶端併發訪問的一致的 POSIX 名稱空間。 在同一操作的上下文中提交的所有 I/O 操作（包括讀取）將使用相同的 epoch。DAOS 事務機制自動檢測傳統的讀/寫、寫/讀和寫/寫衝突，並中止其中一個衝突事務（事務在 `-DER_RESTART` 引數下提交失敗）。然後，使用者/應用程式必須重新啟動失敗的事務。 在目前的實現中，事務 API 具有以下限制，這些限制將在未來的 DAOS 版本中解決： - 不支援 **Array API** - 通過同一上下文環境執行的物件獲取/列表和鍵值獲取/列表操作所進行的事務物件更新和鍵值放入操作不可見。 # 相關資訊 > GitHub: https://github.com/storagezhang > > Emai: [email protected] > > 華為雲社群: https://bbs.huaweicloud.com/blogs/254178 > > DAOS: https://github.com/daos-stack/daos > > 本文翻譯自 https://daos-stack.github.io/overview/tra