Azure Cosmos DB全球规模架构设计核心指南

1. 项目概述：这不是又一个“云数据库”，而是为全球实时业务而生的底层引擎

Azure Cosmos DB 这个名字在云原生开发圈里，已经不是新鲜词了。但很多人第一次听到它，还是下意识把它归类成“微软版的 MongoDB”或者“带 SQL 接口的 DocumentDB”。这种理解偏差，直接导致项目后期踩坑——比如明明选了强一致性却遭遇跨区域读延迟，或者以为自动缩放能扛住流量洪峰，结果在 Black Friday 当天被 429 错误刷屏。我做过 7 个横跨金融、游戏、IoT 领域的 Cosmos DB 主导项目，最深的体会是：它不解决“有没有数据库”的问题，而是解决“当你的用户从东京登录、订单写入新加坡、风控校验在法兰克福执行、报表聚合在巴西生成时，数据还能不能算得准、回得快、不出错”这个根本命题。它的核心关键词不是“NoSQL”，而是“全球规模（Global-Scale）”——这个词在官方文档里出现 217 次，但在实际落地中，90% 的团队连它的第一层含义都没吃透。它面向的不是单体应用开发者，而是架构师、SRE 和全球化产品负责人；它要解决的不是 CRUD 性能，而是“地理围栏合规性”“多活单元切换耗时”“最终一致性窗口内业务可容忍的冲突类型”这些真实战场上的硬骨头。如果你正在设计一个需要服务亚太、欧美、拉美三地用户的 SaaS 平台，或者正在把本地部署的 ERP 系统迁移到全球云环境，那么 Cosmos DB 不是一个可选项，而是一道必须认真拆解的必答题。

2. 全局架构设计与核心思路拆解：为什么“全球规模”必须从分区键开始想

2.1 “全球规模”不是功能开关，而是贯穿数据模型、网络拓扑、一致性策略的系统级约束

很多团队在 Azure 门户上点几下就创建好 Cosmos DB 账户，然后兴冲冲地导入百万条测试数据，结果发现查询变慢、RU 消耗飙升、跨区域同步延迟超预期。问题往往出在最开始的架构决策上——他们把“全球规模”当成一个部署后的配置项，而不是一个从数据建模第一天就必须嵌入的 DNA。Cosmos DB 的“全球规模”能力，本质是三个相互咬合的齿轮：物理分布（Regions）、逻辑分区（Partitions）、一致性模型（Consistency Levels）。这三个齿轮如果转速不匹配，整个系统就会发出刺耳的噪音。

先说物理分布。你可以在 Azure 门户里一键添加东京、阿姆斯特丹、圣保罗三个区域，但这只是“挂载点”。真正决定数据如何流动的，是账户级别的多主（Multi-Master）模式是否开启。默认关闭，意味着只有写入主区域（Primary Region）才被允许，其他区域只读。这看起来安全，但一旦主区域因网络抖动或维护中断，整个写入链路就断了。而开启多主后，每个区域都能接受写入，系统会自动在后台做冲突解决——但这就引出了第二个齿轮：逻辑分区。

逻辑分区由你定义的/partitionKey字段驱动。这个字段的取值，决定了每条文档会被哈希到哪个物理分区（Partition）上。关键来了：Cosmos DB 的全球复制，是以“分区”为最小单位进行的，而不是以“文档”或“容器”为单位。比如你设/tenantId为分区键，那么所有tenantId="acme"的文档，无论写入哪个区域，都会被同步到所有已启用的区域中。但如果你设/userId为分区键，而用户 A 在东京注册、用户 B 在圣保罗下单，他们的数据就可能落在完全不同的物理分区上，跨区域同步的路径和压力就完全不同。我见过一个电商项目，用/orderId作分区键，结果订单号是 UUID，完全随机，导致数据在 128 个物理分区上均匀打散。表面看负载均衡了，但一个“用户订单列表”查询（需要按/userId查询）就变成了跨所有分区的广播扫描，RU 消耗暴涨 40 倍。这就是典型的“用错了齿轮比”。

第三个齿轮是一致性模型。Cosmos DB 提供五种级别：强、有界过期、会话、一致前缀、最终。很多人选“最终一致性”，觉得性能最好。但实测下来，在跨三大洲的部署中，“最终一致性”的延迟窗口可能长达 5 秒——这对支付状态同步、库存扣减这类场景是灾难性的。而“强一致性”虽然保证了任意区域读到的数据都和主区域完全一致，但它要求所有副本达成共识，网络 RTT 成为瓶颈。我们一个游戏项目在东京-法兰克福双活部署下，强一致性平均读延迟是 180ms，而会话一致性只要 65ms，且能保证同一用户会话内的读写顺序。所以，“全球规模”的设计，本质上是在“数据局部性（Locality）”、“操作延迟（Latency）”、“业务正确性（Correctness）”三者之间做精密的权衡，而不是简单地勾选“启用多区域”。

2.2 分区键设计：不是技术选择，而是业务契约的具象化表达

分区键（Partition Key）是 Cosmos DB 架构中最容易被低估、也最致命的设计点。它不像传统数据库的索引那样可以事后优化，一旦容器（Container）创建，分区键就无法更改。这意味着，你在设计第一个文档结构时，就已经签下了未来三年的数据命运契约。

我总结出分区键设计的“三不原则”：

• 不选高基数、低业务意义的字段：比如/id（UUID）、/timestamp、/guid。它们确实能保证数据均匀分布，但几乎无法支撑任何有意义的查询。一个/id分区键的容器，99% 的查询都得走跨分区扫描（Cross-Partition Query），RU 消耗呈指数级增长。我们曾为一个日志分析平台用/logId作分区键，结果一个简单的“查某 IP 今天所有错误日志”查询，要扫描 200 多个分区，单次查询 RU 超过 10,000，成本翻了 5 倍。

• 不选业务上会频繁变更的字段：比如/status、/ownerId。Cosmos DB 不支持在同一个事务中更新分区键的值。如果一条订单的/ownerId从 A 变成 B，你必须先删除再插入，这不仅破坏原子性，还会在变更窗口期造成数据不一致。更糟的是，如果/ownerId是高频变更字段，每次变更都意味着一次昂贵的物理移动。

• 不选无法承载业务隔离边界的字段：这是最高阶的陷阱。比如一个 SaaS 平台，所有租户（Tenant）共享一个数据库。如果分区键是/customerId，那么客户 A 和客户 B 的数据就混在同一个分区里。一旦客户 A 的数据量暴增（比如上传了百万张图片元数据），整个分区的吞吐量（RU/s）就会被它吃光，客户 B 的查询立刻变慢——这叫“邻居效应（Noisy Neighbor）”。正确的做法是/tenantId，它天然划清了租户边界，让资源隔离成为可能。

那么，什么才是好的分区键？答案是：它必须是业务上最常被用来“切片”数据的那个维度，且这个维度的值分布相对均匀。我们给一个跨境物流平台设计时，最终选了/shipmentId。因为：

1. 所有核心查询（查单号轨迹、查单号详情、查单号状态）都以shipmentId为条件；
2. shipmentId是业务主键，永不变更；
3. 单号生成规则（COUNTRY-YYYYMMDD-SEQ）保证了时间序列上的均匀性，避免了冷热不均；
4. 它天然支持按国家/地区做数据归档（/shipmentId前缀即国家码）。

这个选择让 95% 的查询都落在单一分区内，平均 RU 消耗从 1200 降到 85，查询 P99 延迟稳定在 12ms 以内。分区键不是技术参数，它是你对业务领域最深刻理解的代码化表达。

2.3 一致性模型选型：用“会话一致性”平衡全球部署的性能与正确性

在多区域部署中，一致性模型的选择，直接决定了你的应用是“快但不准”，还是“准但很慢”。官方文档把五种模型列出来，但实际项目中，我们 90% 的场景只用两种：会话一致性（Session Consistency）和有界过期一致性（Bounded Staleness）。强一致性太重，最终一致性太松，一致前缀则过于理论化。

会话一致性是我个人最推荐的“默认起点”。它的核心承诺是：“对于同一个客户端会话（Session），你读到的数据，永远不会比你之前写入的数据更旧。” 这听起来像废话，但在分布式系统里，这是极强的保障。想象一个用户在东京下单（写入东京区域），然后立刻刷新页面查看订单状态（读取东京区域）。会话一致性确保他一定能看到刚下的单。但如果另一个用户在法兰克福查这个订单，他可能看到的是 200ms 前的状态——这通常是可以接受的，因为业务上并不要求全球瞬时可见。

为什么它性能好？因为 Cosmos DB 为每个客户端 Session 维护了一个轻量级的“读取版本向量（Read Version Vector）”。当客户端发起读请求时，系统只需检查该区域副本的最新版本是否 >= 客户端上次写入的版本，而无需等待所有区域达成全局共识。这省去了跨区域的协调开销。

我们一个在线教育平台，用会话一致性支撑了“学生上课-教师发布作业-学生提交-教师批改”的完整闭环。所有操作都在同一个用户会话内完成，数据流清晰，延迟稳定在 50ms 内。当需要跨会话强一致时（比如财务结算），我们才用有界过期一致性——它允许你指定一个“最大过期版本数”或“最大过期时间（秒）”，比如MaxStalenessPrefix=100或MaxStalenessIntervalInSeconds=5。这意味着，任何读请求，返回的数据版本不会比最新版本落后超过 100 个写入事件，或 5 秒。这比强一致性灵活得多，又比最终一致性可靠得多。

提示：在 .NET SDK 中，会话一致性是默认开启的，你甚至不需要显式配置。但务必在应用层显式管理SessionToken，尤其是在 Web 应用中，要将它从请求头传入、响应头传出，否则会话上下文就断了。我们曾因忘记在 API 网关里透传x-ms-session-token，导致前端反复刷新看到“订单未创建”的假象，排查了两天才发现是会话丢失。

3. 核心细节解析与实操要点：RU 消耗、索引策略与变更数据捕获（CDC）

3.1 RU（Request Unit）不是抽象概念，而是可精确计算、可精准优化的“数据库货币”

新手最容易陷入的误区，就是把 RU（Request Unit）当成一个模糊的性能指标。实际上，RU 是 Cosmos DB 计费和限流的绝对基础单位，1 RU = 1 个 1KB 文档的单分区、单次、强一致性读取操作所消耗的资源。它是可计算、可预测、可优化的“数据库货币”。理解 RU，是控制成本、保障性能的第一步。

RU 的消耗公式，官方给出了明确的基准：

• 读取（Read）：1 RU = 1 次单分区、1KB 文档的读取。
• 写入（Write）：1 RU = 1 次单分区、1KB 文档的写入（含索引更新）。
• 查询（Query）：最复杂，取决于扫描的文档数、返回的文档数、索引命中率、是否跨分区。

举个真实例子。我们一个 IoT 设备管理平台，设备上报的 JSON 数据平均大小为 2.3KB。一条写入操作，基础 RU 就是 2.3。但还要加上索引开销：Cosmos DB 默认为所有字段建立索引（Automatic Indexing），这会让写入 RU 翻倍。我们最初没关掉无用索引，一条 2.3KB 的设备心跳上报，RU 消耗高达 8.7。后来分析发现，90% 的查询只用/deviceId和/timestamp，于是我们配置了"Excluded Paths"，排除了/sensorData/*、/diagnostics/*等大字段的索引，写入 RU 直接降到 3.2，成本立降 63%。

查询的 RU 更值得深挖。一个SELECT * FROM c WHERE c.status = "active"，如果status没有索引，系统就得扫描全分区所有文档（假设 10,000 条），每条按平均 2KB 算，RU 消耗就是 20,000！而如果status有索引，它只需定位到匹配的文档 ID，再读取这些文档，RU 可能只有 120。这就是为什么“没有索引的查询”是 RU 消耗黑洞。我们有个项目，一个后台定时任务每天凌晨跑一次全量统计，因为没加索引，单次查询 RU 超过 50,000，触发了账户级限流，导致后续所有请求排队。解决方案不是加 RU 配额，而是加一个复合索引：[{"path":"/status/?","order":"ascending"},{"path":"/createdAt/?","order":"descending"}]，查询 RU 降到 420。

注意：Cosmos DB 的索引是“写时构建”，不是“读时构建”。这意味着，索引越多，写入越慢、RU 越高。所以索引策略必须是“按需建设”，而不是“全量覆盖”。我们团队的铁律是：上线前，用 Azure Portal 的"Query Metrics"功能，对所有核心查询做 RU 消耗压测，确保 P95 查询 RU < 100。超过这个阈值，第一反应不是加配额，而是查索引、查分区键、查查询写法。

3.2 索引策略：从“全量索引”到“精准索引”的成本革命

Cosmos DB 默认开启"Automatic Indexing"，即为容器中所有字段（包括嵌套字段）自动创建索引。这极大降低了入门门槛，但也埋下了成本隐患。就像给一辆家用车装上了 F1 赛车的全套空气动力学套件——好看，但日常通勤根本用不上，还徒增油耗。

索引的本质，是空间换时间。每个索引，都是额外的存储空间和写入时的计算开销。一个 1KB 的文档，如果为 10 个字段建索引，写入时就要额外处理 10 份索引数据，RU 消耗自然水涨船高。我们一个内容管理系统，初始文档结构包含/title,/body,/author,/tags,/metadata/*等 20+ 字段。默认全量索引下，一篇 1.5KB 的文章发布，RU 消耗 18.6。后来我们做了三件事：

1. 识别核心查询路径：95% 的查询是WHERE /status = "published" AND /publishDate > @date和WHERE /author = @id。
2. 关闭非核心索引：在索引策略中，将/body,/metadata/*,/seo/*等字段加入"excludedPaths"。
3. 为高频查询字段建复合索引：为status + publishDate和author + status创建了两个复合索引。

结果：写入 RU 从 18.6 降到 4.3，降幅 77%；存储成本下降 35%（索引也占存储）；最关键的是，核心查询的 P99 延迟从 120ms 降到 18ms。

索引策略的配置，是通过 JSON 定义的。一个典型的、经过优化的策略如下：

{ "indexingMode": "consistent", "automatic": false, "includedPaths": [ { "path": "/_ts/?" }, { "path": "/status/?" }, { "path": "/publishDate/?" }, { "path": "/author/?" } ], "excludedPaths": [ { "path": "/*" }, { "path": "/body/?" }, { "path": "/metadata/*" } ] }

这里的关键是"automatic": false，它关闭了自动索引，强制你显式声明哪些路径需要索引。"excludedPaths"中的"/*"是一个“兜底排除”，意思是“先排除所有路径”，然后再在"includedPaths"中逐个添加需要的。这是一种防御性编程思维，确保不会遗漏。

实操心得：在 Azure Portal 的容器设置里，你可以实时编辑索引策略并保存。但要注意，索引重建是后台异步进行的，在重建完成前，新索引不会生效，旧索引也不会立即删除。所以，上线新索引策略后，一定要用Query Metrics观察 RU 消耗变化，确认新索引已被使用。我们曾因没等重建完成就上线，导致查询依然走全扫描，白白浪费了几天的高 RU 开销。

3.3 变更数据捕获（CDC）：用 Change Feed 实现毫秒级业务解耦

在微服务架构中，一个服务修改了数据，其他服务如何及时感知？传统方案是发消息队列（如 Kafka、Service Bus），但这引入了额外组件、额外运维、额外一致性难题（比如消息丢了怎么办？）。Cosmos DB 的Change Feed功能，提供了一种原生、轻量、可靠的 CDC（Change Data Capture）方案。

Change Feed 的本质，是一个按_ts（时间戳）排序的、只读的、无限长的变更日志流。它记录了容器中所有文档的INSERT、UPDATE、DELETE事件。关键特性是：

• At-Least-Once 语义：保证每条变更至少被消费一次，不丢。
• Lease-Based 分片：Change Feed 被自动分片（Shard），每个分片由一个消费者（Consumer）独占，通过 Lease Container（一个普通 Cosmos DB 容器）来协调租约，天然支持水平扩展。
• 毫秒级延迟：从文档变更到 Change Feed 可见，P95 延迟 < 100ms。

我们用它重构了一个订单履约系统。以前，订单服务（Order Service）创建订单后，要调用库存服务（Inventory Service）、物流服务（Logistics Service）、通知服务（Notification Service）的 API，形成一个长链条的同步调用，任何一个环节失败，整个流程就卡住。现在，订单服务只负责写 Cosmos DB，Change Feed 自动将订单创建事件推送给下游的三个独立消费者。每个消费者可以：

• 异步处理，失败后重试，不影响主流程；
• 按自己的节奏处理，库存服务可以批量扣减，物流服务可以合并发货单；
• 独立扩缩容，订单量暴增时，只增加通知服务的消费者实例，不影响库存服务。

实现 Change Feed 消费，核心是ChangeFeedProcessorBuilder（.NET SDK）。一个标准的消费者启动代码如下：

var processor = new ChangeFeedProcessorBuilder() .WithHostName("inventory-processor") .WithFeedContainer(feedContainer) // 订单容器 .WithLeaseContainer(leaseContainer) // 租约容器 .WithProcessorName("inventory-processor") .WithInstanceName(Guid.NewGuid().ToString()) .WithMaxItems(100) .WithPollInterval(TimeSpan.FromSeconds(5)) .WithDelegate(async (changes, ct) => { foreach (var item in changes) { if (item.OperationType == OperationType.Create || item.OperationType == OperationType.Replace) { var order = JsonConvert.DeserializeObject<Order>(item.Content); await ProcessInventory(order); // 扣减库存 } } }) .Build(); await processor.StartAsync();

这里WithMaxItems(100)和WithPollInterval(TimeSpan.FromSeconds(5))是关键调优点。MaxItems控制每次拉取的最大变更数，值太小（如 10）会导致频繁轮询，增加 RU 消耗；值太大（如 1000）可能导致单次处理时间过长，影响整体吞吐。我们经过压测，发现 100 是一个平衡点。PollInterval则是轮询间隔，5 秒是默认值，对于大多数业务足够。如果要求极致实时，可以降到 1 秒，但要监控 Change Feed 的 RU 消耗。

注意：Change Feed 本身不收费，但读取 Change Feed 会产生 RU 消耗（因为它本质是读取一个特殊的系统容器）。所以，消费者实例的数量，要和业务吞吐量匹配。我们一个高并发项目，最初只启了 1 个消费者，结果 Change Feed 积压严重，延迟飙升到分钟级。后来根据Change Feed的监控指标（ChangeFeedLag），动态扩容到 8 个实例，延迟立刻回到 100ms 内。Azure Monitor 里的ChangeFeedLag指标，是你调优的唯一指南针。

4. 实操过程与核心环节实现：从零搭建一个东京-法兰克福双活电商数据库

4.1 第一步：创建全球分布的 Cosmos DB 账户（不是容器！）

很多新手第一步就错了：他们在 Azure 门户里，直接点击“创建 Cosmos DB 账户”，然后填完基本信息就下一步。这创建出来的，是一个单区域的、默认主从架构的账户。要实现真正的全球规模，第一步必须是创建一个多区域、多主（Multi-Master）的账户。这个动作，决定了整个系统的基因。

具体步骤（以 Azure Portal 为例）：

1. 搜索 “Azure Cosmos DB”，点击“创建”。
2. 在“基本信息”页，选择订阅、资源组、账户名称（如ecommerce-prod-global）、API（选 Core (SQL)）。
3. 最关键的一步：在“地理冗余”部分，勾选“启用地理冗余”和“启用多主”。此时，下方的“区域”列表会变成可多选。我们勾选Japan East（东京）和Germany West Central（法兰克福）。
4. 在“网络”页，配置 VNet 服务终结点（如果需要私网访问）和防火墙规则。
5. 在“容量模式”页，选择“预配吞吐量（Provisioned throughput）”，这是生产环境的标配。注意，这里的吞吐量（RU/s）是账户级总吞吐量，会在所有区域间自动分配。比如你配了 10,000 RU/s，东京和法兰克福各分到约 5,000 RU/s（实际按流量动态调整）。
6. 点击“查看 + 创建”，审核后创建。

创建完成后，进入账户的“复制数据”页，你会看到两个区域都显示为“在线”，且“写入”和“读取”状态都是“已启用”。这表示多主已生效。此时，任何区域都可以接受写入。

提示：账户创建后，不能再添加或删除区域。如果未来要扩展到巴西圣保罗，你必须创建一个全新的、包含三个区域的账户，然后迁移数据。所以，区域规划必须前置。我们建议：初期选 2 个核心区域（如中美），预留 1-2 个“待启用”区域（在创建时就勾选，但不启用），这样未来扩展只需在 Portal 里点一下“启用”，无需重建账户。

4.2 第二步：设计并创建商品（Products）与订单（Orders）容器

有了全球账户，接下来是创建容器（Container），也就是逻辑上的“表”。我们的电商系统有两个核心实体：Products（商品）和Orders（订单）。它们的分区键设计截然不同，体现了业务逻辑的差异。

Products 容器设计：

• 分区键（Partition Key）：/categoryId。理由：商品查询最常用的是“按分类浏览”，如/api/products/category/101。categoryId基数适中（几十到几百），能保证分区数量合理，避免单分区过大或过小。
• 吞吐量（Throughput）：预配 5,000 RU/s。因为商品数据相对静态，读多写少，5,000 RU/s 足够支撑每秒数千次的分类查询。
• 索引策略：关闭自动索引，只索引/categoryId、/name、/price、/_ts。排除/description、/specifications/*等大字段。
• 一致性：会话一致性（默认）。

Orders 容器设计：

• 分区键（Partition Key）：/customerId。理由：90% 的订单查询是“查我的订单”，如/api/orders?customerId=abc123。customerId基数极高（百万级），能完美分散写入压力。虽然单个客户订单可能跨多个分区（因为customerId相同），但“我的订单”查询是单分区的。
• 吞吐量（Throughput）：预配 15,000 RU/s。订单是写密集型，尤其在促销期间，写入峰值很高。
• 索引策略：关闭自动索引，只索引/customerId、/status、/createdAt、/orderId。为customerId + status和customerId + createdAt创建复合索引。
• 一致性：会话一致性（保证用户看到自己刚下的单）。

在 Portal 中创建容器时，这些参数都可以在“高级”选项卡里配置。创建完成后，两个容器就具备了全球分布的能力。

4.3 第三步：编写 SDK 代码，实现跨区域的读写与故障转移

SDK 是连接应用和 Cosmos DB 的桥梁。一个健壮的 SDK 配置，是全球规模落地的最后也是最关键的一步。我们以 .NET SDK v3 为例，展示核心代码。

连接字符串与客户端初始化：

// 从 Azure Portal 的“连接字符串”页获取主连接字符串 var connectionString = "AccountEndpoint=https://ecommerce-prod-global.documents.azure.com:443/;AccountKey=xxx;"; // 创建客户端，关键：启用多区域读取 var client = new CosmosClient(connectionString, new CosmosClientOptions { ApplicationRegion = Regions.JapanEast, // 应用所在区域，用于优化路由 ConnectionMode = ConnectionMode.Gateway, // Gateway 模式更稳定，Direct 模式更快但对网络要求高 MaxRetryAttemptsOnRateLimitedRequests = 9, MaxRetryWaitTimeOnRateLimitedRequests = TimeSpan.FromSeconds(30) });

ApplicationRegion设置为JapanEast，告诉 SDK，应用服务器主要部署在东京，SDK 会优先将读请求路由到东京区域，降低延迟。ConnectionMode.Gateway使用 HTTPS 网关，兼容性最好，适合大多数场景。

写入订单（自动路由到最近的写入区域）：

// 创建订单容器引用 var container = client.GetContainer("ecommerce-prod-global", "Orders"); // 创建订单对象 var order = new Order { Id = Guid.NewGuid().ToString(), CustomerId = "customer-001", Status = "pending", CreatedAt = DateTime.UtcNow, Items = new List<OrderItem> { /* ... */ } }; // 写入，SDK 会自动选择最优的写入区域（通常是 ApplicationRegion） var response = await container.CreateItemAsync(order, new PartitionKey(order.CustomerId)); Console.WriteLine($"Order created in region: {response.Headers["x-ms-region"]}");

response.Headers["x-ms-region"]会返回实际执行写入的区域，你可以用它来调试路由逻辑。

读取订单（利用会话一致性）：

// 从 HTTP 请求头中提取 SessionToken string sessionToken = HttpContext.Request.Headers["x-ms-session-token"]; // 读取单个订单，带上 SessionToken var response = await container.ReadItemAsync<Order>( orderId, new PartitionKey(customerId), new ItemRequestOptions { SessionToken = sessionToken }); // 将新的 SessionToken 写回响应头，维持会话 HttpContext.Response.Headers["x-ms-session-token"] = response.Headers["x-ms-session-token"];

这段代码确保了“写后即读”的体验。

故障转移模拟与验证：为了验证多主的可靠性，我们手动模拟了区域故障：

1. 在 Portal 的“复制数据”页，找到Germany West Central区域，点击“禁用”。
2. 等待状态变为“已禁用”。
3. 此时，所有发往法兰克福的请求，会自动被 SDK 重定向到东京。
4. 我们用 JMeter 对/api/orders接口施加 1000 RPS 的压力，观察 P95 延迟。结果显示，延迟从 45ms 上升到 68ms（增加了 23ms，主要是网络 RTT），但0% 请求失败，0% 429 错误。5 分钟后，重新启用法兰克福区域，系统自动恢复，无需任何人工干预。

实操心得：永远不要在生产环境依赖“自动故障转移”的神话。必须定期（如每月）进行真实的故障演练。我们有一个自动化脚本，会随机禁用一个区域，运行 5 分钟的全链路压测，然后自动生成报告。这让我们在去年一次真实的法兰克福区域网络中断中，做到了 0 用户投诉。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

5.1 问题速查表：从现象到根因的快速定位

5.2 “邻居效应”（Noisy Neighbor）：一个被严重低估的隐形杀手

“邻居效应”是指，一个租户（Tenant）或一个业务模块的突发流量，耗尽了共享分区的 RU，导致同一分区内的其他租户/模块服务降级。这在 SaaS 多租户场景中尤为致命。

我们一个客户，其 SaaS 平台用/tenantId作分区键，理论上应该隔离。但问题出在tenantId的分布上：前 10 个大客户（占总客户数 0.1%）贡献了 80% 的数据量和 90% 的写入流量。他们的数据被哈希到了少数几个物理分区上。结果，当其中一个大客户进行数据迁移（批量导入 50 万条记录）时，它所在的分区 RU 消耗瞬间达到 100%，导致同分区的其他 200 个小客户的所有查询都超时。

根因分析发现，tenantId虽然是业务字段，但它的值（如acme-corp、global-inc）在哈希后，并没有均匀分布到 128