在2020年最后一個(gè)月的第一天，AWS官方博客發(fā)布文章稱：Amazon S3實(shí)現(xiàn)了原生支持強(qiáng)一致性。從2006年上線至今，Amazon S3一直采用最終一致性的實(shí)現(xiàn)方案。14年來，隨著上層業(yè)務(wù)類型從簡單的數(shù)據(jù)歸檔擴(kuò)展到更為復(fù)雜的數(shù)據(jù)分析場景，存儲(chǔ)模型由基本的寫入讀取升級(jí)為更多數(shù)據(jù)覆蓋寫且時(shí)效性要求更高的遍歷讀取，Amazon S3的最終一致性方案已經(jīng)無法滿足這一需求。尤其是以Hadoop為代表的大數(shù)據(jù)分析場景，要求數(shù)據(jù)寫入之后快速讀取，底層存儲(chǔ)支持強(qiáng)一致性成為剛需。

什么是數(shù)據(jù)一致性

從數(shù)據(jù)讀寫的角度，如果前一刻寫入新數(shù)據(jù)，后續(xù)某個(gè)時(shí)間能準(zhǔn)確讀到最新數(shù)據(jù)，這時(shí)我們說數(shù)據(jù)是一致的。按照寫入新數(shù)據(jù)和準(zhǔn)確讀到新數(shù)據(jù)的時(shí)間窗口（即不一致窗口）長短，分為強(qiáng)一致性、弱一致性和最終一致性。

強(qiáng)一致性

數(shù)據(jù)一致性最理想的情況是，無論數(shù)據(jù)何時(shí)被更新，用戶總能立即讀取到最新的數(shù)據(jù)，這叫強(qiáng)一致性。這種是對用戶最友好的，就是用戶上一次寫什么，下一次就保證能讀到什么。

弱一致性

強(qiáng)一致性之外統(tǒng)稱為弱一致性，即數(shù)據(jù)更新之后，無法保證用戶能立即讀到最新數(shù)據(jù)，但是一段時(shí)間之后可以讀到最新數(shù)據(jù)。遺憾的是，弱一致性沒有保證不一致窗口到底有多長。

最終一致性

弱一致性中有一個(gè)特例——最終一致性，它限定了不一致性窗口的時(shí)間，保證用戶最終一定能讀取到正確數(shù)據(jù)。

應(yīng)用端寫入內(nèi)容為“1”的對象，寫完后讀到正確的“1”；之后覆蓋寫入“2”，這時(shí)讀取操作就會(huì)遭遇不一致窗口，應(yīng)用端可能讀到舊數(shù)據(jù)“1”；但最終一致性能夠保證過了不一致窗口，應(yīng)用端能讀取到正確的“2”。Amazon S3最初就是采用最終一致性方案。

為什么不能用強(qiáng)一致性解決一切？

看完前面內(nèi)容，有人可能會(huì)問：既然強(qiáng)一致性無“死角”，那所有的分布式系統(tǒng)為啥不都采用強(qiáng)一致性？強(qiáng)如Amazon S3竟也要退而求其次選擇最終一致性呢？這就不得不提分布式領(lǐng)域那個(gè)如雷貫耳的原理——CAP原理。

CAP原理是指在一個(gè)分布式系統(tǒng)中，C（Consistency：一致性）、A（Availability：可用性）、P（Partitiontolerance：分區(qū)容錯(cuò)性）這三個(gè)要素最多同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。而對于分布式系統(tǒng)，分區(qū)容忍性是基本要求，否則就失去了價(jià)值。因此在設(shè)計(jì)分布式系統(tǒng)時(shí)，就只能在一致性和可用性之間做平衡。如果一味追求強(qiáng)一致性，就無法保證數(shù)據(jù)的可用性了。

以Amazon S3為例，其最初的應(yīng)用場景多是數(shù)據(jù)歸檔，比如將一張商品圖片上傳到S3存儲(chǔ)做長期歸檔，后續(xù)只會(huì)預(yù)覽圖片而不會(huì)做其他修改。這種場景不要求“數(shù)據(jù)寫入立即可讀”，可以接受“不一致性窗口”的存在，而且犧牲一定的一致性可以換取更高的可用性，所以Amazon S3采用了最終一致性的方案。

大數(shù)據(jù)分析場景，為何強(qiáng)一致性成為剛需？

為什么需要強(qiáng)一致性？

在大數(shù)據(jù)分析場景下，數(shù)據(jù)持續(xù)高并發(fā)讀寫，數(shù)據(jù)寫入成功即被計(jì)算程序立即讀取，計(jì)算程序讀不到準(zhǔn)確數(shù)據(jù)就會(huì)導(dǎo)致計(jì)算結(jié)果不準(zhǔn)確或不可信。因此，存儲(chǔ)系統(tǒng)必須要保證數(shù)據(jù)的強(qiáng)一致性。

Amazon S3是如何解決強(qiáng)一致性問題的？

以Amazon S3對接Hadoop為例，解決方式之一是增加額外的組件S3 Guard，由S3 Guard內(nèi)部的Metadata Store來單獨(dú)記錄元數(shù)據(jù)的改動(dòng)，以確保強(qiáng)一致性。具體流程大致如下：

1.假設(shè)當(dāng)前Budget A目錄下有文件“File A”，此時(shí)在相同目錄下新建文件“File B”；

2.S3內(nèi)部不會(huì)立即更新元數(shù)據(jù)信息（因?yàn)镾3采用最終一致性），在額外增加的Metadata Store中，元數(shù)據(jù)信息會(huì)被立即更新；

3.“File B”創(chuàng)建后，應(yīng)用端對目錄執(zhí)行l(wèi)ist操作；

4.S3 Guard將同時(shí)向S3和Metadata Store查詢元數(shù)據(jù)并進(jìn)行結(jié)果匯總，向應(yīng)用端返回最新數(shù)據(jù)狀態(tài)；

5.應(yīng)用端獲取到最新數(shù)據(jù)，強(qiáng)一致性得到保證。

雖然通過S3 Guard來確保一致性，但這顯然增加了系統(tǒng)的復(fù)雜性以及部署S3 Guard產(chǎn)生的額外成本。有沒有更好的方案呢？

MOS原生支持強(qiáng)一致性，為大數(shù)據(jù)提供強(qiáng)大底座

作為私有化部署的對象存儲(chǔ)產(chǎn)品，杉巖MOS在設(shè)計(jì)之初就考慮到了復(fù)雜場景的業(yè)務(wù)需求，原生支持強(qiáng)一致性方案，MOS可直接對接Hadoop平臺(tái)而無需類似S3 Guard這樣的額外組件，消除了額外成本，而且架構(gòu)更加簡單。

MOS作為大數(shù)據(jù)應(yīng)用的數(shù)字底座，無縫兼容Hadoop、Spark等主流平臺(tái)，并針對大數(shù)據(jù)場景的業(yè)務(wù)特點(diǎn)，在多個(gè)層面進(jìn)行了方案優(yōu)化：S3接口原生支持?jǐn)?shù)據(jù)強(qiáng)一致性，確保計(jì)算結(jié)果準(zhǔn)確可信；基于數(shù)據(jù)內(nèi)容感知和強(qiáng)大的元數(shù)據(jù)管理能力，加速數(shù)據(jù)預(yù)?。灰环輸?shù)據(jù)能夠同時(shí)提供給多個(gè)計(jì)算流程使用，提升分析效率。MOS為數(shù)據(jù)分析和智能應(yīng)用帶來極大便利，無疑是企業(yè)應(yīng)對大數(shù)據(jù)挑戰(zhàn)、實(shí)現(xiàn)數(shù)字化升級(jí)的得力幫手。

責(zé)任編輯：tzh