参考架构：多区域 / 全球

当用户在地理上分散，或需要抵御区域性灾难时，数据会分布到多个区域。这棵决策树逐步介绍读取本地化（每个区域一个只读副本）、写入拓扑（单主 vs 多主 vs quorum）、数据驻留/合规（GDPR）、冲突解决，以及 RPO/RTO 与延迟之间的取舍。基本事实：由于物理定律，低延迟、强一致性和多区域写入无法同时完全实现；必须做出有意识的取舍。

为什么要采用多区域：读取本地化、写入/容灾还是合规？

多区域架构成本高且复杂；先明确动机。你是希望远方用户获得低读取延迟，需要跨区域写入/容灾能力，还是真正的要求是数据留在特定国家（法律上的数据驻留）？

• 远方用户需要快速读取；写入可以留在一个区域
• 需要跨区域写入 / 能承受丢失一个区域
• 数据在法律上必须留在特定国家/区域

写入拓扑应该是什么：单主、多主还是 quorum？

对于跨区域写入，关键决策是主节点模型。是所有写入都发往单个区域（简单、一致，但远程写入很慢），每个区域都可以写入（写入延迟低但存在冲突），还是写入在获得多数区域确认后才被接受（quorum：一致但增加延迟）？

• 一个区域写入，其他区域读取（简单且一致）
• 每个区域都可以本地写入（写入延迟低）
• 多数确认后写入；一致性优先

建议：每个区域一个只读副本（读取本地化）

写入保留在单个主区域，同时在每个用户所在区域放置一个由其供给的只读副本。用户从最近的副本读取，读取延迟下降；由于写入仍然发往单一中心，一致性模型保持简单。

建议：单主写入

所有写入都发往单个主区域；其他区域是由该主区域异步供给的只读副本。这是最简单、一致性最强的模型；因为只有一个写入点，所以没有冲突。代价是来自远程区域的写入延迟很高。

建议：多主写入 + 冲突解决

由于每个区域都可以本地写入，写入延迟低，即使一个区域被切断，其他区域也能继续写入。代价很大：两个区域可能以不同方式更新同一条记录，你必须设计冲突解决机制。

建议：基于 quorum 的写入（多数确认）

当多数（quorum）区域/副本确认后，写入才被接受；当读取也访问多数节点时，就能保证读到最新值。它能抵御区域丢失且具有强一致性；代价是每次写入都要等待到达多数节点的延迟。

建议：数据驻留 / 合规（GDPR）

某些数据（个人、健康、财务）在法律上必须保留在特定国家/区域的境内（例如 GDPR）。在这种情况下，架构设计不是围绕“到处复制”，而是让数据在地理上固定。