数据中心选型：全球枢纽、云区域与广告流量部署

全球化业务选数据中心，本质上是一次可用性决策，而不只是「哪家云便宜」：机房选在哪，直接决定了用户离服务有多远、机房级故障发生时有没有邻近节点能接住流量。它是广告服务上云实战的自然延伸——把竞价服务送上云之后，下一个问题就是「云该开在哪几个区域」；也和冗余与容灾、依赖韧性讨论的是同一类问题：如何让系统在故障和流量波动下仍然可用，只是这里的变量换成了地理覆盖范围、网络枢纽层级、海底电缆登陆点与云区域可用性。本篇面向广告类全球化业务，系统梳理地区划分、Tier 枢纽、云区域能力与实际请求分布，最终给出新加坡 + 弗吉尼亚为主、法兰克福为辅的部署建议，并附双活同步架构示意；落地时机房布局还要与冗余与容灾中的同城/异地多活选型一起看，才是完整的可用性方案。

TL;DR

• 数据中心选型是可用性决策的地理维度：机房布局决定延迟基线，也决定机房级故障时能否就近切换，与冗余、多活选型是同一套问题的两面。
• 选型要同时看四条约束：地理覆盖 / 网络枢纽层级、真实流量分布、成本（跨区 egress + 冗余）、合规（数据驻留）——延迟只是其中一维，合规往往是硬约束。
• Tier 1 枢纽（如硅谷、新加坡、法兰克福、弗吉尼亚）是跨区互联与低延迟的关键锚点。
• 广告流量往往高度集中在少数国家；用分布数据比「感觉」更靠谱。
• 推荐组合：弗吉尼亚（US-East / us-east-1）扛美洲主流量，新加坡做亚太枢纽，法兰克福作欧洲备选；SG+VA 可覆盖约一半请求。全文统一用 SG+VA（弗吉尼亚），§6 的「新加坡 + 硅谷」是 US-West 变体，取舍见该节。
• 延迟要映射到业务：区域 RTT 吃掉竞价 tmax 预算——RTT 逼近 tmax 时应就近部署或 no-bid，否则出价发出即注定超时（与依赖韧性的超时预算同一原理）。
• 双活：亚洲读写新加坡、美洲读写弗吉尼亚/硅谷一带，主库实时同步、缓存可异步——但跨区复制延迟会让频控/预算状态短暂不一致，是超投超支的常见根因（见 §11 跨区状态一致性）。同步/异步取舍见冗余与容灾。
• 跨区一致性陷阱：复制 lag 拉大时，两区各看本地状态会导致全局预算超投、频控双计——异步复制的状态绝不能当强一致用（见 §11 跨区状态一致性）。

Table of contents

1. 全球主要地区（关键市场速览）

全球地区划分是数据中心选型的地理坐标系。以下只列出后文流量分析与部署建议会直接用到的关键市场；其余国家可按 ISO 3166-1 标准查询，不逐一列出，以免表格喧宾夺主。

1.1 美洲（Americas）

中美洲与加勒比（哥斯达黎加、巴拿马等）、南美其余国家（阿根廷、智利、哥伦比亚等）广告流量占比均个位数，多依赖美国或巴西节点中转，选型时按整体区域看待即可。

1.2 欧洲（Europe）

北欧（瑞典、挪威、芬兰）、南欧（意大利、西班牙、葡萄牙）与东欧其余国家（波兰、乌克兰、保加利亚等），流量规模较小，一般靠法兰克福/阿姆斯特丹枢纽统一覆盖，不需要单独设点。

1.3 亚太（Asia-Pacific）

韩国、马来西亚、泰国、菲律宾、越南、巴基斯坦、孟加拉国等东南亚/南亚市场，及新西兰，多依赖新加坡或孟买节点覆盖，具体流量占比见 §4。

1.4 中东与非洲（MEA）

以色列、土耳其、埃及、肯尼亚等中东/非洲其余国家流量占比小，通常依赖迪拜或南非开普敦节点中转。中国香港作为国际互联网出口枢纽在 §2.1 单独讨论；其余地区（澳门、台湾等）可按 ISO 3166-1 查询。

注：ISO 国家代码遵循国际标准化组织（ISO 3166-1）标准；台湾地区的政治地位存在争议，此处不代表政治立场。

2. 全球网络枢纽

Tier 1 顶级枢纽、Tier 2 新兴市场、Tier 3 边缘与 CDN 覆盖。

2.1 Tier 1：顶级枢纽

北美

欧洲

亚太

2.2 Tier 2：新兴枢纽

东南亚

南亚

南美

中东

2.3 Tier 3：边缘与 CDN 覆盖

2.4 全球海底电缆

海底电缆承载了全球 99% 的国际互联网流量，是连接各大洲的核心基础设施。以下列出主要电缆节点及其对延迟与业务部署的影响。

2.4.1 核心海底电缆节点

跨太平洋（美↔亚）关键节点

跨大西洋（美↔欧）关键节点

亚欧（新↔欧）关键节点

2.4.2 新兴区域海底电缆

东南亚区域互联

南美互联

非洲互联

3. 主流云厂商区域布局

注：本节所有「区域数 / 可用区数」均为参考值，云厂商持续新建区域，数字会随时间变化——选型时应以厂商官方的 Global Infrastructure 页面为准，这里只用来做量级对比，不作为精确依据。

3.1 AWS

全球覆盖最广，区域遍布六大洲

3.1.1 核心区域

3.1.2 新兴市场

3.1.3 扩展计划

• 马来西亚（吉隆坡）、新西兰（奥克兰） 等新区域已陆续上线或规划中
• 专线接入：AWS Direct Connect 在 100+ 城市提供私有连接

3.2 阿里云

30 个区域，89 个可用区

3.2.1 核心区域

3.2.2 新兴市场

3.2.3 中国区特殊性

• 国内区域：需独立ICP备案，与国际区隔离（如北京、上海）
• 合规性：支持中国网络安全法数据本地化要求

3.3 华为云

全球覆盖：30+ 区域，70+ 可用区

特点：

• 强项：5G+云协同（边缘计算）、中国/欧洲合规性
• 弱点：美国市场受限（政治因素）、国际带宽稳定性弱于AWS

3.4 Linode

全球覆盖：11 个区域（聚焦欧美）

特点：

• 强项：极简运维、高性价比（无流量附加费）
• 弱点：无多AZ容灾、无企业级SLA（适合非关键业务）

3.5 云厂商横向对比

4. 广告流量的国家与地区分布

示例日流量请求总数：300 亿。

其余尼日利亚、秘鲁、孟加拉国、西班牙、意大利、日本、哥伦比亚、保加利亚、匈牙利、荷兰、奥地利、捷克等约 12 个国家，合计约占 7% 的请求量，均为 T2/T3 市场，请求量分散、单国占比不足 1.1%，通过所属地区最近的枢纽或 CDN 边缘节点覆盖即可，不必单独设点，故不再逐一列出。

广告请求高度集中：印度、美国等 Top 国家占大头。

5. 部署选型：新加坡 + 弗吉尼亚

VA 主美洲、SG 亚太枢纽、法兰克福欧洲备选；SG+VA 约覆盖一半请求。

一句话：广告全球化部署优先 弗吉尼亚 + 新加坡，欧洲流量起来再加重 法兰克福。

根据全球广告请求分布、网络延迟优化、成本效益及云服务商区域覆盖能力，最适合部署的两个主节点为：

5.1 新加坡（Singapore）

AWS ap-southeast-1 / Azure Southeast Asia

核心优势：

• 覆盖高流量亚太市场：直接服务印尼（8.19%）、菲律宾（4.96%）、泰国（3.00%）、越南（2.29%）、马来西亚（2.51%），合计约覆盖 20.95% 的全球广告请求。通过低延迟（<50ms）连接南亚（印度、孟加拉国）和中东（沙特、阿联酋）。
• T1 网络枢纽地位：海底电缆枢纽（APG、SEA-ME-WE 6），直达欧洲和北美。阿里云/AWS/Azure 均在此设立核心节点，合规性完善（支持 GDPR、伊斯兰金融）。
• 成本与性能平衡：相比北美/欧洲节点成本低约 20%，适合高流量新兴市场。

适用场景：

• 亚太及中东广告流量的实时处理和投放。
• 需要兼顾中国出海业务的混合架构（通过香港节点中转）。

5.2 美国弗吉尼亚（Virginia）

AWS us-east-1 / Azure East US

核心优势：

• 覆盖美洲及全球高价值流量：直接服务美国（16.52%）、巴西（5.41%）、墨西哥（1.94%）、加拿大（1.49%），合计覆盖约 25.36% 的全球广告请求。通过骨干网低延迟连接欧洲（法兰克福约 60ms）和南美（圣保罗约 100ms）。
• 全球云计算核心枢纽：AWS 最大区域，服务最全（EC2/S3/Lambda 等），SLA 99.99%；EC2 定价比硅谷低约 10–15%。
• 扩展性与容灾：可作为欧洲/亚洲流量的备份节点（如新加坡故障时通过法兰克福迂回）。

适用场景：

• 北美及南美广告高并发请求处理。
• 依赖 AWS 全球服务（如 Kinesis 实时数据分析）的业务。

5.3 备选：法兰克福（Frankfurt）

AWS eu-central-1

核心优势：

• 覆盖欧洲及中东非：直接服务英国（3.12%）、德国（0.41%）、法国（0.56%）、沙特（1.71%），合计约 5.8% 高价值请求。通过迪拜节点（Azure UAE）覆盖中东，通过南非开普敦（AWS af-south-1）辐射非洲。
• 合规与稳定性：GDPR 合规，DE-CIX 为全球最大互联网交换点。

适用场景：

• 欧洲金融/工业广告及数据主权合规需求。

5.4 为什么选 SG + VA

1. 流量覆盖最大化：新加坡 + 弗吉尼亚可覆盖超 46% 的全球广告请求（亚太 + 美洲核心市场）；剩余地区（如欧洲、非洲）可通过 CDN 或边缘节点补充。
2. 延迟与成本最优：新加坡亚太延迟最低、成本低于欧美；弗吉尼亚美洲延迟最低、资源定价最优。
3. 架构互补：新加坡专注高增长新兴市场，弗吉尼亚服务成熟高价值市场；两者通过跨洋电缆（MAREA、PLCN 等）互联，延迟可控（约 150–200ms）。

5.5 备选调整方案

• 若欧洲流量占比提升：将弗吉尼亚替换为 德国法兰克福（AWS eu-central-1），可覆盖欧洲（约 8.37%）+ 部分中东/非洲流量。
• 若南亚流量优先：替换法兰克福为 印度孟买（AWS ap-south-1），专注印度（27.74%），但需牺牲欧洲本地化覆盖。
• 若成本敏感：将弗吉尼亚替换为 俄勒冈（AWS us-west-2），可节省约 20% 成本，但延迟增加 10–15%。

5.6 部署策略

• 主节点：弗吉尼亚（全球核心）。
• 区域枢纽：新加坡（亚太核心）。
• 边缘补充：
  • 欧洲：法兰克福（通过弗吉尼亚备份）。
  • 南亚：孟买（通过新加坡覆盖）。

此组合在性能、成本、覆盖率三个维度上达到最佳平衡，适合 90% 以上的全球化广告业务需求。

5.7 最终建议

此组合实现全球覆盖、低延迟、成本可控三重目标，适合广告、电商、游戏等全球化业务。

6. 分配表示例：新加坡 + 硅谷（US-West 变体）

一句话：主推方案是 §5 的 SG + VA（弗吉尼亚，US-East / us-east-1）；本节的「新加坡 + 硅谷」是同一双活骨架的 US-West 变体，仅换了美洲落点，用来演示逐国路由分配。

先把两个容易混淆的美国落点讲清楚——它们都是 Tier 1，但覆盖侧重不同：

取舍规则：默认选弗吉尼亚（覆盖面和到欧洲/南美的延迟都更优）；只有当美洲流量集中在西海岸、或希望缩短「美洲 ↔ 新加坡」跨太平洋同步延迟时，才把美洲落点换成硅谷/俄勒冈。俄勒冈（us-west-2）比硅谷（us-west-1）价格更低、可用区更多，成本敏感时优先俄勒冈。下表以硅谷为例演示逐国路由（换成弗吉尼亚时，美西 10–30ms 对应改为美东，欧洲/南美延迟更低）：

菲律宾、泰国、巴基斯坦、越南等东南亚/南亚国家的路由模式与印尼/马来西亚一致——就近接入新加坡；墨西哥、加拿大与美国同属一组，就近接入硅谷；法国、德国、俄罗斯、韩国的路由模式与英国/日本类似（跨洋 + 骨干网接入硅谷），延迟量级相近，不再逐条列出。

graph TD
    A[用户请求-亚洲] -->|写入| B[新加坡主库]
    A -->|读取| C[新加坡缓存]
    D[用户请求-美洲] -->|写入| E[硅谷主库]
    D -->|读取| F[硅谷缓存]
    B -->|实时同步| E
    C -->|异步同步| F
    G[监控系统] -->|校验| B
    G -->|校验| E

下图与上方 Mermaid 对应，展示亚洲读写新加坡、美洲读写硅谷及双活同步关系：

亚洲读写新加坡、美洲读写硅谷；主库实时同步，缓存可异步。

7. 区域延迟 → 竞价业务映射（RTT vs tmax）

前几节的延迟都是「网络指标」；对广告业务，真正要回答的是这个延迟能不能在竞价窗口内完成一次出价。RTB 里，交易所（SSP/Exchange）给每个竞价请求一个 tmax（典型 100–120ms），DSP 必须在这个时间内返回出价，否则被判超时、当作 no-bid 丢弃。

关键换算：

DSP 有效计算预算 = tmax − 2 × RTT(Exchange ↔ DSP 节点) − 序列化/排队开销

也就是说，区域 RTT 会先从 tmax 里扣掉往返两趟，剩下的才是留给特征查询 + 模型打分的时间。RTT 越大，计算窗口越窄；一旦 2 × RTT 逼近甚至超过 tmax，出价在发出的那一刻就注定超时——这本质上就是依赖韧性里「调用链超时预算」的地理版：每一跳的 RTT 都在消耗全局 deadline，剩余预算不足就该主动放弃（no-bid），而不是发一个注定被丢的请求白烧 QPS。

以 tmax = 120ms、DSP 计算约需 30ms 为例：

2×RTT 越过 tmax 红线，出价发出即注定超时——就近部署或 no-bid。

一句话：延迟不是「越低越好」的美观指标，而是竞价可达性的硬门槛——RTT 把 tmax 吃穿，就近部署或 no-bid，二选一。

7.1 印度：孟买何时从「就近边缘」升级为「主竞价节点」

印度贡献 27.74% 的请求，是全篇最大的单一市场，但 §5 把它放在「通过新加坡覆盖」的位置。上面的换算解释了为什么这不能一直成立：印度用户/交易所到新加坡的单程 RTT 约 60–80ms，往返就吃掉 120–160ms，在 tmax=100~120ms 下竞价窗口已经归零。当满足以下任一条件时，孟买（AWS ap-south-1）就应从「就近 CDN 边缘 / 日志回传点」升级为主竞价节点：

• 印度竞价请求的 tmax 超时率（no-bid due to timeout）随流量上涨、持续高于可接受阈值（如 >2%）；
• 印度本地交易所/媒体占比提升，要求 DSP 在境内响应；
• 触发数据驻留合规（见 §9，印度 DPDP Act）——此时是合规而非延迟驱动，必须本地部署。

升级后印度请求就近落 ap-south-1，RTT 降到个位数～20ms，竞价窗口恢复；孟买到新加坡再走区域内低延迟链路做状态同步。判断准则和 §7 一致：先看 RTT 是否吃穿 tmax，再看合规是否强制本地——两者任一成立即升级，不要等超时率恶化才被动扩区。

8. 跨区部署的成本模型

多活不是「多开几个区域」这么简单——每加一个活跃区，成本沿复制 egress、双活带宽、存储冗余、区域实例价差四条线同时增长。选型时要把「覆盖率」和「成本」放在同一张表上看，而不是只追覆盖。

8.1 成本构成粗算

假设双活各承载一半流量，跨区需要持续复制的是状态流（预算计数、频控计数、用户画像增量），而非原始曝光日志（原始日志就近落盘、就近计算，不跨区搬）。设状态流约 2 TB/天 ≈ 60 TB/月：

一句话：跨区成本的大头不是多买的实例，而是持续的复制 egress 和被 ×N 的冗余存储——原始日志就近处理、只跨区复制「必须一致的状态」，是控成本的第一原则。

8.2 覆盖率 vs 成本的取舍

覆盖率的边际收益是递减的，而复制成本往往是超线性的：

• 2 活（SG+VA）：覆盖约 46%，跨区复制只有 1 对链路（SG↔VA）。
• 加第 3 活（法兰克福）：覆盖只多约 6%（欧洲），但如果三区互为主备做全网状复制，复制链路从 1 对变成 3 对，egress 近似翻倍；运维、对账、故障演练的复杂度也非线性上升。

因此除非欧洲流量显著上涨或GDPR 要求 EU 数据必须落欧洲区（见 §9），否则不轻易上第三活——多数广告业务在「两点覆盖 46% + CDN 边缘补齐长尾」的组合下，性价比明显优于强行三活/四活。这与冗余与容灾的结论一致：多活层级要按 RPO/RTO 目标和成本约束来定，不是越多越好。

9. 数据驻留与隐私合规

前面所有选型都是延迟/成本驱动的；但在越来越多的市场，合规是先于延迟的硬约束——法律规定某类数据必须留在境内，就算隔壁区延迟更低、成本更省，也不能把数据搬过去。合规因此会反向约束机房/区域选型。

consent（同意）分区是 AdTech 特有的一层：在 GDPR 区，用户未通过 CMP（如 IAB TCF v2.2）授予个性化广告同意时，请求不能进入画像/定向/频控画像管道，只能走非个性化（contextual）链路。工程上意味着：

• 数据面隔离：EU 请求的 PII 和 consent 状态在欧盟区内闭环，跨区同步的只能是已脱敏/聚合的指标，而非原始 PII。
• 路由要带合规维度：GSLB/DNS 不能纯按延迟路由——EU 用户即使离某个非欧盟区更近，也必须被路由到欧盟境内节点（见 §10 的 geo-routing 兜底）。

一句话：延迟决定「最好放哪」，合规决定「不许放哪」——两者冲突时，合规优先，这也是「延迟最低点」未必是「合法落点」的根本原因。

10. GSLB / DNS 地理路由与区域路由（配置与伪代码）

把 §7（延迟）和 §9（合规）落到工程上，靠的是几层配合：入口的 GSLB/DNS 路由决定请求进哪个区（§10.1），区域路由决定用户读写落哪个区（§10.2），跨区数据库复制 + 状态一致性策略决定数据怎么放、怎么同步（§10.3–10.5），健康检查 + failover在机房级故障时把流量切走（§10.6）。以下均以 SG + VA 双活为例给出可直接参照的配置与伪代码。

10.1 DNS：延迟路由（性能） + 地理路由（合规兜底）

以 AWS Route 53 为例。默认用 latency-based routing 把用户解析到延迟最低的节点：

{
  "Comment": "latency-based routing for bid.example-dsp.com",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "bid.example-dsp.com",
        "Type": "A",
        "SetIdentifier": "sg",
        "Region": "ap-southeast-1",
        "AliasTarget": {
          "HostedZoneId": "Z_SG_NLB",
          "DNSName": "sg-nlb.ap-southeast-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "bid.example-dsp.com",
        "Type": "A",
        "SetIdentifier": "va",
        "Region": "us-east-1",
        "AliasTarget": {
          "HostedZoneId": "Z_VA_NLB",
          "DNSName": "va-nlb.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }
  ]
}

但纯延迟路由会违反 §9 的合规约束，所以欧盟等数据驻留区要用 geolocation routing 做更高优先级的兜底——EU 用户无论离哪个区近，都强制解析到欧盟境内节点：

{
  "Action": "UPSERT",
  "ResourceRecordSet": {
    "Name": "bid.example-dsp.com",
    "Type": "A",
    "SetIdentifier": "eu-geo",
    "GeoLocation": { "ContinentCode": "EU" },
    "AliasTarget": {
      "HostedZoneId": "Z_FRA_NLB",
      "DNSName": "fra-nlb.eu-central-1.elb.amazonaws.com",
      "EvaluateTargetHealth": true
    }
  }
}

EvaluateTargetHealth: true 让 Route 53 在某区健康检查失败时自动把解析摘到其余健康区——这是 DNS 层的故障切换，配合冗余与容灾的多活切换一起构成机房级容灾。

10.2 区域路由：合规优先，其次就近

进入区域后，用区域路由决定用户的读写落点。规则的顺序很关键：合规硬约束先判，其次才按延迟就近；同一用户尽量稳定落到同一区，避免跨区往返与写冲突。

# 区域路由：合规优先于延迟，同一用户稳定落一个区、避免跨区往返
EU = {"DE", "FR", "GB", "NL", "AT", ...}

def route_region(user):
    if user.country in EU:            # GDPR：EU PII 必须留在欧盟区
        return "eu-central-1"
    if user.country == "RU":          # 242-FZ：俄罗斯数据本地化
        return "ru-local-idc"
    if user.country == "IN" and india_upgraded():   # 见 §7.1
        return "ap-south-1"
    return nearest_by_latency(user)   # 其余按 RTT 就近（SG / VA）

10.3 跨区状态复制：带 lag 保护的预算/频控读取

预算和频控是双活里最容易出错的状态（见 §11）。核心原则是本地快照做实时判断、跨区复制值只做校正，并对复制滞后留安全余量：

# 预算判断：本地快照（毫秒级）+ 跨区复制值（可能滞后），取保守侧
def can_bid(campaign, region):
    local_spent  = local_budget_cache.get(campaign)       # 本区实时快照
    global_spent = replicated_budget.get(campaign)         # 跨区复制值，可能滞后

    # 复制滞后期间，两区各自只看本地会双双超投；用较大值 + 安全余量收敛
    effective = max(local_spent, global_spent) + safety_margin(campaign, region)
    return effective < campaign.daily_budget

safety_margin 应随当前跨区复制 lag 动态调整：lag 越大，余量越保守（宁可少投也不超投）。这需要把复制 lag 当作一等监控指标——即「把关键滞后量做成 SLI 并告警」的做法。

10.4 跨区数据库复制配置

主数据（campaign、定向规则等读多写少的元数据）用单主 + 跨区只读副本：VA 写、SG 就近读，故障时把副本提升为主。以 AWS Aurora Global Database（Terraform）为例：

# Aurora Global Database：us-east-1 主写，ap-southeast-1 跨区只读副本
resource "aws_rds_global_cluster" "adx" {
  global_cluster_identifier = "adx-global"
  engine                    = "aurora-postgresql"
  engine_version            = "15.4"
}

resource "aws_rds_cluster" "primary" {
  provider                  = aws.us_east_1          # 主库：弗吉尼亚
  cluster_identifier        = "adx-primary"
  global_cluster_identifier = aws_rds_global_cluster.adx.id
  engine                    = aws_rds_global_cluster.adx.engine
  engine_version            = aws_rds_global_cluster.adx.engine_version
  master_username           = var.db_user
  master_password           = var.db_password
}

resource "aws_rds_cluster" "secondary" {
  provider                  = aws.ap_southeast_1     # 只读副本：新加坡
  cluster_identifier        = "adx-secondary"
  global_cluster_identifier = aws_rds_global_cluster.adx.id
  engine                    = aws_rds_global_cluster.adx.engine
  engine_version            = aws_rds_global_cluster.adx.engine_version
  # 物理复制，典型跨区 lag < 1s；主库故障时可提升为主（见 §10.6）
  depends_on                = [aws_rds_cluster.primary]
}

要点：只读就近能吃掉大部分读延迟；但复制是异步的，强一致的实时状态（预算/频控）绝不能靠它跨区读——那类状态另走 §10.5 的方案。计费等最终一致数据用 DynamoDB Global Tables 这类多主复制也可，但要接受写冲突后按 last-writer 收敛 + 对账。

10.5 频控 / 预算：region-local 计数 + 异步汇总

预算/频控是写多、要求实时的状态，不适合跨区强一致读。做法是本区 Redis 就近计数（毫秒级判断）+ 异步汇总把各区增量聚合后回写，全局只做最终一致的校正：

# 频控：本区 Redis 实时计数；跨区差异靠异步汇总回写的 :remote 计数校正
# 同一 identity 就近固定路由到一个区（见 §11），正常只落一个区，跨区计数只是兜底
def check_and_incr_freq(user_id, campaign, region, cap):
    r = redis_local[region]
    key = f"freq:{{{user_id}}}:{campaign}"          # hash-tag 保证同槽，本地原子操作
    local  = int(r.get(key) or 0)                   # 本区实时计数
    remote = int(r.get(key + ":remote") or 0)       # 其他区汇总值（异步，可能滞后）
    if local + remote >= cap:
        return False                                # 已达 cap，走非个性化或不曝光
    r.eval(INCR_WITH_TTL, 1, key, ttl_until_midnight())  # incr + 当日过期，原子
    return True

# 异步汇总 worker：消费各区增量事件流 → 中心聚合 → 回写各区 :remote（最终一致）
def rollup_worker():
    central = FreqStore()
    for region in REGIONS:
        central.merge(consume_freq_deltas(region))   # 消费本区 Kafka 增量
    snapshot = central.snapshot()
    for region in REGIONS:
        write_remote_counts(region, snapshot)        # 回写其他区计数，周期性收敛

预算同理：不共享单池实时扣减，而是按区域预分配子配额（如 VA 60%、SG 40%），各区在子配额内自治判断，汇总任务周期性再平衡剩余额度——这正是 §11 的核心设计方向。

10.6 健康检查与区域 failover 脚本

DNS 层的 EvaluateTargetHealth（§10.1）依赖健康检查结果；关键是健康检查要覆盖竞价关键路径的下游依赖（缓存/DB/模型服务），而不是只回一个静态 200。连续失败达阈值时，把该区从 GSLB 摘除，并在必要时提升数据库副本为主：

#!/usr/bin/env bash
# 区域健康检查 + failover：连续失败则把该区从 GSLB 摘除，必要时提升 DB 副本
set -euo pipefail

REGION="$1"                                    # e.g. us-east-1
ENDPOINT="https://bid-${REGION}.example-dsp.com/healthz"
FAILS=0; THRESHOLD=3

while true; do
  # 健康检查须校验下游依赖（缓存/DB/模型），而非仅 HTTP 200
  if curl -fsS --max-time 1 "$ENDPOINT" | grep -q '"deps":"ok"'; then
    FAILS=0
  else
    FAILS=$((FAILS + 1))
    echo "$(date -u) ${REGION} unhealthy (${FAILS}/${THRESHOLD})"
    if [ "$FAILS" -ge "$THRESHOLD" ]; then
      # 1) 把该区权重置 0，Route 53 将解析摘到其余健康区（配合 §10.1）
      aws route53 change-resource-record-sets \
        --hosted-zone-id "$ZONE_ID" --change-batch "file://drain-${REGION}.json"
      # 2) 若故障区是数据库主库，提升其余区的 Aurora 副本为主
      if [ "$REGION" = "us-east-1" ]; then
        aws rds failover-global-cluster \
          --global-cluster-identifier adx-global \
          --target-db-cluster-identifier "$SECONDARY_CLUSTER_ARN"
      fi
      alert "region ${REGION} drained + failed over"   # 通知值班
      exit 1
    fi
  fi
  sleep 2
done

切走之后，剩余健康区要能扛住被转移过来的流量——这要求容量规划时预留 failover 余量（N+1），否则一区故障把流量全压到另一区，会引发二次雪崩（与依赖韧性、冗余与容灾呼应）。

11. 跨区状态一致性：预算与频控

双活下，预算与频控若依赖跨区异步复制，lag 一拉大就会出现「两区各看本地状态、全局超投 / 频控双计」——异步复制的状态绝不能当强一致用。

设计原则：

• 预算：不共享单池实时扣减，而是按区域预分配子配额（如 VA 60%、SG 40%），各区在子配额内自治判断，汇总任务周期性再平衡剩余额度。
• 频控：按 identity 就近固定路由到一个区计数（同一用户始终落同一区），跨区只做聚合校正。
• 可观测：把跨区复制 lag 做成 SLI + 告警，超阈值自动调大 safety_margin 并降级为保守出价（见 §10.3）。
• 对账：建立跨区最终一致对账任务，以事件流为准回补差异。

这与异步与削峰里反复强调的一点同源：跨区/异步链路只能保证最终一致，不能在关键路径上当强一致用。

一句话：双活的坑几乎都出在「拿异步复制的状态做强一致判断」——预算和频控要么按区域预分配配额自治，要么接受最终一致 + 对账，绝不能假设跨区能实时一致。

12. 反模式与落地清单

12.1 反模式

• 只看延迟不看合规：把 EU 用户 PII 复制到 VA/SG 图延迟低——直接违反 GDPR（见 §9）。
• 纯延迟路由、无合规兜底：GSLB 只按 RTT 解析，EU 用户被路由到境外节点。
• 共享单池预算跨区实时扣减：复制滞后期间两区双双超投（见 §11）。
• 跨区读频控当强一致：同一用户在两区被重复计数，cap 形同虚设。
• RTT 已吃穿 tmax 仍强行远程竞价：出价发出即注定超时，白烧 QPS，不如就近部署或 no-bid（见 §7）。
• 忽略 egress 成本盲目上三活/四活：覆盖只多几个点，复制 egress 却翻倍，运维复杂度非线性上升。
• 主节点单区无 AZ 冗余：机房级故障无就近接管，双活退化成「双单点」（与冗余与容灾呼应）。
• 健康检查只探 HTTP 200：下游依赖（缓存/DB/模型）已挂但入口仍「健康」，故障区不被摘除，流量继续打进黑洞（见 §10.6）。
• failover 无容量余量：一区故障把全部流量压到另一区，剩余区被打爆引发二次雪崩——双活须按 N+1 预留 failover 余量。
• 把孟买长期当纯 CDN 边缘：印度 27.7% 流量下竞价预算不足仍绕行新加坡，超时率高企（见 §7.1）。
• 原始日志跨区搬运：原始曝光/点击就近落盘即可，跨区只复制必须一致的状态，否则 egress 成本失控（见 §8.1）。

12.2 落地清单

多活机房选型与部署上线前逐项确认：

• 选型同时评估**延迟/覆盖、成本（egress + 冗余）、合规（数据驻留）**三条约束，而非只看延迟
• 每个主竞价节点确认区域 RTT 在目标 tmax 预算内；2×RTT 逼近 tmax 时就近部署或 no-bid
• EU / 印度 / 俄罗斯等数据驻留区域的 PII 不跨境复制，consent 分区落地（未授权只走 contextual 链路）
• 预算按区域预分配子配额，不依赖跨区强一致实时扣减；有周期性再平衡
• 频控按 identity 就近固定路由到一个区计数，避免跨区双计
• 跨区复制 lag 有监控 + 告警（做成 SLI），超阈值自动收紧 safety_margin / 降级为保守出价
• GSLB/DNS 同时配置 latency routing（性能）+ geo routing（合规兜底），健康检查驱动故障切换
• 每个主节点至少跨 2 个 AZ，机房级故障有就近接管，双活不退化成双单点
• 健康检查覆盖竞价关键路径的下游依赖（缓存/DB/模型），且 failover 后剩余区有 N+1 容量余量接住转移流量
• 主数据（campaign/元数据）用单主 + 跨区只读副本就近读，实时状态（预算/频控）另走 region-local 计数 + 异步汇总，不靠副本跨区强一致读
• 跨区 egress 成本纳入容量规划，新增 region 前算清「覆盖增量 vs 成本增量」
• 有跨区最终一致对账任务（预算/计费/频控），并演练过区域级故障切换

小结

• 数据中心选型是可用性问题的地理维度：机房布局先天决定了延迟基线，也决定机房级故障发生时有没有邻近节点能接住流量——这与冗余与容灾里讨论的同城/异地多活是同一个决策的两个视角，只是这里的输入变量是网络枢纽、海底电缆与云区域，而不是抽象的 RTO/RPO。
• 枢纽等级 ≠ 本地流量大小：新加坡本地广告请求占比不到 1%，却因为网络拓扑（海底电缆枢纽 + 三大云核心节点）成为亚太流量的最佳承载点——选型要看”连接谁的能力”，不能只看”本地市场有多大”。
• 推荐组合：弗吉尼亚扛美洲，新加坡扛亚太，法兰克福作欧洲/中东非补充；SG + VA 两点即可覆盖约 46% 的全球广告请求，覆盖-成本-延迟三者的平衡点在多数场景下优于强行做三活甚至四活。
• 双活只是起点：本篇的新加坡 + 硅谷（或弗吉尼亚）双活示意，本质是冗余与容灾中”异地多活”形态在数据中心选型层面的落地——真正上线前，仍需要按该篇的框架把写冲突、会话黏性、故障演练等一致性和容灾细节补齐，选好机房只是第一步。

数据中心选型把服务化与部署的最后一环收在了地理维度上：广告服务上云实战解决了「服务怎么跑在云上」，本篇接着回答「云该开在哪几个区域」；再往上，则回到高可用系统设计反复强调的原则——先量化可用性目标，再按需叠加手段。地理选型同样如此，不必一步到位铺满全球，先把核心市场的两三个节点做扎实，再随流量增长逐步扩展。