DAOS 分佈式異步對象存儲｜事務模型

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

DAOS: https://github.com/daos-stack/daos

本文翻譯自 https://daos-stack.github.io/overview/transaction