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

使用 DynamoDB 全域資料表疏散區域

撤離區域是將讀取和寫入活動從該區域遷移出去的過程。最常見的是寫入活動，偶爾會有讀取活動。

疏散即時區域

出於多種原因，您可能決定疏散即時區域。疏散可能是一般業務活動的一部分，例如您使用 follow-the-sun寫入一個區域模式。疏散也可能是由於商業決定變更目前作用中的區域、因應 DynamoDB 外部軟體堆疊的故障，或是因為您遇到一般問題，例如區域內的延遲高於平時。

通過寫入任何區域模式，疏散即時區域非常簡單。您可以透過任何路由系統將流量路由到備用區域，並讓已經在疏散區域中發生的寫入操作照常複製。

使用寫入單一區域和寫入您的區域模式時，您必須確保在新的使用中區域中開始寫入之前，使用中區域的所有寫入都已被完整記錄、串流處理和全域傳播。這是必要的，以確保未來的寫入是針對最新版本的資料。

假設區域 A 處於作用中狀態，而區域 B 是被動的 (無論是針對全域資料表或區域 A 中的項目來說)。執行疏散的典型機制是暫停寫入 A、等待充分的時間讓這些操作完全傳播到 B、更新架構堆疊以辨識 B 為使用中，然後繼續寫入操作至 B。沒有指標能夠保證區域 A 的資料已完全複製到區域 B。如果區域 A 狀況良好，請暫停寫入操作至區域 A，然後等待 10 倍 ReplicationLatency 最近指標的最大值，判斷複製是否完成。如果區域 A 狀況不佳並顯示延遲增加的其他區域，則您可以選擇較大的倍數作為等待時間。

疏散離線區域

有一個特殊情況需要考慮：如果區域 A 在毫無通知的情況下完全離線怎麼辦？ 雖然極不可能發生，但仍需審慎考慮。如果發生這種情況，區域 A 中尚未傳輸的任何寫入操作都會在區域 A 重新上線後保留和傳播。寫操作不會遺失，但它們的傳播會無限期延遲。

在這種情況下如何進行應用程式的決策。對於業務連續性，寫入操作可能需要繼續進行新的主要區域 B。不過，如果區域 B 中的某個項目在區域 A 的寫入操作擱置傳播時收到更新，則會在最後一個寫入獲勝模型下抑制傳播。區域 B 中的任何更新都可能會抑制傳入的寫入請求。

透過寫入任何區域模式，讀取和寫入可以在區域 B 中繼續，相信區域 A 中的項目最終會傳播到區域 B，並察覺遺失項目的可能性，直到區域 A 重新連線為止。可能的話，您應該考慮重新播放最近的寫入流量 (例如，通過上游事件來源)，以填補任何可能遺失的空白寫入操作，並讓最後一個寫入獲勝衝突解決方案抑制傳入寫入操作的最後傳播。

使用其他寫入模式時，您必須考量工作可以繼續的程度，並稍微 out-of-date檢視世界。區域 A 重新上線之前，將丟失一些持續時間較短的寫入操作 (如，ReplicationLatency 追蹤)。業務能夠繼續進行嗎？ 在某些使用案例中，能夠繼續進行，但在其他情況下，如果沒有額外的緩解機制，可能無法繼續進行。

例如，假設即使在區域故障後，您也需要不間斷維持可用的信用餘額。您可以將餘額分成兩個不同的項目，一個在區域 A 和一個在區域 B，每個項目從可用餘額的一半開始。這將使用寫入您的區域模式。每個區域中處理的交易更新會針對餘額的本機複本寫入。如果區域 A 完全離線，工作仍然可以在區域 B 中繼續進行交易處理，並且寫入操作將限制為區域 B 中所保留的餘額部分，像這樣拆分餘額會導致複雜性，但即使在不確定的待處理寫入操作下，可以提供一個安全業務復原的範例。

作為另一個例子，假設您在擷取 Web 表單資料。您可以使用 Optimistic 並行控制 （OCC） 將版本指派給資料項目，並將最新版本內嵌至 Web 表單作為隱藏欄位。每次提交時，只有當資料庫中的版本仍與建置表單的版本相符時，寫入操作才會成功。如果版本不相符，則可以根據資料庫中目前版本重新整理 (或仔細合併) Web 表單，並且使用者可以再次進行操作。此OCC模型通常可避免其他用戶端覆寫並產生新版本的資料，但也可以在容錯移轉期間協助用戶端可能遇到較舊版本的資料。

假設您是使用時間戳記作為版本。假設表單首先是在 12:00 針對區域 A 建置，但是 (在容錯移轉之後) 嘗試寫入區域 B，並注意到資料庫中的最新版本是 11:59。在此情況中，用戶端可以等候 12:00 版本傳播到區域 B，然後在該版本之上寫入，或是在 11:59 建置並建立新的 12:01 版本 (寫入後，會在區域 A 復原之後抑制傳入版本)。

作為最後一個範例，金融服務公司將客戶帳戶及其財務交易的相關資料保存在 DynamoDB 資料庫中。如果區域 A 完全中斷，他們想要確保與其帳戶相關的任何寫入活動在區域 B 中完全可用，或者想要隔離他們已知的部分帳戶，直到區域 A 重新連線為止。他們沒有暫停所有業務，而是決定只對確定有未傳播交易的一小部分賬戶暫停業務。為了達成此目的，他們使用了第三個區域，我們將呼叫區域 C。在處理區域 A 中的任何寫入操作之前，他們在區域 C 中對那些暫緩操作 (例如，帳戶新的交易計數) 建立摘要彙總。此彙總足以讓區域 B 判斷其檢視是否完全為最新狀態。此動作會有效鎖定帳戶，從寫入區域 C 開始，直到區域 A 接受寫入操作且區域 B 收到為止。除非作為容錯移轉程序的一部分外，不會使用區域 C 中的資料，之後區域 B 可以和區域 C 交叉比對資料，以檢查其帳戶是否已過期。這些帳戶將被標記為隔離，直到區域 A 復原將部分資料傳播到區域 B。

如果區域 C 當機，則可以改用新的區域 D。區域 C 中的資料是非常暫時性的，幾分鐘後，區域 D 會有足夠 up-to-date記錄的處理中寫入操作，以便完全有用。如果區域 B 當機，區域 A 可以繼續接受與區域 C 合作的寫入請求。這家公司願意接受更高的延遲寫入 (到兩個區域：C 和 A)，並且很高興擁有資料模型，可以摘要彙總帳戶狀態。