住宅代理故障转移：构建可靠的多区域数据管道

有两个可靠性关切，团队常常把它们混为一谈，而它们之间有一条清晰的界线。重试处理的是一个坏请求，一次调用失败了，再试一次。**故障转移（failover）**处理的是一个坏依赖，一整个组件停止工作了，绕开它。负载均衡与重试架构那篇讲的是前者：工作如何映射到身份，以及一层重试如何对单个失败分类并恢复。这一篇讲的是后者，而它是一个不同的问题：当一层重试帮不上忙——因为你要重试去打的那个东西自己就宕了——你的管道会怎么办。

对一支在跨市场的规模上运行采集的数据工程团队而言，这就是”一个在事故期间优雅降级的管道”和”一个悄无声息地产出一整天缺失或错误数据的管道”之间的区别。在一个住宅代理 gateway 上，你并不管理 IP，所以你的故障转移，不是关于替换地址，而是关于为单个请求之上那些层级的失败去做设计。

首先，把故障域命名出来

不先把究竟什么会失败列举出来，你就没法构建故障转移。一条代理支撑的管道会在六个不同的层级上失败，而只有头两个已经替你处理好了：

错误在于假定重试覆盖的比第一行更多。对着一个正在把你整套流量模式封成潮水的目标去更狠地重试，恢复不了，只会升级。对着一个正在闹事故的 gateway 去重试，只是在烧时间。故障转移，是为第三到第六行所做的设计。

你真正能掌控的那些可靠性原语

因为 IP 管理住在 gateway 里，你的故障转移工具箱，就是一小组以正确粒度施加的原语：

健康信号，按故障域。 不只在全局、而是按目标、按地理、按供应商地追踪成功率、延迟和封锁率。一个 95% 的聚合成功率，可能藏着一个坐在 20% 的市场。你只能对你看得见在失败的东西做故障转移，而测量方法见如何测试代理的速度、成功率与位置准确度。

熔断器，按故障域。 负载均衡那篇引入了一个按主机的熔断器。故障转移把它一般化：一个按目标、按地理、按供应商的熔断器。当某个域的健康崩掉时，别再猛击它，跳闸到一个后备，而不是去磨一个已经在拒绝你的依赖。

一条次要路径。 没有一个可以转移过去的地方，故障转移就毫无意义，一个后备地理、一个后备供应商，或一个明确的降级模式。如果对失败的唯一回应是”重试同一件事”，那你没有故障转移，你有的是一个忙循环。

持久化队列。 一次宕机期间在途的工作，必须能挺过它。如果一次事故意味着工作条目丢失，那你的故障转移是通过隐藏这份损失，把事情弄得更糟了。

多区域拓扑：把失败圈住，而不是散播出去

核心的结构性思想是：每个市场都是它自己的故障域，而拓扑应当让它保持如此。 一波针对你德国流量的封锁潮，不应该拖住你的美国采集。

那意味着：

• 按市场对 worker 分区。 每个地理一套独立的 worker 池（或至少独立的队列和限流器），这样一个区域的降级，就无法吃掉另一个区域的容量。这就是负载均衡那篇里”按主机隔离”的原则，往上抬一层、应用到区域。
• 区域范围的熔断器与并发。 每个市场拿到它自己的熔断器和它自己的并发预算。当 de 跳闸时，us 和 gb 原封不动地继续跑。
• 不要全局耦合。 一个跨区域共享的限流器、或一个跨区域共享的重试预算，会把彼此独立的故障域耦合在一起，正是要避免的反模式。一个市场的事故，对其余市场应当是不可见的。

回报是：局部失败保持局部。你得到的不是”管道宕了”，而是”德国采集正在降级并做故障转移，而其余一切照跑”,这是一个可运维的状态，而不是凌晨三点的一通告警。

供应商级的故障转移，说实话

这里有一个严肃的可靠性评审会问的、不舒服的问题：万一 gateway 本身闹了事故呢？认证开始失败、端点触达不到、质量在全网范围崩塌。再多的地理隔离也帮不上，因为每个区域都经由同一个供应商路由。

诚实的答案有两部分。

大多数团队不需要多供应商故障转移，也不应该过早加上它。 第二个供应商会让你的集成面、你的账务、以及你的一致性问题都翻倍（地理与会话语义在供应商之间有差异，所以一个转移过去的请求，行为可能微妙地不同）。对绝大多数管道而言，一个优质的住宅代理供应商，加上扎实的内部故障转移——基于健康的熔断器、降级模式、持久化队列——就覆盖了真实的风险。为了防一个罕见的供应商事故而加上第二个供应商、同时引入日常的复杂度，往往是一笔坏买卖。

当你的可靠性目标确实证明它有必要时，比如带着硬性新鲜度 SLA 的高价值管道，那就把它做对：把供应商抽象到一个薄接口之后，好让故障转移是一次配置改动，而不是一次重写：

class ProxyProvider:
    def proxy_url(self, geo: str, session: str | None) -> str: ...
    def healthy(self) -> bool: ...

class Gateway:
    def __init__(self, primary: ProxyProvider, secondary: ProxyProvider | None = None):
        self.primary, self.secondary = primary, secondary

    def resolve(self, geo, session=None):
        # 优先主供应商；仅当其熔断器打开时才做故障转移。
        if self.secondary and not self.primary.healthy():
            return self.secondary.proxy_url(geo, session)
        return self.primary.proxy_url(geo, session)

重点不在代码，而在形态：一个供应商就是一个接口之后的、可替换的依赖，由健康门控，后备一直休眠，直到主供应商的熔断器打开。哪怕你今天只跑一个供应商，按这个接口来构建也花不了多少，而这意味着日后加一个次供应商，是一次配置改动、而非一次管道重写。别在需要之前就买第二个供应商；但要把门留开着。

优雅降级：错但诚实，胜过缺失

当你确实无法采集到新鲜数据时，故障转移到什么都没有，很少是最好的选择。有意地降级：

• 提供”最后已知的好值”，并标记为陈旧。 对许多用例来说，昨天的价格、标上 stale: true，比一个缺口更有用，只要下游知道它是陈旧的。永远不要把陈旧数据悄悄当作当前数据递出去，那是一次数据质量失败（而且如果这数据要驱动关于人的决策，那也是一次准确性失败）。
• 向优先级卸载。 如果在一次局部宕机期间容量受限，就采集高价值的目标、把长尾往后推，而不是让一切都均等地失败。
• 放宽窗口。 临时放松新鲜度要求，而不是丢掉覆盖，一份稍旧一点的完整数据集，往往胜过一份新鲜但残缺的。

降级是一个一等的模式，不是一个意外。事先就为每个数据集决定好”降级”意味着什么，并把它做成一个明确、可观测的状态。

持久性与背压

只有当在途工作能挺过失败时，故障转移才成立。两条规则：

什么都不丢。 工作条目活在一个持久化队列里；一个失败的条目，进入一个重试队列或死信队列，它会在依赖恢复时排空，而不是进入虚空。当 de 做故障转移时，它待处理的工作停到一边，一旦熔断器闭合就重放。

重放是安全的。 让工作条目幂等，这样在恢复之后重跑一个，就不会重复计数或损坏数据。这就是负载均衡那篇所依赖的同一种幂等性，也正是它让故障转移的恢复变得干净，而不是一场对账噩梦。

测试你的故障转移，否则它并不存在

一条在真实事故中才第一次被触发的故障转移路径，不是一条故障转移路径，它是一份怀着善意的负债。在 staging 里有意地注入失败：

• 把某个区域的供应商指向一个死端点，确认它的熔断器跳闸、它做了故障转移、而其他区域原封不动。
• 模拟一个目标返回封锁，确认按目标的熔断器打开、降级模式启用。
• 在运行中途杀掉一个 worker 或队列，确认恢复后没有工作丢失。

如果你从没看过你的管道失去一个依赖却还能站稳脚跟，那你并不知道它会站稳。

为失败、而不只是为健康而建的可观测性

只显示聚合吞吐量的仪表盘，会在一个市场悄无声息地死去时依然一片绿。为故障域埋点：

• 把新鲜度纳入的 SLO，而不只是成功率，数据延迟（lag）才是那个能抓住一个悄悄停摆区域的指标。
• 按域的健康告警，按目标、按地理、按供应商，好让一个正在失败的单一市场在它变成一整天缺失数据之前就把你告警出来。
• 把故障转移事件当作一等遥测，当一个熔断器跳闸、或一个区域降级时，那是一个要记录、告警并复盘的事件，而不是一个沉默的内部状态。

常见问题

重试和故障转移有什么区别？ 重试是对着同一个依赖，重新尝试一个失败的单个请求。故障转移是绕开一个自己已经失败的依赖，一个在封锁潮里的目标、一个降级的地理、一个供应商事故。重试修不了一个坏掉的依赖；故障转移，是为”你要重试去打的那个东西宕了”所做的设计。

做故障转移我需要第二个代理供应商吗？ 通常不需要。一个优质供应商，加上内部故障转移——基于健康的熔断器、降级模式、持久化队列——就覆盖了大部分风险，而第二个供应商会带来真实的成本和一致性复杂度。只有当一个硬性的可靠性/新鲜度 SLA 证明它有必要时才加多供应商，而且如果要加，就把供应商抽象到一个接口之后，好让它是一次配置改动。

我怎么防止一个市场的失败拖垮整条管道？ 把每个市场当作它自己的故障域：按地理分开的 worker 池、队列、并发预算和熔断器，不用任何全局限流器或共享预算把它们耦合起来。这样一个国家的一波封锁潮，就只降级那个国家并做故障转移，而其余照常运行。

当我无法采集到新鲜数据时，应该发生什么？ 有意地降级，而不是悄无声息地失败：提供标记为陈旧的”最后已知好值”、向优先级目标卸载，或放宽新鲜度窗口。事先按数据集决定好”降级”意味着什么，并把它做成一个可观测的状态，永远不要把陈旧数据当作当前数据递出去。

我怎么知道我的故障转移真的有效？ 测它。在 staging 里注入供应商、目标和基础设施的失败，确认熔断器跳闸、后备启用、其他域仍然站着、且没有工作丢失。一条只在真实事故中才跑过的故障转移路径，应当被假定为是坏的。

底线

重试和故障转移解决的是不同的问题，而把它们混为一谈，正是那些看起来很稳健的管道会在真实事故中倒下的原因。重试恢复的是单个请求；故障转移，是为”一整个故障域——一个目标、一个市场、一个供应商，或你自己的基础设施——宕掉”所做的架构。构建它的办法是：把这些域命名出来、隔离每个市场好让失败保持圈住、把依赖门控在基于健康的熔断器之后、有意地降级而不是悄悄失败、让在途工作持久且幂等，以及最重要的，在一次事故替你测试这些失败路径之前，先自己测试它们。

在供应商这个问题上，忍住加第二个的冲动、直到一个真实的 SLA 要求它，并按一个薄薄的供应商接口来构建，好让这个选项一直很便宜。一个具备一致地理与会话行为的优质住宅代理网络，才是让那些常见的失败模式——封锁潮和地理降级——一开始就可恢复的关键；而池的质量（IP 信誉）决定了你到底会多频繁地触发这些路径。定价页面有按 GB 计费的套餐，可以拿它对着你自己的多区域工作负载来构建和测试。