从 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 这个更新建立在不牺牲性能，可用性，无额外成本的基础之上，任何客户在实现自身应用场景时，更简化和游刃有余，对象存储服务是云时代的开拓者，也是面向未来数据和智能时代的基石。
参考资料
Explanation of The S3 Consistency Model
Amazon S3 data consistency model
Amazon S3 Update – Strong Read-After-Write Consistency
Consistency Models
Werner Vogels - Eventually Consistent
申明
本站点所有文章，仅代表个人想法，不代表任何公司立场，所有数据都来自公开资料，如有不妥的图片或内容请公众号“联系作者”
转载请注明出处
	

微博、微信、直播等互联网应用的风靡，带来了海量的图片、音频和视频文件，这些非结构化数据的容量、文件的数量已经超越了传统NAS存储的处理能力，因此各大互联网厂商根据自身特点发展出了适合业务需求的分布式存储架构，如：Google的GFS，亚马逊的AWS S3，以及FaceBook的Cassandra等等。特别是亚马逊2006年推出的AWS S3对象存储，其定义的S3接口已经逐渐成为非结构化数据存储的事实标准。
知名分析机构IDC的报告预测，到2020年非结构化存储数据量将达到410EB，相比2015年增长4倍，而对象存储占文件存储总容量的70%以上。报告显示，2015-2020年对象存储市场营收的年均复合增长率将达到8.7%。非结构化数据量的暴增及对象存储时代的到来，让企业用户越来越意识到对象存储技术的重要性，基于对象存储领域多年的实践经验，今天有幸和大家分享我的一些积累和见解。


图：杉岩数据CTO 邱尚高
传统NAS存储制约业务的发展
“互联网+”趋势的推进以及各类智能终端的普及，非结构化数据呈现出爆发性增长，如：金融业务办理的开户视频、互联网金融行业的申请资料、保险行业的理赔资料、快递行业的电子快递单、安防行业的视频监控录像等。同时，为了满足政策合规性，部分行业监管要求长时间保存以供查询取证。
如今，这些传统企业的IT部门正在经历着互联网公司曾经遭遇的NAS无法解决的存储难题，主要体现在如下方面：NAS存储采用古老的文件系统技术，单个文件系统容量受限，超过容量后对IT运维将带来巨大挑战;NAS存储的目录文件系统采用B+树进行文件索引，当文件数量过多时，会严重影响访问性能;NAS设备过维保后，由于非结构化数据规模较大，在更换时需要花费大量时间，且数据迁移存在风险等等。
那么，相对于传统NAS文件存储而言，对象存储到底可以带来哪些颠覆性的技术优势，接下来和大家做一些简单分享。
对象存储将成为企业存储的新标准
分布式去中心架构，容量和性能扩展方便
对象存储普遍采用的是基于通用x86服务器+分布式对象存储软件的技术架构，对象存储软件将多台服务器通过以太网连接，构建成一个统一的存储资源池，可动态增加或删除服务器实现容量的调整，数据能够自动均衡，并且利用副本和纠删机制(类似于RAID5/6)实现数据的高可靠和高可用性。
传统NAS过维保后，需要将过保设备上的数据人工迁移到新购置的NAS上，文件数量较多的用户需要花1到2个月时间，运维人力消耗非常大。而采用如下图所示的分布式架构，可以动态移除旧设备，无需人工干预，业务也不受影响。
创新的索引技术，真正解决海量小文件问题
海量小文件的存储是工业界和学术界公认的难题，解决问题较为关键的技术点就是优化元数据管理，由于传统NAS采用B+树进行文件检索，当文件数量比较少的时候，B+树基本可以被缓存，性能还是不错的。但随着文件数量的增多，B+树占用空间非常大无法被缓存时，就会涉及到机械盘操作导致性能明显下降，如果层级较深，仅仅索引访问就会产生多次磁盘随机访问操作，严重影响文件的访问性能。
而对象存储普遍采用了分布式哈希查找算法(DHT)，技术原理：在建立集群时，对象存储将整个存储空间划分成一个哈希环，每个磁盘负责哈希环中部分哈希分区的存储。当需要访问一个文件时，系统通过“目录/桶名+文件名”的哈希计算后，查询DHT表即可定位到具体磁盘进行文件访问。由于哈希环并不随文件数量的增加而增多，所以查找性能不会受到文件数量的影响。
超大容量单目录，满足业务生命周期存储需求
传统NAS存储采用文件系统技术，单个文件系统容量普遍在几十TB级。由于IT管理人员在业务上线前无法对规范容量和目录需求做出精准评估，对于某些产生数据量较大的业务系统来说，需要挂载多个文件系统目录，这会带来很多非增值的运维工作。
而对象存储采用扁平化的文件名唯一定位方式，单个目录或者存储空间能达到数十PB甚至数百PB级，可以满足业务系统整个生命周期的存储容量需求，无需挂载目录和调整业务系统，让IT人员更加关注业务价值本身。
更加适用于多数据中心容灾场景
高效的业务系统容灾方案是企业IT部门最为关注的焦点之一。对象存储在接口方面的技术改良，使其在多数据中心容灾方面支持得更加完善，大部分对象存储厂商都支持两个及以上的多数据中心容灾。传统NAS往往是主备模式的容灾，而对象存储普遍支持Active-Active模式的容灾，可实现本地数据中心应用的就近访问。这对于采用负载均衡模式数据中心的企业来说，是非常有价值的，可以提升每个数据中心业务系统的访问性能。
实现私有云和公有云间的数据流通
随着企业互联网业务的发展，越来越多的应用运行在智能终端和公有云平台上，而考虑到安全性和保密性，数据依然保存在企业内部。传统NAS的CIFS/NFS协议只能被企业内网访问，无法直接提供给外部网络。对象存储最早被应用在互联网和公有云场景，所以对象存储的访问协议(S3、SWIFT)都是基于HTTP标准协议，可支持内网和外网应用系统对存储的自由访问。
在安全性方面，数据采用AES进行加密传输，支持HTTPS保证传输链路安全。S3协议还定义了完整的多租户访问、文件粒度的授权访问等多种安全技术，保证了数据开放给外网访问的安全性。
关于应用对象存储技术的一些建议
匹配对象存储典型的应用场景
传统文件存储主要有两种使用场景：一种是在线编辑场景，如媒资行业的现编系统存储，另一种是非在线编辑场景，主要是满足归档和查询需求，不需要对文件内容进行修改。在实际应用中，非在线编辑场景占数据总容量的80%以上。对象存储接口能够完全满足非在线编辑场景的需求，因此在此类场景中用户可以完全替换掉传统NAS。为了让用户更好地匹配对象存储的关键应用场景，我们做了如下总结：
1)文件数量特别多，访问性能受到影响的场景。例如：银行的影像资料、保险的电子保单、快递的电子快递单等等，对象存储可以保证在这种场景下的访问性能。
2)数据存储量特别大，需要长期保存的场景。例如：金融行业的双录、医疗行业的影像资料、提供客服中心服务的语音资料等等，利用对象存储的弹性扩展能力以及超大容量目录，保证业务系统整个生命周期不需要做任何变更。
3)互联网业务的使用场景，例如：互联网金融相关业务，对象存储可以实现互联网应用对企业内部文件的安全访问，让数据在企业内部和互联网间高效流动。
4)多数据中心共享场景，例如：跨地域的文件共享、总部与分支机构文件的共享与归集等应用场景。
重视厂商的技术服务能力
虽然AWS S3协议已成为对象存储的事实标准，其数据访问接口相对传统文件系统访问接口更加简单。但由于S3接口相比NAS提供更加丰富的功能，包括：权限管理、租户管理、标签、外链、配额、多版本、生命周期、多数据中心策略等上百个API接口，如何充分利用好这些接口，帮助业务系统提高数据安全性、优化业务性能、优化存储管理、优化多数据中心访问方式和存储策略等方面，可能需要有对象存储部署经验的厂商来协助。
因此，我们建议在引入对象存储技术的同时，用户应该更多地关注厂商对于应用开发技术的服务能力，实现对象存储部署价值的最大化。
【关于杉岩数据】企业级软件定义存储(SDS)方案和服务提供商，“+存储”理念的倡导者和践行者，由来自世界500强企业的专业存储团队为技术班底组成。帮助企业级用户轻松应对IT向云迁移的存储挑战，为大数据时代的商业决策提供智能存储。

对象存储OSS(Object Storage Service)是阿里云提供的海量、安全、低成本、高持久的云存储服务。其数据设计持久性不低于99.9999999999%(12个9)，服务设计可用性不低于99.995%。OSS具有与平台无关的RESTful
API接口，您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
标准存储类型
高持久、高可用、高性能的对象存储服务，支持频繁的数据访问。是各种社交、分享类的图片、音视频应用、大型网站、大数据分析的合适选择。
低频访问存储类型
适合长期保存不经常访问的数据(平均每月访问频率1到2次)。存储单价低于标准类型，适合各类移动应用、智能设备、企业数据的长期备份，支持实时数据访问。
归档存储类型
适合需要长期保存(建议半年以上)的归档数据，在存储周期内极少被访问，数据进入到可读取状态需要1分钟的解冻时间。适合需要长期保存的档案数据、医疗影像、科学资料、影视素材。
冷归档存储类型
适合需要超长时间存放的极冷数据。例如因合规要求需要长期留存的数据、大数据及人工智能领域长期积累的原始数据、影视行业长期留存的媒体资源、在线教育行业的归档视频等。
适用场景
OSS适用于以下场景：
静态网站内容和音视频的存储与分发
每个存储在OSS上的文件(Object)都有唯一的HTTP URL地址，用于内容分发。同时，OSS还可以作为内容分发网络(CDN)的源站。由于无需分区，OSS尤其适用于托管那些数据密集型、用户生产内容的网站，如图片和视频分享网站。各种终端设备、Web网站程序、移动应用可以直接向OSS写入或读取数据。OSS支持流式写入和文件写入两种方式。
静态网站托管
作为低成本、高可用、高扩展性的解决方案，OSS可用于存储静态HTML文件、图片、视频、JavaScript等类型的客户端脚本。
计算和分析的数据存储仓库
OSS的水平扩展性使您可以同时从多个计算节点访问数据而不受单个节点的限制。
数据备份和归档
OSS为重要数据的备份和归档提供高可用、可扩展、安全可靠的解决方案。您可以通过设置生命周期规则将存储在OSS上的冷数据自动转储为低频或者归档存储类型以节约存储成本。您还可以使用跨区域复制功能在不同地域的不同存储空间之间自动异步(近实时)复制数据，实现业务的跨区域容灾。
性能
如果您的云服务器ECS和对象存储OSS在同一个地域，那么通过云服务器ECS访问对象存储OSS中的数据理论上是最快的。OSS的设计也使其服务端延迟相对于网络延迟来讲可以忽略不计。此外，OSS对于存储量、请求数和用户数的扩展特性，使其可以很好的支持大量Web级应用程序。如果您使用多线程、多个应用程序或多个客户端同时访问OSS，总的OSS聚合吞吐量通常会扩展到远超任何单个服务器可以生成或消耗的速率。
为了提升大文件(5 GB以上)的上传性能，阿里云OSS提供分片上传(Multipart Upload)功能，将要上传的Object分成多个数据块(Part)来分别上传，上传完成之后再将这些Part组合成一个Object来达到断点续传的效果。分片上传适用于网络条件不佳的场景，当出现上传失败的时候，可以对失败的Part进行独立的重试，而不需要重新上传整个Object。
为了提升数据访问速度，许多开发者会将OSS和搜索引擎(如开放搜索OpenSearch)或数据库(如表格存储、云数据库RDS)搭配使用。OSS用于存储实际的数据，而搜索引擎或数据库用于存储元信息，如文件名称、大小、关键词等。数据库中存储的元信息很容易被索引和查询。OSS和搜索引擎或数据库结合使用可用于精确定位和检索OSS中的文件。
为了提升远距离大文件的上传下载体验，满足文件动态更新、非热点文件的下载加速需求，OSS还提供
对于静态热点文件的下载加速场景，OSS支持开启阿里云CDN加速服务。阿里云CDN将OSS的Bucket作为源站，将源内容发布到边缘节点。阿里云CDN配合精准的调度系统，将用户的请求分配至最适合的节点，使终端用户以最快的速度读取到所需的内容，有效解决Internet网络拥塞状况，提高用户访问的响应速度。
数据持久性和服务可用性
OSS提供的三种存储类型中，标准类型(Standard)和低频访问类型(Infrequent Access)通过自动同步提供。OSS采用多可用区(AZ)机制，将用户的数据分散存放在同一地域(Region)的3个可用区。当某个可用区不可用时，仍然能够保障数据的正常访问。OSS同城3AZ能够提供99.9999999999%(12个9)的数据持久性以及99.995%的数据可用性。
您还可以针对存储空间启用跨区域复制功能。启用后，不同地域的不同存储空间之间将实现自动异步(近实时)复制数据，实现跨区域容灾需求。源存储空间和目标存储空间均提供99.9999999999%(12个9)的数据持久性以及99.995%的数据可用性。
扩展性和弹性
OSS提供高扩展性和弹性。普通的文件系统如果在同一目录下存放太多文件，经常会出现问题。而OSS总的存储容量以及单个存储空间的容量均无上限。您可以在一个存储空间内存放无限量的文件，OSS自动将您的数据副本存储至同一地域的不同服务器，所有数据副本共享阿里云的高性能基础设施能力。
安全性
阿里云对象存储OSS(Object Storage Service)具有丰富的安全防护能力，支持服务端加密、客户端加密、防盗链白名单、细粒度权限管控、日志审计、合规保留策略(WORM)等特性。OSS是目前中国国内唯一通过Cohasset
Associates审计认证的云服务，可满足严格的电子记录保留要求，例如SEC Rule 17a-4(f)、FINRA 4511、CFTC 1.31等合规要求。关于OSS安全能力的详细介绍，请参见
接口
OSS提供标准的RESTful API接口，您可以使用API接口将文件(Object)存储在存储空间(Bucket，顶级文件夹)中，存储空间的名称全局唯一。每个文件有一个Object
Key(文件名)，作为该文件在该存储空间中的唯一标识。OSS没有文件夹的概念，所有元素都是以文件来存储，但是您可以通过创建以正斜线(/)结尾的文件名(如folder1/folder2/file)来模拟文件夹。
开发者一般使用工具或封装了API接口的SDK来开发应用。OSS目前提供包括Java、Python、PHP、Go、Android、iOS在内的
您还可以使用事件通知功能，及时了解您OSS资源上的相关操作。详情请参见
费用模型
OSS的服务费用由存储费用、流量费用、请求费用、数据处理费用等组成。OSS开通后默认为按量计费，即按实际使用量*单价的方式计费，每小时统计前一小时的实际用量并从账户余额中扣除实际消费金额。针对部分计费项，您还可以使用包年包月的计费方式，进一步降低费用。包年包月即预先购买指定资源包，之后使用资源时，扣除相应的额度。详情请参见

1. 块存储

主要给虚拟机用的，包括数据库，将裸磁盘空间映射给主机使用。 创建虚拟机的时候create image，其实是直接将一块磁盘的一部分空间映射出来当做虚拟机的使用空间。 优点在于速度块，缺点在于共享。

 

2. 文件存储

支持标准的POSIX接口，传统的FTP即是。优点在于共享方便，但是速度慢。

 

3. 对象存储

综合1,2的优点。K、V模式。但是需要部署管理软件。支持put/get/delete 等接口，无法随机读取，无目录树概念。