先于Amazon S3支持强一致性，这款产品值得了解一下

2020年最后一个月的第一天，AWS官方博客发布文章称：Amazon S3实现了原生支持强一致性。从2006年上线至今，Amazon S3一直采用最终一致性的实现方案。14年来，随着上层业务类型从简单的数据归档扩展到更为复杂的数据分析场景，存储模型由基本的写入读取升级为更多数据覆盖写且时效性要求更高的遍历读取，Amazon S3的最终一致性方案已经无法满足这一需求。尤其是以Hadoop为代表的大数据分析场景，要求数据写入之后快速读取，底层存储支持强一致性成为刚需。 

从数据读写的角度，如果前一刻写入新数据，后续某个时间能准确读到最新数据，这时我们说数据是一致的。按照写入新数据和准确读到新数据的时间窗口（即不一致窗口）长短，分为强一致性、弱一致性和最终一致性。

数据一致性最理想的情况是，无论数据何时被更新，用户总能立即读取到最新的数据，这叫强一致性。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。

强一致性之外统称为弱一致性，即数据更新之后，无法保证用户能立即读到最新数据，但是一段时间之后可以读到最新数据。遗憾的是，弱一致性没有保证不一致窗口到底有多长。

弱一致性中有一个特例——最终一致性，它限定了不一致性窗口的时间，保证用户最终一定能读取到正确数据。

图1.图解最终一致性

如图所示，应用端写入内容为“1”的对象，写完后读到正确的“1”；之后覆盖写入“2”，这时读取操作就会遭遇不一致窗口，应用端可能读到旧数据“1”；但最终一致性能够保证过了不一致窗口，应用端能读取到正确的“2”。Amazon S3最初就是采用最终一致性方案。

看完前面内容，有人可能会问：既然强一致性无“死角”，那所有的分布式系统为啥不都采用强一致性？强如Amazon S3竟也要退而求其次选择最终一致性呢？这就不得不提分布式领域那个如雷贯耳的原理——CAP原理。

CAP原理是指在一个分布式系统中，C（Consistency：一致性）、A（Availability：可用性）、P（Partitiontolerance：分区容错性）这三个要素最多同时实现两点，不可能三者兼顾。而对于分布式系统，分区容忍性是基本要求，否则就失去了价值。因此在设计分布式系统时，就只能在一致性和可用性之间做平衡。如果一味追求强一致性，就无法保证数据的可用性了。

图2：CAP原理

以Amazon S3为例，其最初的应用场景多是数据归档，比如将一张商品图片上传到S3存储做长期归档，后续只会预览图片而不会做其他修改。这种场景不要求“数据写入立即可读”，可以接受“不一致性窗口”的存在，而且牺牲一定的一致性可以换取更高的可用性，所以Amazon S3采用了最终一致性的方案。

在大数据分析场景下，数据持续高并发读写，数据写入成功即被计算程序立即读取，计算程序读不到准确数据就会导致计算结果不准确或不可信。因此，存储系统必须要保证数据的强一致性。

以Amazon S3对接Hadoop为例，解决方式之一是增加额外的组件S3 Guard，由S3 Guard内部的Metadata Store来单独记录元数据的改动，以确保强一致性。具体流程大致如下：

1.假设当前Budget A目录下有文件“File A”，此时在相同目录下新建文件“File B”；

2.S3内部不会立即更新元数据信息（因为S3采用最终一致性），在额外增加的Metadata Store中，元数据信息会被立即更新；

3.“File B”创建后，应用端对目录执行list操作；

4.S3 Guard将同时向S3和Metadata Store查询元数据并进行结果汇总，向应用端返回最新数据状态；

5.应用端获取到最新数据，强一致性得到保证。

图3.通过S3 Guard的方式保证强一致性

虽然通过S3 Guard来确保一致性，但这显然增加了系统的复杂性以及部署S3 Guard产生的额外成本。有没有更好的方案呢？

作为私有化部署的对象存储产品，杉岩MOS在设计之初就考虑到了复杂场景的业务需求，原生支持强一致性方案，MOS可直接对接Hadoop平台而无需类似S3 Guard这样的额外组件，消除了额外成本，而且架构更加简单。

图4.MOS支撑大数据应用，架构更简单

MOS作为大数据应用的数字底座，无缝兼容Hadoop、Spark等主流平台，并针对大数据场景的业务特点，在多个层面进行了方案优化：S3接口原生支持数据强一致性，确保计算结果准确可信；基于数据内容感知和强大的元数据管理能力，加速数据预取；一份数据能够同时提供给多个计算流程使用，提升分析效率。MOS为数据分析和智能应用带来极大便利，无疑是企业应对大数据挑战、实现数字化升级的得力帮手。