对象业务的修改数据接口

依据AWS S3，没有定义修改数据的操作，修改数据时，均需要重新上传对象的数据和元数据。

本文有如下假定：

• 对象存储服务基于文件语义实现。

接口定义

依据前述，业界主流对象存储服务比如AWS S3并未定义修改对象数据的操作，而国内的各家公有云对象存储服务，提供了对象的修改对象数据的操作。

国内的公有云对象存储服务，相关操作的文档的链接（排名不分先后），如下：

• 华为云OBS

以华为云OBS的修改写对象为例，接口定义如下：

PUT /ObjectName?modify&position=Position HTTP/1.1
Host: bucketname.obs.region.myhuaweicloud.com
Content-Type: type
Content-Length: length
Authorization: authorization
Date: date
<object Content>

本接口的关键参数，如下：

• 对象名，指定修改数据的对象名。
• 操作名，参数名为modify，不需要指定参数值。
• 修改位置，参数名为position，依据实际情况指定。
• 操作指标，HTTP头部Content-Length，本次操作修改的数据的长度。

实现思路

修改数据的范围

对于普通对象，即使用PUT或者复制方式上传的对象，对象大小的范围为[1, 5GiB]，因此

• 假如position的位置小于1或者大于5GiB，则校验失败。
• 假如Content-Length的取值小于1或者大于5GiB，则校验失败。
• 假如position和Content-Length的和大于5GiB，则校验失败。

对于使用多段方式上传的对象，涉及的API，如下：

• CreateMultipartUpload
• UploadPart
• UploadPartCopy
• CompleteMultipartUpload

段的数量上限为10000，每个段大小的范围为[1, 5GiB]，因此对象整体的范围可到达到[1, 48.8TiB]，因此

• 假如position的位置小于1或者大于48.8TiB，则校验失败。
• 假如Content-Length的取值小于1或者大于48.8TiB，则校验失败。
• 假如position和Content-Length的和大于48.8TiB，则校验失败。

对象大小的规格，参见AWS S3文档。

ETag

参考AWS S3数据一致性，ETag基于对象的数据，使用MD5算法计算得到。

服务端校验数据一致的流程

• 客户端使用本次上传的数据，基于MD5算法计算得到MD5值X1。
• 客户端在请求中附带的Content-MD5为使用本次数据计算到的MD5值X1。
• 对象存储服务端收到数据后，基于MD5算法计算得到本次操作的MD5值X2。
• 服务端执行MD5值X1和X2的比较。
  • 二者一致，则判定数据一致，本次写入操作成功。
  • 二者不一致，则判定数据不一致，本次写入操作失败。
• 服务端在返回的响应中增加ETag字段，使用服务端计算的MD5值X2填充。

客户端校验数据一致的流程

• 客户端发起请求，并在读数据、写数据的过程中，使用本次上传的数据，基于MD5算法计算得到MD5值X1。
• 对象存储服务端收到数据后，基于MD5算法计算得到本次操作的MD5值X2。
• 服务端在返回的响应中增加ETag字段，使用服务端计算的MD5值X2填充。
• 客户端使用本地计算的X1和服务端返回的ETag进行比较。
  • 二者一致，则判定数据一致，本次写入操作成功。
  • 二者不一致，则判定数据不一致，本次写入操作失败。考虑到服务端已成功写入，因此需要增加必要的修复措施。

服务端对象的MD5值
由于变更了部分数据，因此对象的ETag值和数据已不一致，需要设计补救方案。

对于普通对象，即使用PUT或者复制方式上传的对象，考虑在后台任务中读取全量数据，计算对象数据的MD5值，保存至ETag字段的值保存下来。

对于使用多段方式上传的对象，涉及的API，如下：

• CreateMultipartUpload
• UploadPart
• UploadPartCopy
• CompleteMultipartUpload

依据Checking object integrity的介绍，该类对象的ETag值样例为C9A5A6878D97B48CC965C1E41859F034-14，由所有的段的MD5值计算得到，因此修复操作相对复杂一些。

• 依据修改点起始位置position和Content-Length计算涉及变化的段的清单。
• 依据最新的数据，计算涉及变化的段的MD5值。
• 使用所有的段的MD5值，按照多段对象的ETag值的生成规则，重新计算，得到最终的结果。

对象存储服务在实现时，有如下需求：

• 多段对象的系统元数据中保留所有的段的清单。
• 段的元数据中记录自身的MD5值，数据的起始位置、段的长度。

多版本

按照AWS S3多版本中的说明，多版本特性的开关作用在桶级，包含如下状态：

Buckets can be in one of three states:

• Unversioned (the default)
• Versioning-enabled
• Versioning-suspended

接口定义中未提供versionId，因此只支持修改当前版本，不支持修改历史版本。

分级

参考AWS S3 归档和AWS S3 分级中的说明，处于归档状态的对象，需要先取回才能访问。
显而易见，此处为了维护对象语义，照顾对象存储服务的实现，当对象处于归档状态时，不允许更新对象的数据。

WORM

参考AWS S3 Object Lock中的说明，开启WORM后：

• 在保护期内的对象，不允许修改，不允许删除。
• 在保护期外的对象，不允许修改，允许删除。

因此从维护对象语义的角度讲，在保护期内的对象、保护期外的对象，均不允许修改对象的数据。

生命周期

参考AWS S3 Lifecycle，修改元数据操作的对象可能符合生命周期规则，从而被恰好正在运行的后台任务删除掉。
此时有如下选择：

• 生命周期的后台任务具备更高的优先级，提前中断操作，正常删除掉对象，对象存储服务对客户应用返回操作失败。
• 生命周期的后台任务优先级相对较低，跳过当前对象，待下次运行时再决策是否删除。

数据加密

依据SSE-C的说明，客户应用在执行PUT/GET/Head/Copy操作时，均需要提供加密数据的密钥。

即在发起请求时，提供如下头部：

• x-amz-copy-source​-server-side​-encryption​-customer-algorithm
• x-amz-copy-source​-server-side​-encryption​-customer-key
• x-amz-copy-source-​server-side​-encryption​-customer-key-MD5

由于需要先解密数据、修改数据、再加密数据，本特性在实现时，成本要高不少。
为降低修改数据的范围，对象存储内部实现时，可以将数据切割成固定大小的块，这样可以有如下好处：

• 修改数据时，仅处理受影响的块。
• 涉及修改的块，读取、解密、修改、加密、保存等操作，可以并发执行，改善体验。
• 不涉及修改的块，不需要执行解密操作，节约算力和时间。

事件通知

依据AWS S3 事件通知中的说明，对象存储服务可以提供事件通知，目前支持的事件类型见文档，显然不包括修改元数据操作，可以扩展事件名，比如s3:ObjectDataUpdated:Put。

并发一致性

依据AWS S3 data consistency model的说明，对象存储服务提供read-after-write的模型。

当多客户端对相同对象并发的发起修改数据的操作时，参照文件语义，提供最终一致性。