从 2006年第一个云服务对象存储服务 Amazon S3 发布直到 2020年12月1日之前，S3 对象操作都是遵循 “最终一致性”原则，对象存储服务本身就是一个复杂的分布式系统，但对用户暴露简单的 API 服务接口，无限扩展存储大小，极高的数据持久性(标准存储在一个区域多个可用区进行多份冗余存储)；对象存储服务已经成为数据和智能时代最重要的一个可靠“数据容器”，无论 AWS 自身的数据湖解决方案还是类似 Snowflake 新型的云数仓即服务的产品，后台都选择了 S3 作为数据存储；

- 1 -

数据一致性

2000年左右发表的 CAP 理论，即三选二，任何基于网络的数据共享系统最多满足数据一致性，高可用性，分区容忍性三要素的两个；而在一个大规模分布式系统中，网络分区是不可避免的，因此同时取得高可用和数据一致性就是一个非常大的挑战；导致有两种选择，一种平衡就是在发生网络分区时，牺牲一点数据一致性而保障系统高可用，或者优先保障数据一致性，牺牲系统可用性；最终一致性是满足大规模可扩展的分布式系统，在系统可用性和数据一致性中取得的一个平衡；

Werner Vogels 在2008年一篇博客中，强调数据一致性并不是一个绝对优先考虑的事情：

不一致是可以容忍的，一是可以在高并发条件下提高读写性能；二是处理一些分区状况——多数表决模型(majority model)有可能使系统的一部分表现为不可用，虽然那些节点正运行良好。

看待一致性有两个角度：一种是从用户/客户端视角，他们如何观察数据更新(可以用户是否感知到不一致)，另外一种是系统服务器角度，更新修改如何扩散到整个系统，系统对更新的保障；

假设我们的系统是一个大规模分布式系统，保证数据持久性和可用性，我们来理解下一致性问题，第一种维度，客户端/用户侧即观察者(可能多个)如何看到数据变更：

强一致性：在一次更新操作之后，所有的观察者看到一致的更新之后的值
弱一致性：系统不保证观察者后续访问都返回更新之后的值，通常需要满足一定的条件或前提，这个前提通常是经过一段时间，即不一致时间窗口
最终一致性：是弱一致性的一个特定表现，系统在该对象没有其它更新的情况下，最终所有的访问都返回最新的更新的值对象；如果没有故障发生，最长的不一致时间窗口，取决于通信延迟，系统负载大小，以及冗余的复制副本数量等等；

第二个维度，系统后台服务器角度来看数据一致性处理过程，假定 N 是服务器一个数据对象所有副本数量，W 是需要响应写成功的副本数量，R 是一次客户端读请求需要读取的数据副本数量；

如果 W+R > N ，写副本集合和读取的副本集合总是有重叠，也就是读操作一定包含最新的数据副本，就能保证强一致性；在一个实现同步复制的主从数据库系统中，N=2，W=2，R=1，无论客户端读到哪个副本，总能返回最新的数据值；但如果是一个异步复制的主从数据库系统，R+W=N，这种情况下，客户端读取从库数据就无法保证强一致性；
W+R <= N, 就会导致弱一致性/最终一致性，客户端就有可能从没有收到更新的节点(分区)读取数据；

更详细的数据一致性内容请阅读参考资料里面的内容；

- 2 -

S3 的一致性

原本的 S3 一致性符合如下原则：

通过 PUT 操作创建一个新对象(原本不存在)，返回成功响应后，任何客户端 GET 到的值都是一致的(该新建的对象值)(Read-After-Write 写后读一致性)
通过 PUT 操作更新一个已有对象，如上图，由于 S3 对象会有多份复制，服务端接受到该请求，到对象在多个位置完全复制完需要一段时间，在这段时间内，客户端 GET 到的值可能是旧值 “1” 或新值 “2”，等到所有副本都最终一致状态(同样的值)，后续客户端请求 GET 到的都是最新值 (Eventually consistent 最终一致性)
通过 DELETE 操作删除一个已有对象，也类似更新操作，S3 提供最终一致性保障，比如 DELETE 后立刻进行 LIST 对象操作，可能还能返回该对象 (Eventually consistent 最终一致性)
存储桶的创建和删除以及配置变更也是符合 (Eventually consistent 最终一致性)，比如启用版本控制，删除一个存储桶等操作
同一个 Key 的对象操作是符合 “原子性”原则，也就是任何特定 Key 的对象操作(PUT，DELETE等)，客户端要么读到旧值或新值，不会读到部分更新数据或中间状态的数据

很多场景，比如数据分析场景下，很多客户跑 Spark 或 Hive 任务，会有大量的文件新建和更新操作，加上分布式并行处理架构，S3 对象存储的最终一致性带来一些挑战，比如任务 B 依赖任务 A 的输出，而任务 A 的输出是保存到 S3 对象存储，当任务 A 结束，任务 B 启动时，有可能读不到依赖的输入或者读到的数据不完整；AWS 托管的 Hadoop 平台 EMR 提供了一致性视图来帮助客户透明解决该问题，通过外部的 DynamoDB 表来实现 S3 对象操作的 Read-After-Write 强一致性；开源社区针对 S3A 接口，提供了类似的 S3Guard 解决方案；

12月1日，在 2020 Reinvent 在线大会上， AWS 宣布 S3 默认支持对象的强一致性保障：

Amazon S3 现在可默认为所有应用程序提供强大的写后读强一致性。与其他云提供商不同，Amazon S3 可为任何存储请求提供强大的写后读一致性，而不会改变性能或可用性，同时不会牺牲应用程序的区域隔离，也无需额外成本

这彻底改写了 S3 的最终一致性模型：

所有 S3 对象的操作都支持写后读的强一致性，包括PUT(新建和更新)，LIST，DELETE操作，以及 S3 Select，S3 ACL List，S3 对象标签和元数据操作都自动适用，比如
- 一个客户端成功写入一个新对象，紧接着的读取或列表(List)操作都可以读到该新对象 (Read-After-Write)
- 一个客户端成功更新一个新对象，紧接着的读取或列表(List)操作都可以读到该新对象 (Read-After-Update)
- 一个客户端成功删除一个新对象，紧接着的读取或列表(List)操作都将读不到该对象 (Read-After-Delete)
存储桶的创建和删除以及配置变更依然符合 (Eventually consistent 最终一致性)，比如启用版本控制，删除一个存储桶等操作
对于并发操作，S3 并不支持对象锁，比如两个几乎同时的 PUT 操作，后到达的操作覆盖前面的操作

- 3 -

S3 对象操作和数据库 ACID差异

大家更熟悉的关系数据库领域的 ACID(原子性，一致性，隔离性和持久性) 中的 C(一致性)/ A(可用性)概念跟 CAP 又有所不同，强调事务结束数据库处于一致的状态，经典的场景比如从一个账号把钱转移到另外一个账号，两个账号金额的总数是保证不变；数据库中通常需要开发人员编写事务相关逻辑，再通过数据库来进行实现一致性约束；

那 S3 的对象操作从 ACID 模型的如何理解？

原子性：

原子性保证每个事务作为一个完整的单元，要么成功要么失败，对于 S3 某个对象，所有的操作都是原子操作，但不支持跨多个对象的原子操作，因为 S3不提供对象锁机制；

一致性：

强一致性确保事务只能将数据库从一种有效状态转移到另一个有效状态。S3 作为一个分布式系统，12月1日起支持对象/标签/元数据/ACL的 read-after-write, read-after-delete, read-after-update强一致性保障；

隔离性：

事务通常并发执行，同一时间多个事务同时读取或修改同一个表；隔离性确保事务的并发执行使数据库与按顺序执行事务时所获得的状态相同。数据库的隔离级别可以设定，分为未提交读(Read uncommitted)、已提交读(Read committed)、可重复读(Repeatable read)和可串行化(Serializable )四类，隔离级别由低到高；而数据库的锁机制也是为了满足实现并发的隔离性；

而对于用户/客户端读取数据而言，不同的隔离级别会产生脏读(Dirty Reads)、不可重复读(NonRepeatable Reads)和幻读(Phantom Reads)现象；

S3 类比处于可重复读(Repeatable read)隔离性阶段，客户端不会产生脏读现象，但会存在不可重复读和幻读现象；

持久性：

持久性确保，一旦事务被提交，即使在系统出现故障的情况下，事务仍将保持提交后的状态。这通常意味着已完成的事务(或其影响)会记录在非易失性存储器中；

S3 在这块比数据库要强非常多(11个9的持久性)，天然的分布式冗余存储，而且是同区域跨不同可用区复制(标准存储等)，哪怕一个底层数据中心的故障，数据持久性都不受影响；除此之外，S3 标准存储还提供了 99.99% 的可用性保障。

- 4 -

总结

虽然市场上，很多云服务玩家都已经支持对象存储的 Read-After-Write/Delete/Update 强一致性，但作为对象存储事实标准的 S3 上的实现是一个标志性事件，S3 这个更新建立在不牺牲性能，可用性，无额外成本的基础之上，任何客户在实现自身应用场景时，更简化和游刃有余，对象存储服务是云时代的开拓者，也是面向未来数据和智能时代的基石。