想象你是一家全国连锁快递“小云速递”的老板。你只有一部 400 总机号，但北京、武汉、成都、广州的分中心都在电信局“认领”了这个号码——无论客户从哪打来，电话网络都会自动转给离他最近、最不忙的那家分中心。客户完全不知道号码背后藏着好几个分中心，他只知道：打这个电话，响应最快。这套“一号多地认领、电话网络自动就近转接”的魔法，就是本文的主角——Anycast。 有了总机，接下来要想的事就多了：分中心该开在哪些城市？电话来了转给谁？某家分中心着火了怎么办？分中心能不能顺便备点常用货（缓存），甚至现场组装一下（边缘计算）？本文跟着“小云速递”的扩张故事，把这些问号一个个解开，让你彻底搞懂边缘节点调度与流量就近接入。

岗位关联

对云架构师、DevOps 工程师而言，Anycast 与边缘调度是搭建全球低延迟基础设施的基石，掌握它能让你从“会部署服务器”进阶为“能设计一张全球网络”。

目录
  1. 可视化演示
  2. Anycast路由原理
  3. 节点选址策略
  4. 流量就近接入
  5. 全局负载调度
  6. 容错与冗余
  7. CDN与边缘演进
  8. 运维监控实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Anycast三模式：路由原理（AIP任播IP→BGP就近路由→U0/U1/U2用户分别接入E0/E2/E3最近边缘节点+UNI/ANY/MLT三类型对比）、CDN部署（L1 Anycast DNS D0-D2→L2边缘节点E0-E4五区域AS/EU/US/SA+L3源站ORG+节点分布统计）、流量调度（六维负载雷达CPU/MEM/NET/DISK/CONN/QPS+BGP/WRR/LC/GEO/RTT五策略+五节点流量分布柱状图）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Anycast BGP就近路由原理 多个边缘节点共享同一AIP地址，BGP路由用户到拓扑最近节点 U0→E0、U1→E2、U2→E3分别就近接入，降低延迟 Anycast = 1 IP + N Nodes + BGP(best path) 延迟15ms，3跳，可用性99%

Anycast路由原理

小云速递的第一家分中心开在北京后，老板发现广州的客户打电话总要等很久。于是他让武汉、广州的分中心也去电信局登记了同一个 400 号码。电信局之间有一本“通话地图”——学名叫 BGP（边界网关协议）——所有电话公司的交换机都照着这张地图找路。当广州客户拨打 400 电话，广州电信的交换机一查地图：哦，这个号码在我们本地就有登记，不用往北京发。于是电话直接被接进了广州分中心。

这就是 Anycast 的核心机制：多个物理位置共享同一个 IP 地址，每个位置通过 BGP 向全网通告“这个 IP 我也认领了”，路由器再按自己的路由策略选择“最近”的下一跳。对用户和 DNS 来说，全程只有一个 IP，完全无感知——接入发生在网络层，应用层不需要任何改动。

Anycast 的选路决策实际上是给每条候选路径打分取最优。BGP 会参考路径经过的运营商数量（AS 路径长度）和实测往返延迟（RTT，即从网络这端到那端再回来的时间），加权後挑最小的：

就这样，小云速递一分钱广告费没花，就把“总机号码”铺到了全国——客户永远在打“最近的那个分中心”。Anycast 天然解决了跨地域接入的第一个难题：让用户自己“够得着”最近的节点。

Pathbest=arg⁡min⁡p∈Routes(AS_len(p)×w1+RTT(p)×w2)\displaystyle Path_{best} = \arg\min_{p \in Routes} \left( AS\_len(p) \times w_1 + RTT(p) \times w_2 \right)
通俗地说：路由器手里攒着好几条去往同一个 IP 的路，它把每条路的“经过多少家公司”和“实测快不快”换算成分数，谁分低（代价小）就选谁。
  1. 候选路径集合 Routes路由器从 BGP 学到的、能通往目标 IP 的所有可选路径，就像电信交换机上列着“这个 400 号在哪些城市有登记”的一串名单。
    Routes={p1,p2,…,pk}Routes = \{ p_1, p_2, \dots, p_k \}
  2. AS 路径长度 AS_len路径穿过的自治系统（可以理解为各家运营商网络）数量，穿过的“关卡”越多，转发越慢、越不可控，代价越大。
    AS_len(p)AS\_len(p)
  3. 实测延迟 RTT这条路径的真实往返时延，毫秒级数值，能反映高峰期堵不堵，是“就近”最实在的度量。
    RTT(p)RTT(p)
  4. 加权求最小给路径长度和延迟分别配权重 \(w_1\)、\(w_2\)，相加得到总代价，用 \(\arg\min\) 找出代价最小的那条路径作为最终转发路径。
    arg⁡min⁡p(AS_len(p)×w1+RTT(p)×w2)\arg\min_{p} \left( AS\_len(p) \times w_1 + RTT(p) \times w_2 \right)

节点选址策略

总机号码铺开后，老板开始认真琢磨：下一个分中心开在哪？直觉是“哪里客户多开哪里”，但快递行业的账要算细。首先是用户密度分布：打开后台订单地图，珠三角订单占三成、成渝占两成，那这两个区域必须覆盖；其次是网络拓扑质量：一个城市客户多，但如果当地机房与主流运营商互联带宽很小，客户打电话照样卡，所以要选在骨干网枢纽、运营商互通好的机房；然后是成本效益评估：一线城市机房租约贵、电力贵，不能只追密度不看账单；最后是覆盖半径模型：假设一个分中心能高效服务周边 200 公里，那就按网格画圈，让每个圈既不重叠浪费、也不留空白。

把这套思路抽象成选址打分表，每个候选城市都算一遍总分：

小云速递靠这张打分表，没有拍脑袋开店，而是像插旗一样把分中心铺满了全国。选址的本质，是把“客户在哪、路好不好、房租贵不贵”换算成同一张评分卡。

Scorei=wG×Gi+wU×Ui+wN×Ni−wC×Ci\displaystyle Score_i = w_G \times G_i + w_U \times U_i + w_N \times N_i - w_C \times C_i
地理覆盖、用户密度、网络质量三个“加分项”乘上各自权重，再减去成本这个“减分项”，总分最高的城市胜出。
  1. 地理覆盖分 \(G_i\)该节点能覆盖的地理范围价值，覆盖客户越多分越高。
    Gi∈[0,1]G_i \in [0, 1]
  2. 用户密度分 \(U_i\)周边活跃用户占全网比例，珠三角 30% 用户就意味着这格拿高分。
    Ui=usersiuserstotalU_i = \frac{users_i}{users_{total}}
  3. 网络质量分 \(N_i\)机房与骨干网、主流运营商的互联带宽与质量，互联越好分越高。
    Ni∈[0,1]N_i \in [0, 1]
  4. 成本项 \(C_i\)机房租金、电力、带宽采购等综合成本，是减分项，前面用负号。
    −Ci-C_i
  5. 权重加权四类因子乘上 \(w_G, w_U, w_N, w_C\) 后求和，权重体现公司当前战略——要开疆拓土就把 \(w_U\) 调大，要省钱就把 \(w_C\) 调大。
    Scorei=wG×Gi+wU×Ui+wN×Ni−wC×CiScore_i = w_G \times G_i + w_U \times U_i + w_N \times N_i - w_C \times C_i

流量就近接入

分中心建好了，新的问题出现了：什么叫“近”？老板最初以为直线距离近就行，结果发现北京到天津直线 130 公里，但数据包要从北京绕到上海再回天津，反而比打到武汉还慢。原来互联网里的“近”不是地图上的近，而是网络路径的近——要看 RTT、要看运营商之间怎么互联。

于是总机调度系统引入了接入点选择：每个用户进来先测一批候选节点的 RTT，而不是默认选地理最近的；同时做延迟敏感路由：让测速探针每隔几秒更新一次全网 RTT 表格，哪条路堵了就换路。光换路还不够，还要会话保持策略——一个老客户正在通话中，不能因为路径分数微调就把他转到别家分中心，否则“喂喂喂”就断了。最后还有回源路径优化：如果天津分中心没货（缓存未命中），它去北京总仓取货也要选一条快路，不能傻走最堵的那条高速。

把“近”和“不忙”同时考虑，就得到调度公式：

小云速递的接线员们从此不再问“客户在哪”，而是问“哪个分中心又近又不忙”——就近接入不是地理学，是算出来的综合最优解。

Si=α×1RTTi+β×(1−Loadi)+γ×Availi\displaystyle S_i = \alpha \times \frac{1}{RTT_i} + \beta \times (1 - Load_i) + \gamma \times Avail_i
节点得分 = 延迟分 + 空闲分 + 稳定分。延迟越小、负载越低、可用性越高，得分越高，总机就把电话转给谁。
  1. 延迟项 \(\frac{1}{RTT_i}\)RTT 越大，倒数越小，所以延迟惩罚反映为低分；这是“近”的量化。
    1RTTi\frac{1}{RTT_i}
  2. 空闲项 \(1 - Load_i\)\(Load_i\) 是节点当前负载率（0 到 1），负载越高 \(1-Load\) 越小，防止客户都挤进同一家分中心。
    1−Loadi1 - Load_i
  3. 可用性项 \(Avail_i\)节点最近一段时间的可用率，经常抖动的节点即使近也要扣分。
    Availi∈[0,1]Avail_i \in [0, 1]
  4. 权重系数\(\alpha + \beta + \gamma = 1\)，体现业务侧重；实时互动看重延迟就把 \(\alpha\) 调大，下载业务看重吞吐就把 \(\beta\) 调大。
    α+β+γ=1\alpha + \beta + \gamma = 1
  5. 取最大者对每个候选节点算 \(S_i\)，取 max 作为最终接入点。
    S∗=max⁡i∈NodesSiS^* = \max_{i \in Nodes} S_i

全局负载调度

分中心多了，总机也要讲管理艺术。老板定下规矩：所有电话先打到一个“总调度台”（GSLB，全局负载均衡器），由它根据客户所在大区，先指向某几个分中心（比如华南客户只考虑广州和深圳），再由上一步的 Anycast 路由在 IP 层选具体机房。这就是典型的分层调度：GSLB 管大方向，Anycast 管最后一公里。

GSLB 不是瞎分配，它依赖健康检查机制——每隔几秒主动探测每个分中心“活着吗、忙不忙”，像老板时不时打电话到分中心问情况，占线三次就把它从导航里摘掉。分配时还讲究动态权重调整：新开业的成都分中心先给低权重 1，练熟了慢慢升到 3；双十一期间武汉爆仓，就把武汉的权重临时调低，把单子更多地转给长沙和郑州。这些策略背后的基础模型，是加权轮询：

有了这套总调度台，小云速递就像装了红绿灯的城市交通：每个分中心该吃多少流量，不再靠抢，而靠权重说了算。

Pi=Wi∑j=1NWj\displaystyle P_i = \frac{W_i}{\displaystyle \sum_{j=1}^{N} W_j}
节点 i 被选中的概率 = 自己的权重 ÷ 所有节点权重之和。权重高，接的单就多，但不至于垄断。
  1. 节点权重 \(W_i\)代表节点容量或管理员的期望流量份额，容量大的分中心权重高。
    WiW_i
  2. 总权重分母把所有候选节点的权重加总，得到一组权重下能分配的总份额。
    ∑j=1NWj\sum_{j=1}^{N} W_j
  3. 概率比值两者相除得到 0 到 1 之间的概率，所有权重之和的归一化保证所有概率加起来等于 1。
    Pi=Wi∑WjP_i = \frac{W_i}{\sum W_j}
  4. 应用举例两个节点权重 3:1，则第一个节点接到 75% 的请求，第二个接到 25%，既不空转也不压垮。
    P1=33+1=75%,P2=25%P_1 = \frac{3}{3+1} = 75\%, \quad P_2 = 25\%

容错与冗余

天有不测风云，重庆分中心的仓库半夜着了火。系统是怎么反应的？首先，故障检测发现异常——健康检查连续三次连不上，于是 GSLB 立刻把重庆从可用列表里摘掉；与此同时，Anycast 那边更直接：重庆机房到电信局的 BGP 路由被撤回，全网路由器发现“这个 400 号码重庆不认领了”，自动把原本去重庆的流量改道到成都和武汉。这就是 Anycast 最迷人的地方——网络层自愈，不需要用户重新解析域名，不需要应用层改配置。

但自愈不是瞬时的。BGP 撤销消息在全世界路由器间传播需要时间（秒级到分钟级），这段窗口里仍可能有人把包发往“已经着火的仓库”。所以真正的生产环境要做多级冗余设计：机房内多台机器互备，城市间异地多活，运营商出口多条链路，层层兜底。冗余的收益可以用并联可用性公式算出来：

小云速递的老板听完汇报后睡了个安稳觉——任何单点都会失效，但设计得当的冗余网络可以永不下线。

Atotal=1−∏i=1N(1−Ai)\displaystyle A_{total} = 1 - \prod_{i=1}^{N} (1 - A_i)
单个节点可用性 99%，三个互相备份后整体可用性 ≈ 99.9999%，相当于一年停机时间从 3.65 天缩短到约 30 秒。
  1. 故障概率 \(1 - A_i\)每个节点“挂掉”的概率；可用性 99% 意味着 1% 的时间可能不可用。
    1−Ai1 - A_i
  2. 连乘求“全挂”概率N 个节点同时故障的概率等于各自故障概率相乘，因为冗余要求所有副本都失效才整体失效。
    ∏i=1N(1−Ai)\prod_{i=1}^{N} (1 - A_i)
  3. 整体可用性用 1 减去“全挂”概率，得到至少有一个节点存活工作的概率。
    Atotal=1−∏i=1N(1−Ai)A_{total} = 1 - \prod_{i=1}^{N} (1 - A_i)
  4. 数值直觉三个 99% 节点并联，\(1 - (0.01)^3 = 0.999999\)，可用性提升了整整四个九。
    1−(0.01)3=0.9999991 - (0.01)^3 = 0.999999

CDN与边缘演进

小云速递最初就是个“转运公司”：客户要货，分中心回总仓取货再送。后来老板发现，很多货（比如《庆余年2》的会员海报）全国重复要，不如直接在分中心仓库备上几箱——这就是 CDN 的缓存机制，客户一来直接拿走，不用回源。缓存省了多少功夫，用命中率衡量：

再往后，老板发现光“备货”还不够，有些客户要“现场加工”——比如直播流的转码、云游戏的画面渲染。于是分中心里不再只有货架，还多了小加工台，这就是边缘计算融合。从此 CDN 的定位从“缓存仓库”升级为“迷你机房”：云边协同调度下，中心云负责“编排与训练”这种重活，边缘节点负责“就近执行”这种急活，算力不断下沉，离用户越来越近。

小云速递的故事也迎来高光时刻：分中心既是仓库，又是加工厂，还是客服中心。CDN 现代化的本质，就是把原本囤在总仓的算力，像便利店一样开进每个社区。

H=NhitNhit+Nmiss\displaystyle H = \frac{N_{hit}}{N_{hit} + N_{miss}}
命中率 = 直接从分中心拿到货的次数 ÷ 总请求次数。命中率越高，回源越少，用户越快。
  1. 命中次数 \(N_{hit}\)请求在边缘节点本地命中了缓存，直接返回，最省时间。
    NhitN_{hit}
  2. 未命中次数 \(N_{miss}\)本地没货，不得不回源站取，耗时变长。
    NmissN_{miss}
  3. 命中率比值命中次数占总请求的比例，行业里做到 90% 以上就是优等生。
    H=NhitNhit+NmissH = \frac{N_{hit}}{N_{hit} + N_{miss}}

运维监控实践

分中心多了，老板当然不能靠感觉管理，他要看一张全国大屏。全球质量拨测是最重要的手段——派出几千个“假客户”（探针）在全球各地周期性拨打总机、下载测试文件，测出每个地区到每个分中心的真实 RTT 和丢包率，数据实时汇入监控系统。核心指标监控则盯着每个节点的四件事：RTT 延迟、缓存命中率、回源带宽、错误率，任何一项飙红都触发告警。

光看还不够，还得“预知未来”。容量规划的思路是：拉出过去一年的流量曲线，找出双十一峰值，乘以 1.5 冗余系数，反推每个分中心要备多少带宽和算力——就像超市提前两个月准备年货。最后是调度参数调优：某分中心频繁过载，就把它的权重调小、健康检查阈值放宽；某区域延迟波动剧烈，就调节度公式里的 \(\alpha\) 权重。调优依赖平滑可靠的指标，常用 EWMA（指数加权移动平均）对 RTT 做平滑：

有了这套大屏和公式，小云速递终于从“拍脑袋经营”进化为“数据驱动经营”。运维的本质不是等故障来了再救火，而是用拨测和监控让故障根本来不及发生。

RTTˉt=β×RTTˉt−1+(1−β)×RTTt\displaystyle \bar{RTT}_t = \beta \times \bar{RTT}_{t-1} + (1 - \beta) \times RTT_t
今天的“平滑延迟” = 昨天的平滑延迟和今天的实时采样各取一部分加权。既跟手，又不被单次抖动带偏。
  1. 历史平滑值 \(\bar{RTT}_{t-1}\)上一时刻算出的延迟均值，代表这阵子的整体水平。
    RTTˉt−1\bar{RTT}_{t-1}
  2. 当前采样值 \(RTT_t\)这一次拨测得到的原始 RTT，可能因为瞬时抖动而忽高忽低。
    RTTtRTT_t
  3. 平滑系数 \(\beta\)取值 0 到 1 之间，\(\beta\) 越大越“念旧”，曲线越平缓；越小越“喜新”，对变化越敏感。
    β∈[0,1]\beta \in [0, 1]
  4. 递推更新每次用新旧 9:1（\(\beta=0.9\)）或 7:3 混合，滚动更新均值，既过滤毛刺又跟随趋势。
    RTTˉt=0.9×RTTˉt−1+0.1×RTTt\bar{RTT}_t = 0.9 \times \bar{RTT}_{t-1} + 0.1 \times RTT_t

AI 应用场景

全球视频直播加速

阶段：流量接入与节点调度

解决的问题：传统直播把流量全部回源到中心机房，跨国用户延迟动辄 300ms 以上，卡顿严重；AI 结合 Anycast 就近接入后，用户请求自动进入最近的边缘节点，节点通过智能调度算法预测各区域带宽需求，提前预置热门视频流。

具体案例：某头部直播平台在东南亚扩张时，利用 Anycast IP 让新加坡、雅加达、马尼拉的用户自动接入最近节点，再配合基于用户观看时长的智能预缓存策略，将首屏加载时间从 4.2 秒降到 0.9 秒，卡顿率下降 70%。

云游戏与实时互动

阶段：边缘节点计算调度

解决的问题：云游戏要求端到端延迟低于 50ms，中心云算得再快也扛不住物理距离；通过边缘节点下沉 GPU 算力，结合 Anycast 将玩家接入最近的算力节点，并用量化模型实时调整分辨率与码率。

具体案例：某云游戏服务商在全国 30 个城市部署边缘 GPU 节点，玩家在成都接入成都节点而非北京中心云，操作延迟从 85ms 降至 28ms；系统还会根据 RTT 波动动态切换节点，保障画面不掉帧。

电商大促全球流量洪峰

阶段：全局负载均衡与容灾

解决的问题：大促期间某区域流量暴涨会导致节点过载、甚至雪崩；利用 GSLB 动态权重 + Anycast 网络层分流，把过载节点的流量按比例转给邻近节点，同时健康检查自动摘除异常节点。

具体案例：跨境电商“黑五”期间，某云厂商欧洲节点流量达到日常 12 倍，系统通过动态权重调整将 35% 流量转至法兰克福与伦敦节点，全程零故障；同时用拨测数据预测下一时段流量，提前扩容。

Python 演示

python55 行
# -*- coding: utf-8 -*-"""Anycast 边缘节点调度模拟器. 用快递分中心的思路模拟: 用户请求到达调度器,调度器根据 RTT(线路距离)与负载(繁忙程度)打分,选择得分最高的边缘节点承接请求."""  class EdgeNode:    def __init__(self, node_id, rtt_ms, capacity):        self.node_id = node_id        self.rtt_ms = rtt_ms        self.capacity = capacity        self.request_count = 0     def score(self, alpha=0.6, beta=0.4):        # 延迟越低得分越高, 负载越低得分越高        latency_score = 100.0 / self.rtt_ms        load_ratio = self.request_count / float(self.capacity)        return alpha * latency_score + beta * (1.0 - load_ratio)     def assign(self):        self.request_count += 1  class AnycastSimulator:    def __init__(self, nodes):        self.nodes = nodes     def choose(self):        return max(self.nodes, key=lambda n: n.score())     def run(self, total_requests):        for _ in range(total_requests):            node = self.choose()            node.assign()        return {n.node_id: n.request_count for n in self.nodes}  def main():    nodes = [        EdgeNode(1, 20, 500),   # 离用户近        EdgeNode(2, 45, 800),   # 中等距离        EdgeNode(3, 80, 1000),  # 远但容量大        EdgeNode(4, 120, 600),  # 最远    ]    sim = AnycastSimulator(nodes)    stats = sim.run(1000)    for nid, cnt in sorted(stats.items()):        print("节点%s: %d 请求" % (nid, cnt))  if __name__ == "__main__":    main()
目的：用加权打分模拟 Anycast 的请求就近分配，运行后能直观看到“近 + 闲”的节点吃下大部分请求，而远且忙的节点只分到少量流量。
  1. def score(self, alpha=0.6, beta=0.4):定义边缘节点的打分规则，延迟占 60% 权重、空闲度占 40%
  2. latency_score = 100.0 / self.rtt_ms延迟越低分数越高，20ms 的节点能拿到 5.0 分
  3. load_ratio = self.request_count / float(self.capacity)把已接单量换算成 0~1 的负载率
  4. return alpha * latency_score + beta * (1.0 - load_ratio)最终得分 = 距离分 + 空闲分
  5. return max(self.nodes, key=lambda n: n.score())每次都选“当前得分最高”的分中心接单
  6. node.assign()给选中的节点记上一单，模拟请求落点
  7. EdgeNode(1, 20, 500)节点 1 离用户 20ms、最多同时处理 500 单

常见误区

误区Anycast 跟 DNS 轮询差不多嘛，不就是把一个域名解析出好几个 IP，客户端随机挑一个用？我用 nginx 也能实现类似效果。

正解两者根本不在一个层面。DNS 轮询是应用层调度，客户端拿到 IP 列表后自己选，选完就固定了；Anycast 是网络层调度，多个节点共享同一个 IP，由沿途路由器根据 BGP 路径自动选路，客户端全程无感知。就像“接线员按名单轮流指派”和“总机号码本身每个城市都有登记”的区别——前者靠人分配，后者靠电话网络自动转接。

为何常见：普通开发者日常接触最多的是 DNS，容易把所有“调度”都理解成域名解析那一套。

误区用户在上海，那肯定接入上海机房的节点最快，选机房就看离用户直线距离近不近就行。

正解互联网的“近”是网络拓扑的近，不是地图上的近。跨海光缆、运营商互联瓶颈、中间路由器拥塞都可能让“直线近”的线路实际很慢。调度系统用 RTT、AS 路径长度、丢包率等实测数据打分，而不是查经纬度。就像打车不能看直线距离，得看真实路网有没有堵车。

为何常见：人类对“近”的本能直觉来自地理空间，但互联网是层层嵌套的抽象拓扑，直觉在这里失效。

误区既然 Anycast 在网络层自动就近，那还要 GSLB 干什么？直接把所有节点配成同一个 IP 不就天下太平了？

正解实际生产中是两层配合：GSLB 在 DNS 层按地区、运营商、业务策略把用户引导到某个边缘集群（大颗粒度），Anycast 在 IP 层把数据包引导到集群内最近的节点（小颗粒度）。GSLB 能感知应用层策略（比如某地区用户必须走合规节点），Anycast 做不到这么细。两者不是替代关系，而是“先分大区、再就近入网”的协作关系。

为何常见：学到一个新机制时容易“万物皆可它”，忽略了真实系统的分层设计。

误区多建节点总没错，每个城市都放一个机房，用户肯定都满意，钱不是问题。

正解节点增加会带来三重代价：建造成本直线上升；全球 BGP 路由表条目膨胀，路由器内存和收敛时间变差；任意一个节点的路由抖动都会影响到整个 Anycast 前缀的稳定性。所以要用覆盖半径模型做网格化规划，追求“该密的地方密、该省的地方省”。

为何常见：“店多客方便”是零售直觉，但网络世界每个节点都会向全网广播路由，单点的问题会被放大成全局问题。

误区节点宕机后 BGP 会自动撤销路由，流量自动切换，运维可以放心睡觉了。

正解BGP 收敛是“最终一致”而不是“瞬间一致”，撤销路由传遍全网需要数秒到数分钟，窗口期内流量仍会涌向故障节点。生产环境必须叠加主动健康检查、GSLB 权重摘除、BFD 快速探测等机制，把收敛时间从分钟级压到秒级甚至毫秒级。

为何常见：“自动”二字让人误以为系统瞬间完成切换，忽视了分布式系统中“传播需要时间”这个铁律。

面试题

Q1. Anycast 的核心思想是什么？

单选题 · easy

  • A.多个 IP 轮流解析到一个服务器
  • B.多个节点共享 IP 由路由就近选择← 正确答案
  • C.一台服务器挂多个 IP 对外提供服务
  • D.用 DNS 把用户分到不同的可用区

答案：B。Anycast 的奥妙在于“同一个 IP 在世界多地同时存在”，路由器按 BGP 路径把用户送到最近的那个，就像总机号码每个城市都登记了。A 描述的是 DNS 轮询，C 是单机多 IP，D 是 GSLB 域名调度。

Q2. Anycast 网络层就近重定向发生在哪个环节？

单选题 · easy

  • A.应用层发起 HTTP 重定向时
  • B.用户端浏览器解析域名时
  • C.中间路由器转发数据包时← 正确答案
  • D.源站服务器处理请求时

答案：C。Anycast 的“就近选择”由沿途路由器完成——它在转发数据包时根据 BGP 路由表选择最优下一跳。用户和 DNS 全程无感知，不需要应用层参与，也不需要浏览器做任何特殊处理。

Q3. CDN 场景中 GSLB 与 Anycast 的协作关系是？

单选题 · mid

  • A.两者功能重复只需选一个
  • B.GSLB 先定集群 Anycast 再入集群← 正确答案
  • C.Anycast 负责 DNS 解析调度域名
  • D.GSLB 负责 TCP 传输层加速

答案：B。GSLB 通过 DNS 返回最合适的边缘集群 IP（大粒度、可按地区策略），这个 IP 是 Anycast 共享地址，数据包再由路由器转发到集群内最近的节点。两者是“先分大区、再就近接入”的两层协作。

Q4. 加权轮询调度中两个节点权重 3:1，预期请求比例是？

单选题 · mid

  • A.随机分配无固定比例
  • B.3:1 近似按权重比例分配← 正确答案
  • C.1:3 与权重成反比分配
  • D.每次都选权重较小的节点

答案：B。\(P_i = W_i / \sum W_j\)，权重 3 的节点概率 = 3/(3+1) = 75%，权重 1 的节点 = 25%，比例正好 3:1。A 忽视了权重的确定性，C 把方向弄反，D 完全背离权重语义。

Q5. 就近接入公式 \(S=0.6\times\frac{100}{RTT}+0.4\times(1-\text{负载})\) 中，RTT 与负载对得分的影响是？

单选题 · mid

  • A.两者都是越大得分越高
  • B.RTT 越小得分高，负载越小得分高← 正确答案
  • C.RTT 越大得分高，负载越大得分高
  • D.两者对得分基本没有影响

答案：B。\(\frac{100}{RTT}\) 随 RTT 增大而缩小，\((1-\text{负载})\) 随负载增大而缩小，所以 RTT 越小、负载越低，得分越高。这正体现了“近 + 闲”双目标调度，缺一不可。

Q6. 单节点可用性 99%，三个独立节点并联后的整体可用性约为？

单选题 · hard

  • A.约 99% 几乎无提升
  • B.约 97% 反而下降
  • C.约 99.99% 提升不多
  • D.约 99.9999% 提升明显← 正确答案

答案：D。并联冗余公式 \(A=1-(1-0.99)^3=1-10^{-6}=99.9999\%\)。A 忽略了冗余收益，B 是错误减法，C 是两副本才有的量级。三个 99% 的节点互相备份后，一年停机时间从 3.65 天缩短到约 30 秒。

Q7. BGP 路由收敛期间，Anycast 故障节点会发生什么？

单选题 · hard

  • A.流量立即全部切走无感知
  • B.路由撤销前仍可能吸入流量← 正确答案
  • C.该节点自动重启并恢复服务
  • D.DNS 必须手动刷新才能切换

答案：B。BGP 撤销路由需要传播到全网，收敛窗口内路由器仍会把包发给已宕机节点，造成短暂丢包。因此生产环境要靠健康检查提前摘流量、用 BFD 加速探测，而不是只依赖 BGP 自愈。

Q8. 边缘节点选址时需要考虑哪些因素？

多选题 · mid

  • A.目标用户的地理分布密度← 正确答案
  • B.与主流运营商的互联质量← 正确答案
  • C.机房租金电力等成本← 正确答案
  • D.网站首页配色的美观度

答案：ABC。选址三要素是用户密度、网络拓扑质量与成本，对应打分公式里的 \(U_i, N_i, C_i\)。D 是无意义干扰项——机房运维与网页配色无关，这也说明选址要用评分卡而不是拍脑袋。

Q9. 流量就近接入的常用优化手段包括？

多选题 · mid

  • A.基于实时 RTT 打分选择路径← 正确答案
  • B.同源会话保持节点不漂移← 正确答案
  • C.智能回源算法优化取货路径← 正确答案
  • D.无脑增加节点数量即可

答案：ABC。就近接入 = 延迟感知选路 + 会话保持 + 回源优化三件事，分别解决“选得准、不断线、回源快”。D 是典型误区：节点增长会带来路由表膨胀与成本上升，不是无脑加。

Q10. 三节点 RTT 分别为 20/40/60ms，负载分别为 80%/20%/10%，用 \(S=0.6\times\frac{100}{RTT}+0.4\times(1-\text{负载})\) 计算，以下哪些判断正确？

多选题 · extreme

  • A.A 节点得分约 3.08 为最高← 正确答案
  • B.B 节点得分约 1.82 仅次于 A← 正确答案
  • C.C 节点因负载最低应被优先选择
  • D.若 C 的 RTT 降为 30ms 则得分升至约 2.36← 正确答案

答案：ABD。A 得分 \(0.6\times5+0.4\times0.2=3.08\)，B 得分 \(0.6\times2.5+0.4\times0.8=1.82\)，C 原得分 \(0.6\times1.667+0.4\times0.9=1.36\)，C 虽然最闲但延迟太大、综合得分最低，故 C 错；若 C 的 RTT 降到 30ms，得分 \(0.6\times3.333+0.4\times0.9=2.36\)，D 对。