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

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

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

強一致性

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

弱一致性

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

最終一致性

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

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

為什么不能用強一致性解決一切？

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

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

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

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

為什么需要強一致性？

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

Amazon S3是如何解決強一致性問題的？

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

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

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

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

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

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

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

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

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

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

責(zé)任編輯：tzh