從 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

申明

本站點所有文章，僅代表個人想法，不代表任何公司立場，所有數據都來自公開資料，如有不妥的圖片或內容請公眾號“聯系作者”

轉載請注明出處

總結

以上是生活随笔為你收集整理的马逊s3云存储接口_当对象存储“湖”有了强一致性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。