Azure 表存储乐观并发处理？

Posted 2023-02-19

【中文标题】Azure 表存储乐观并发处理？

【英文标题】：Azure Table Storage optmistic concurrency handling?

【发布时间】：2022-01-15 12:53:01

【问题描述】：

在传统的关系数据库上，为了防止 Last Writer 获胜的情况，更新通常如下进行：

update MyTable
set myColumn = @newValue,
    version=version+1
where myPk = @pk and version = @versionObtainedPreviously

如何使用 Azure 表存储实现类似的行为？

【参考方案1】：

Azure 表存储中的开放式并发是通过实体上的ETag 属性处理的。每当更新实体时，其 ETag 值都会更改。

使用乐观并发更新实体的过程如下：

您从表中获取实体。 您在客户端对实体进行更改（比如增加version 属性）。 您将更新请求发送到表存储。发送更新请求时，您需要包含获取的实体的 ETag 值。

当更新请求中包含 ETag 值时，Table Storage 会将该值与实体的当前 ETag 值进行比较。

如果两者相同，则表示实体在获取后尚未更新，可以进行更新。

如果值不同，则表存储返回 Pre Condition failed (412) 错误。在这种情况下，您需要再次获取实体并重复该过程。

来自link：

实体的 ETag 为更新提供默认乐观并发 操作。 ETag 值是不透明的，不应阅读或依赖 之上。在更新操作发生之前，表服务会验证 实体的当前 ETag 值与 ETag 值相同 包含在 If-Match 标头中的更新请求中。如果值 是相同的，表服务确定实体没有 自检索以来已被修改，以及更新操作 收益。

如果实体的 ETag 与更新时指定的不同 请求，更新操作失败，状态码为 412（前提条件 失败的）。此错误表明实体已在 服务器，因为它被检索。要解决此错误，请检索 再次实体并重新发出请求。

要强制进行无条件更新操作，请将 If-Match 请求头中的通配符 (*)。通过 该操作的值将覆盖默认乐观 并发并忽略 ETag 值中的任何不匹配。