DAOS API 支持分布式事務，允許將針對屬於同一 Container 的對象的任何更新操作組合到單個 ACID 事務中。分布式一致性是通過基於多版本時間戳排序的無鎖樂觀並發控制機制提供的。DAOS 事務是可串行化的，可以在特定的基礎上獲取部分需要的數據集。
DAOS 版本控制機制允許創建持久的 Container 快照，該快照提供 Container 的實時分布一致性視圖，該視圖可用於構建生產者-消費者管道。
Epoch 和時間戳
每個 DAOS I/O 操作都有一個稱為 epoch 的時間戳。epoch 是一個 64 位整數，它集成了邏輯和物理時鍾（詳見 HLC paper）。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: debugzhang@163.com
華為雲社區: https://bbs.huaweicloud.com/blogs/254178