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