寫入任何區域模式 (無優先層級) - AWS 規定指引

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

寫入任何區域模式 (無優先層級)

寫入任何區域寫入模式是完全主動-主動的,並且不會對可能發生寫入操作的位置施加限制。任何地區都可以隨時接受寫入請求。這是最簡單的模式;不過,它只能用於某些類型的應用程式。當所有寫操作都是冪等的時候,這是合適的。冪等意味著它們可以安全地重複,以便跨區域的並發或重複寫入操作不會發生衝突,例如,當用戶更新其聯繫人數據時。它也適用於僅附加數據集,其中所有寫操作都是確定性主鍵下的唯一插入,這是冪等的特殊情況。最後,此模式適用於可接受衝突寫入操作的風險。

無主要寫入模式

寫入任何區域模式是最直覺式的實作架構。因為任何區域都可以隨時成為寫入目標,路由會更加容易。容錯移轉比較容易,因為任何最近的寫入作業都可以重新顯示到任何次要區域。盡可能之下,您應該以此為寫入模式進行設計。

例如,數個影片串流服務會使用全域資料表來追蹤書籤、評論、觀看狀態旗標等。這些部署可以使用寫入任何區域模式,只要它們確保每個寫入作業都是冪等的。如果每次更新 (例如設定新的最新時間碼、指派新的審核或設定新的監看狀態) 都會直接指派使用者的新狀態,而項目的下一個正確值並不取決於其目前的值。如果偶然的情況下,用戶的寫入請求被路由到不同的區域,最後一個寫操作將持續,並且全局狀態將根據最後的分配結算。此模式下的讀取作業最終會變得一致,因為最新ReplicationLatency值會延遲。

在另一個範例中,一家金融服務公司使用全域資料表作為系統的一部分來維護每個客戶使用借記卡購買的動作記錄,以計算該客戶的現金回饋獎勵。新的交易會從世界各地進行串流並前往多個區域。該公司能夠在仔細重新設計的情況下使用寫入任何區域模式。初始設計草圖為每位客戶保留一個RunningBalance項目。客戶動作會使用不是冪等的運ADD算式更新餘額 (因為新的正確值取決於目前值),而且如果在不同區域中大約同時有兩個相同餘額的寫入作業,則餘額不同步。重新設計使用事件串流,其運作方式類似於具有僅附加工作流程的分類帳。每個客戶動作都會將新項目新增到為該客戶維護的項目收集器。(項目集合是共用主索引鍵但具有不同排序索引鍵的項目集合。) 每個寫入作業都是冪等插入,使用客戶 ID 做為分割索引鍵,而交易 ID 做為排序索引鍵。這種設計使得平衡的計算更加困難,因為它需Query要拉動項目,然後跟一些客戶端數學,但它使所有寫操作都是冪等的,並實現了路由和故障轉移的顯著簡化。本主題後續的「」。

第三個範例是提供線上廣告刊登位置服務的公司。該公司決定為了實現寫入任何區域模式的設計簡化,可以接受低資料遺失風險。當他們投放廣告時,他們只需幾毫秒就能擷取足夠的中繼資料來決定要顯示哪些廣告,然後記錄廣告曝光次數,這樣他們就不會很快重複相同的廣告。他們使用全域資料表來取得全球使用者的低延遲讀取作業,以及低延遲寫入作業。它們會在單一項目中記錄使用者的所有廣告曝光次數,表示為不斷增長的清單。他們使用一個項目而不是附加到項目集合中,因此可以在每次寫入操作中刪除較舊的廣告曝光,而無需支付刪除操作費用。這項寫入作業不是冪等的;如果同一位使用者看到在多個區域放送的廣告大約在同一時間,一個寫入作業的廣告曝光可能會覆寫另一個區域。風險是用戶可能會偶爾看到一次重複的廣告。他們認為這是可以接受的。