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

使用 DynamoDB 全域資料表的寫入模式

全域表在資料表永遠處於主動-主動資料表層級。不過，您可能想要透過控制路由，將它們用作主動-被動的方式。例如，您可能決定將寫入請求路由到單一區域，以避免潛在的寫入衝突。

受管寫入模式有三種主要分類：

您應該考慮哪種寫入模式適合您的使用案例。此選項會影響您的路由請求、疏散區域以及處理災難復原的方式。整體最佳實務可能會因應用程式的寫入模式而有所不同。

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

寫入任何區域模式是完全主動-主動的方式，並且不會任何寫入位置施加限制。任何區域隨時可以接受寫入。這是最簡單的模式。只能適用於某些類型的應用程式。非常適用於所有寫入器都是等冪性時，因為可以安全地複寫，以便跨區域並行進行或重複寫入操作時不會發生衝突。例如，使用者更新其聯絡資料。這種模式也適用於等冪性的特殊情況 (一個僅能新增的資料集)，其中所有寫入都是確定性主索引鍵下的唯一插入。最後，此模式非常適合可以接受寫入衝突風險的情況之下。

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

例如，影片串流服務通常會使用全域資料表來追蹤書籤、評論、觀看狀態旗標等。這些部署可以使用寫入任何區域模式，只需確保每次寫入都是等冪性，並且項目的下一個正確值不依賴於其目前的值。對於直接指派使用者新狀態的使用者更新，例如，設定最新的時間代碼、指派新的審核或設定新的監看狀態，就會發生這種情況。如果使用者的寫入請求被路由到不同的區域，最後一個寫入操作將持續，並且全域狀態將根據最後的指派進行結算。在最後延遲 ReplicationLatency 值之後，此模式下的讀取操作最終會變成一致。

在另一個範例中，一家金融服務公司使用全域資料表作為系統的一部分來維護每個客戶使用借記卡購買的動作記錄，以計算該客戶的現金回饋獎勵。新的交易會從世界各地進行串流並前往多個區域。對於目前未利用全域資料表的設計，他們每個客戶使用單一執行中餘額項目。客戶動作會使用 ADD 運算式更新餘額，該運算式不是等冪性的，因為新的正確值取決於目前值。這意味著如果在不同區域中大約同一時間，有兩個寫入操作達到相同餘額，則餘額會失去同步。

這家公司可以通過對 DynamoDB 全域資料表仔細的重新設計，來實現寫入任何區域模式。新的設計可以遵循「事件串流」模式-本質上是一個帶有僅允許新增的工作流程分類帳。每個客戶動作都會將新項目新增到為該客戶維護的項目收集器。項目集合是共用主索引鍵，具有不同排序索引鍵的一組項目。附加客戶動作的每個寫入動作都是等冪插入，使用客戶 ID 做為分割區索引鍵，使用交易 ID 做為排序索引鍵。這種設計使餘額的計算涉入更多，因為需要 Query 拉動項目，搭配用戶端運算。但優點是，能夠使所有寫入都是等冪性，提供顯著的路由和容錯移轉簡化。如需詳細資訊，請參閱 使用 DynamoDB 全域資料表請求路由。

舉第三個範例，假設有一位客戶在進行線上位置刊登廣告。他們已經決定，為了能夠實現寫入任何區域模式的設計簡化，可以接受低風險的資料丟失。當他們投放廣告時，他們只需幾毫秒就能擷取足夠的中繼資料來決定要顯示的廣告，然後記錄廣告曝光次數，這樣相同的廣告就不會向該使用者重複播放。透過全域資料表，他們可以取得全球終端使用者低延遲讀取和低延遲寫入。他們可以在單個項目中記錄使用者的所有廣告曝光次數，並將其表示為不斷增長的清單。他們可以使用一個項目而不是附加到項目集合中，因為，這樣他們就可以在每次寫入操作中刪除較舊的廣告曝光，而無需支付刪除費用。這項寫入操作不是等冪性的，因此，如果同一位使用者在大約相同時間看到在多個區域投放的廣告，就可能會有一個廣告印象寫入覆寫另一個區域。對於線上位置刊登廣告，使用者偶爾會看到重複播放廣告的風險，值得擁有更簡單、更有效率的設計。

單一優先層級 (「寫入單一區域」)

寫入單一區域模式是主動-被動，並將所有資料表寫入路由到單一主動區域。請注意，DynamoDB 沒有單一使用中區域的概念；DynamoDB 外部路由的應用程式會管理此功能。寫入單一區域模式可確保一次只寫入單一區域，以避免寫入衝突。當您想要使用條件表達式或交易時，這種寫入模式很有用，因為除非您知道自己在使用最新資料，否則將無法運作。因此，使用條件表達式和交易需要將所有寫入請求發送到具有最新資料的區域。

最終一致讀取可以移至任何複本區域，以達到較低的延遲。高度一致性讀取必須移至單一主要區域。

有時需要變更作用中區域以回應區域故障，以協助處理資料。 使用 DynamoDB 全域資料表疏散區域是此使用案例的範例之一。有些客戶會定期變更目前使用中的區域，例如「日後追蹤」部署。這會將使用中區域放置在最活躍的地理位置附近，進而提供最低延遲的讀取和寫入。還具有每天調用區域更改代碼路徑的附加優點，確保在任何災難復原之前都經過充分的測試。

被動區域可能會在 DynamoDB 周圍保留一組縮小規模的基礎設施，只有當成為主動區域時才會建立起來。如需指示燈和暖待命設計的深入討論，請參閱開啟災難復原 (DR) 架構 AWS，第 III 部分：指示燈和暖待命。

利用全域資料表實現低延遲全域分散讀取時，使用寫入單一區域模式會非常合適。例如，一家大型社群媒體公司擁有數百萬使用者和數十億貼文。每個使用者在建立帳戶時都會被分配到一個區域，該區域位於靠近他們的地理位置。所有資料都會進入該非全域資料表。該公司使用一個單獨的全域資料表來保存使用者到其主區域的映射，採用寫入單一區域模式。世界各地僅保留僅供讀取複本，以幫助直接找到每個使用者的資料，並將附加延遲降至最低。很少進行更新 (僅在將使用者的主要區域從一個區域移動到另一個區域時)，並且始終通過一個區域進行寫入，以避免發生寫入衝突的可能性。

作為另一個例子，假設有一位實作每日現金回饋計算的金融服務客戶。他們使用寫入任何區域模式來計算餘額，但使用寫入單一區域模式來追蹤實際的現金回饋付款。如果他們想為客戶提供每一天花費 10 美元即回饋 1 美分，他們需要 Query 將前一天的所有交易計算總支出，將現金回饋決策寫入新的資料表，刪除查詢的項目集並其標記為已消耗，並替換為單一項目儲存作為提醒金額，用於次日的計算。這項工作牽涉交易，因此寫入單一區域模式將能夠更好地工作。只要工作負載沒有重疊的機會，即使在同一個資料表上，應用程式也可能會混合寫入模式。

混合優先層級 (「寫入您的區域」)

寫入您的區域模式會將不同的資料子集指派給不同的區域，並且只允許透過其主區域的項目進行寫入操作。此模式為主動-被動模式，但會根據項目指派使用中的區域。每個區域都是對自己本身的非重疊資料集都是優先層級，而且必須保護寫入以確保適當的位置。

此模式類似於寫入單一區域模式，不同之處在於它可以實現更低的延遲寫入，因為與每個終端使用者相關的資料可以放置在距離該使用者更接近的網絡中。該模式也會在區域之間更均勻地分散周圍的基礎結構，並且容錯移轉案例期間需要建立基礎設施的工作較少，因為所有區域都會有一部分使用中的基礎設施。

可以用多種方式來決定項目的主區域：

例如，假設您在為一家遊戲公司工作。您需要為全球所有遊戲玩家提供低延遲的讀取和寫入。您可以將每個玩家的主區域放置到最接近玩家的區域。該區域接受所有讀取和寫入，確保始終具有強大的寫入後讀一致性。但是，如果該玩家外出旅行，或其主區域遭遇中斷，則將在替代區域提供玩家資料的完整副本。因此，能夠將玩家分配到不同主區域非常實用。

另一個例子，假設您在視訊會議公司工作。每個電話會議的中繼資料都會指派給特定區域。來電者可以使用離他們最近的區域以獲得最低延遲。如果發生區域中斷，使用全域資料表可讓您快速復原，因為系統可以將通話處理轉移到擁有複寫資料副本的不同區域。