问题的历史
全球扩展的企业面临严格的数据驻留法律，如GDPR和CCPA。传统的单体数据库将数据集中在一个地区，违反主权或导致高延迟。早期的分布式系统采用主动-被动复制，但这会导致单点故障和写入延迟问题。现代架构必须支持多活动区域，在EU、US和APAC的用户可以在本地写入，同时尊重数据本地性约束。
问题
核心挑战在于CAP定理的权衡。你不能同时在多个区域实现强一致性、低延迟和分区容忍性。此外，当数据不能跨境时，跨区域的外键关系变得不可能。跨区域事务风险在协调过程中泄露PII并违反合规性。维持低于100毫秒的读取需要缓存，但跨主权边界的缓存失效非常复杂。
解决方案
实现一种单元基础架构，使用数据库本地的地理分区（例如，CockroachDB或Google Cloud Spanner）。通过region列对表进行分区，确保PII永远不离开其物理单元。通过Apache Kafka实施变更数据捕获（CDC），仅在全球范围内复制非敏感元数据。对于跨区域事务，实施Saga模式，使用本地补偿以避免分布式锁。将Redis集群部署在边缘，采用缓存旁路模式处理读取密集型工作负载，使用TTL-基础的无效化以避免跨区域缓存协调。
背景
一家全球支付处理器需要在德国和新加坡推出，同时维持其美国数据中心。法规要求欧盟用户的交易历史物理上保留在法兰克福，而亚太数据则保留在新加坡。然而，跨境转账需要在同一逻辑事务中从美国账户扣款并向欧盟账户充值，同时保持余额查询在100毫秒以下。
解决方案1：带区域读取副本的集中式数据库
这种方法将在美国东部托管主数据库，并在欧盟和亚太设置读取副本，提供简单的一致性模型和直接的ACID保证，无需复杂的同步。然而，这违反了数据主权法律，因为写入流量路由到美国东部，可能将欧盟的PII保留在美国土壤上，而来自新加坡的写入则面临200毫秒以上的延迟，无法满足用户体验需求。该架构也在美国东部产生单点故障，对于需要区域自主权的全球支付平台不可接受。
解决方案2：完全独立的区域孤岛与夜间ETL
该设计在每个区域操作独立的PostgreSQL集群，在夜间维护窗口期间处理跨区域转账，以确保完美的合规隔离和简单的区域自主权。该方法无法支持实时国际支付，导致用户体验不佳，并使得在批处理期间纠正重算错误变得困难。此外，该架构无法在没有显著延迟的情况下支持全球账户余额汇总，使其不适合现代金融科技平台。
解决方案3：具有Saga调度的地理分区数据库
该策略部署CockroachDB，使用partition_key映射用户的主区域进行地理分区表，并实施Temporal工作流将跨区域转账管理为本地事务与补偿操作。该设计通过分区约束强制本地数据驻留，同时通过分配到区域节点的租户实现低于50毫秒的本地读取，尽管引入了需要分布式SQL专长的运营复杂性。该解决方案通过Kafka CDC流处理跨区域元数据的最终一致性，并通过TTL基础的待处理状态可见性管理在saga执行期间的暂时不一致。
选择的方法
团队选择了解决方案3，因为它独特地满足了合规性与延迟约束，无需牺牲事务语义或进行破坏性的数据迁移。他们配置了CockroachDB的按行地域表，将欧盟的行固定到法兰克福节点，在边缘位置部署Redis集群，并为元数据缓存设置5秒TTL，同时实施Temporal saga以调度跨区域转账，在失败时进行自动补偿。
结果
该系统通过GDPR审计，未发生跨境PII泄露，同时处理50,000笔每日跨区域交易，并实现99百分位读取延迟为45毫秒。客户支持团队能够通过API端点查询待处理的saga状态，以解决区域故障期间的暂时不一致。该架构现在支持通过简单地向CockroachDB集群添加新单元，而无需更改应用程序即可扩展到新市场。
当外键关系跨越两个数据主权区域时，你如何维护引用完整性？
当数据不能物理离开其区域时，你无法跨区域强制执行数据库级外键约束。使用UUID引用和通过Outbox模式向Kafka发布的异步验证来实施应用程序级引用完整性；消费者验证引用并发布确认，在超时后进行孤儿检测。这在合规性上牺牲了即时一致性，但确保了没有数据迁移的最终完整性，使用Saga补偿来回滚引用无效外键的事务。
当一个区域在跨区域Saga期间失败时，正在进行的交易会发生什么？
Saga模式不会自动处理失败；你必须设计幂等性，使用存储在Redis或Etcd本地区域的幂等性密钥来防止在重试时的重复处理。如果区域B在信贷操作期间失败，则调度器超时会触发区域A的补偿事务以退款，利用PostgreSQL 顾问锁或ZooKeeper 分布式锁防止在调度器故障转移期间的竞争条件。系统必须通过API端点公开待处理事务状态，以便客户支持干预，确保部分失败状态的可查询性和可解决性，而不会造成数据损坏。
你如何处理跨地理分区单元的零停机时间架构迁移？
采用扩展-收缩模式结合由LaunchDarkly管理的功能标志，首先使用Flyway或Liquibase在各区域的维护窗口中跨区域部署附加的DDL更改（新列、表），保持应用程序的向后兼容性。使用Debezium CDC管道异步迁移数据，然后在确认模式传播通过健康检查后，通过功能标志启用新代码路径，确保没有区域提供过时数据。在所有区域确认迁移完成之前，绝不要执行破坏性的DDL（删除列），利用每个单元内的蓝绿部署即时回滚，如果复制延迟超出阈值。