本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 多區域基本概念 2：了解資料
當您採用多區域架構時，管理資料是一個非小問題。區域之間的地理距離會強加不可避免的延遲，其表現為跨區域複寫資料所需的時間。可用性、資料一致性和在使用多區域架構的工作負載中引入較高延遲之間的權衡是必要的。無論您使用非同步或同步複寫，都需要修改應用程式來處理複寫技術強加的行為變更。資料一致性和延遲的挑戰使得採用專為單一區域設計的現有應用程式變得非常困難，並使其成為多區域應用程式。了解特定工作負載的資料一致性要求和資料存取模式對於權衡權衡至關重要。
## 2.a：了解資料一致性要求
[CAP 理論](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/cap-theorem.html)提供有關資料一致性、可用性和網路分割區之間權衡的推理參考。工作負載只能同時滿足其中兩個需求。根據定義，多區域架構包含區域之間的網路分割區，因此您必須在可用性和一致性之間進行選擇。
如果您選取跨區域資料的可用性，則在交易寫入操作期間不會產生重大延遲，因為在複寫完成之前，對跨區域遞交資料的非同步複寫的依賴會導致跨區域的一致性降低。使用非同步複寫時，當主要區域發生故障時，寫入操作從主要區域等待複寫的可能性很高。這會導致在複寫恢復之前無法使用最新資料的情況，並且需要調節程序來處理未從發生中斷的區域複寫的傳輸中交易。此案例需要了解您的商業邏輯，並建立特定程序來重播交易或在區域之間比較資料存放區。
對於偏好非同步複寫的工作負載，您可以使用 [Amazon Aurora](https://aws.amazon.com/rds/aurora/) 和 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 等服務進行非同步跨區域複寫。 [Amazon Aurora 全域資料庫](https://aws.amazon.com/rds/aurora/global-database/) 和 [Amazon DynamoDB 全域資料表](https://aws.amazon.com/dynamodb/global-tables/) 都有預設的 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 指標，以協助監控複寫延遲。Aurora 全域資料庫包含一個寫入資料 的主要區域，以及最多五個唯讀 次要 區域。DynamoDB 全域資料表包含跨資料寫入和讀取之任何數量區域的多主動複本資料表。
工程工作負載以利用事件驅動型架構是多區域策略的優勢，因為它意味著工作負載可以接受資料的非同步複寫，並透過重播事件來啟用狀態重建。由於串流和傳訊服務緩衝訊息承載資料位於單一區域，因此區域容錯移轉或容錯回復程序必須包含重新導向用戶端輸入資料流程的機制。程序也必須協調存放在發生中斷的區域中的傳輸中或未交付承載。
如果您選擇 CAP 一致性需求，並使用跨 區域同步複寫的資料庫來支援同時從多個 區域執行的應用程式，您可以消除資料遺失的風險，並在區域之間保持資料同步。不過，這帶來了更高的延遲特性，因為寫入需要遞交到多個區域，而且區域彼此之間可以是數百或數千英里。您需要在應用程式設計中考慮此延遲特性。此外，同步複寫可能會帶來相互關聯的失敗機會，因為需要將寫入遞交至多個區域才能成功。如果一個區域內有受損，您將需要形成規定人數，寫入才能成功。這通常涉及在三個區域中設定資料庫，以及建立三個區域中的兩個仲裁。[Paxos](https://www.cs.yale.edu/homes/aspnes/pinewiki/Paxos.html) 等 技術可協助同步複寫和遞交資料，但需要大量的開發人員投資。
當寫入涉及跨多個區域的同步複寫以滿足強大的一致性要求時，寫入延遲會增加一個數量級。較高的寫入延遲不是您通常可以在沒有重大變更的情況下修改為應用程式的內容，例如重新檢視應用程式的逾時和重試策略。理想情況下，首次設計應用程式時，必須將其納入考量。對於同步複寫為優先順序的多區域工作負載， [AWS Partner 解決方案](https://partners.amazonaws.com/)可以提供協助。
## 2.b：了解資料存取模式
工作負載資料存取模式是*讀取密集*型或*寫入密集型*。了解特定工作負載的此特性可協助您選取適當的多區域架構。
對於完全唯讀的讀取密集型工作負載，例如靜態內容，您可以實現[主動-主動](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)多區域架構，與寫入密集型工作負載相比，其工程複雜性較低。使用內容交付網路 (CDN) 在邊緣提供靜態內容，透過快取最接近最終使用者的內容來確保可用性；使用 [Amazon CloudFront 內的原始伺服器容錯移轉](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)等功能集有助於實現此目標。另一個選項是在多個區域中部署無狀態運算，並使用 DNS 將使用者路由到最近的區域來讀取內容。您可以使用 [Amazon Route 53 搭配地理位置路由政策](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)來達成此目標。
對於讀取流量百分比大於寫入流量的讀取密集型工作負載，您可以使用 [讀取本機寫入全域 策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)。這表示所有寫入請求都會傳送至特定區域中的資料庫，資料會以非同步方式複寫至所有其他區域，而且讀取可以在任何區域中完成。這種方法需要工作負載才能接受最終一致性，因為跨區域複寫寫入的延遲增加，可能會導致本機讀取過時。
[Aurora 全域資料庫](https://aws.amazon.com/blogs/database/improving-business-continuity-with-amazon-aurora-global-database/) 可協助在待命區域中佈建 [僅供本機處理所有讀取流量的僅供讀取複本](https://aws.amazon.com/rds/features/read-replicas/) ，以及在特定區域中佈建單一主要資料存放區來處理寫入流量。資料會從主要資料庫非同步複寫到待命資料庫 （僅供讀取複本），而且如果您需要將操作容錯移轉到待命區域，則可以將待命資料庫提升為主要資料庫。您也可以在此方法中使用 DynamoDB。[DynamoDB 全域資料表 ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)可以跨區域佈建 [複本資料表](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.html)，每個區域都可以擴展以支援任何數量的本機讀取或寫入流量。當應用程式將資料寫入某個區域的複本列表時，DynamoDB 會自動將寫入傳播到另一個 區域的其他複本列表。使用此組態，資料會從定義的主要區域非同步複寫到待命區域中的複本資料表。任何區域中的複本資料表一律可以接受寫入，因此在應用程式層級管理將待命區域提升為主要區域。同樣地，工作負載必須接受最終一致性，如果一開始就不是為此設計，則可能需要重寫。
對於寫入密集型工作負載，應選取主要區域，且應將容錯移轉至待命區域的功能設計為工作負載。與主動-主動方法相比，[主要-待命](https://aws.amazon.com/rds/features/multi-az/)方法具有額外的權衡。這是因為對於主動-主動架構，必須重寫工作負載以處理智慧路由到 區域、建立工作階段親和性、確保等冪交易，以及處理潛在的衝突。
大多數使用多區域方法來恢復能力的工作負載不需要主動-主動方法。您可以使用[碎片](https://aws.amazon.com/what-is/database-sharding/)策略，透過限制整個用戶端基礎的受損影響範圍來提供更高的彈性。如果您可以有效地分割用戶端基礎，您可以為每個碎片選取不同的主要區域。例如，您可以碎片化用戶端，讓一半的用戶端與區域 1 對齊，一半與區域 2 對齊。透過將區域視為儲存格，您可以建立多區域儲存格方法，從而減少工作負載的影響範圍。如需詳細資訊，請參閱 [AWS re：Invent 有關此方法的簡報](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Reducing_blast_radius_with_cell-based_architectures_ARC411-R1.pdf)。
您可以結合碎片方法與主要待命方法，為碎片提供容錯移轉功能。您需要將經過測試的容錯移轉程序設計成工作負載，以及資料對帳的程序，以確保容錯移轉後資料存放區的交易一致性。本指南稍後會詳細說明這些內容。
## 金鑰指引
+ 發生故障時，等待複寫的寫入不會遞交至待命區域的可能性很高。在複寫恢復之前，資料將無法使用 （假設為非同步複寫）。
+ 在容錯移轉過程中，將需要資料對帳程序，以確保使用非同步複寫的資料存放區維持交易一致狀態。這需要特定的商業邏輯，而不是由資料存放區本身處理的邏輯。
+ 需要強式一致性時，需要修改工作負載，以容忍同步複寫的資料存放區所需的延遲。