18、深入探索对象存储：并发更新与多部分上传

深入探索对象存储：并发更新与多部分上传

一、对象元数据与并发更新问题

在对象存储中，自定义键会添加 opc-meta- 前缀，以避免与标准元数据（如 content-length 或 content-type ）冲突。需要注意的是，对象是不可变的，如果要为存储桶中的对象添加新的元数据，就必须替换该对象，即使新版本的内容与旧版本相同。

并发更新时会出现竞态条件。假设有两个应用程序同时更新同一个对象，逐步添加各自的部分更改。若它们依次获取对象，将处理相同的基础版本，彼此都不知道有另一个应用程序也在并行处理该对象。直到两个应用程序都决定上传对象的新版本，替换基础版本时，问题才会显现。后更新的应用程序会覆盖先保存对象的应用程序所做的更改，这种情况称为丢失更新。

例如，在更改地下停车场地图，标记已售停车位的应用逻辑中，丢失更新会导致显示一些已售停车位仍为可用状态。为避免此类问题，对象存储 API 引入了实体标签（ETag）来实现乐观并发控制。每个对象版本都会生成一个 ETag，即使内容未变，每次上传也会生成不同的 ETag。

以下是一个示例代码，展示了两次上传同一对象生成不同 ETag 的情况：

$ head -c 8096 /dev/urandom > warsaw/bemowo/parking.pdf
$ oci os object put -bn blueprints --name waw/bemowo/parking.pdf --file warsaw/bemowo/parking.pdf