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

什么是數據一致性

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

強一致性

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

弱一致性

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

最終一致性

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

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

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

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

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

以Amazon S3為例，其最初的應用場景多是數據歸檔，比如將一張商品圖片上傳到S3存儲做長期歸檔，后續只會預覽圖片而不會做其他修改。這種場景不要求“數據寫入立即可讀”，可以接受“不一致性窗口”的存在，而且犧牲一定的一致性可以換取更高的可用性，所以Amazon 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.應用端獲取到最新數據，強一致性得到保證。

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

MOS原生支持強一致性，為大數據提供強大底座

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

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

責任編輯：tzh