背景与问题

在分布式系统里，请求该落到哪台机器，看起来只是一个“路由”问题，但一旦服务实例频繁扩缩容、节点偶发故障、缓存又强依赖命中率时，事情就没那么简单了。

很多团队最开始会用这几种方式做流量分发：

• DNS 轮询
• 负载均衡器 Round Robin
• 简单取模：hash(key) % N

这些方式在系统规模小时都能工作，但当架构进入多实例、动态伸缩、灰度发布阶段后，问题会越来越明显：

1. 节点变化导致大规模请求重映射

   • 例如原来 8 台机器扩到 10 台，简单取模会让大量 key 的映射关系失效。
   • 如果后端挂的是本地缓存、会话、热点数据分片，抖动会非常大。

2. 服务发现与路由决策脱节

   • 注册中心知道谁存活，但调用方路由策略可能还在用旧节点列表。
   • 结果就是“注册中心显示健康，客户端还在打已经下线的实例”。

3. 负载看似均衡，实际热点严重倾斜

   • 某些 key 天生是热点，比如大客户租户、热门商品、超高频用户。
   • 如果没有虚拟节点、权重和故障转移策略，热点实例很容易被打爆。

4. 节点抖动引发级联问题

   • 一个实例被摘除，哈希环重建，请求重新分配，邻近节点瞬间承压。
   • 如果没有限流和缓冲，系统会出现“越修越崩”的连锁反应。

我当时做一套 API 网关到后端 Worker 的路由优化时，最痛的一个坑就是：服务发现已经改成秒级推送了，但客户端仍然按老的节点快照做哈希，导致一边注册中心很健康，一边请求错误率上升。
这类问题本质上不是单点算法问题，而是一致性哈希 + 服务发现 + 客户端缓存更新机制的组合问题。

方案概览：为什么是一致性哈希 + 服务发现

先说结论：

• 服务发现负责告诉你：当前有哪些可用节点、节点状态是什么、权重如何变化。
• 一致性哈希负责在节点集合变化时，尽量减少 key 到实例的迁移量。
• 客户端本地路由缓存负责保证每次请求的路由决策足够快。
• 健康检查、熔断、重试负责让异常节点不会拖垮整个流量面。

它们组合起来，才能真正把“流量路由优化”做完整。

一个典型架构

flowchart LR
    A[客户端请求] --> B[路由层/SDK]
    B --> C[本地节点缓存]
    C --> D[一致性哈希环]
    E[注册中心] -->|变更推送/拉取| C
    D --> F[目标实例A]
    D --> G[目标实例B]
    D --> H[目标实例C]
    F --> I[健康上报]
    G --> I
    H --> I
    I --> E

这个结构里最关键的点有两个：

1. 哈希环不是静态配置，而是由服务发现驱动动态构建
2. 路由决策在客户端本地完成，避免每次请求都查中心组件

核心原理

1. 一致性哈希解决了什么问题

传统取模：

node = hash(key) % N

问题在于，N 一变，几乎所有 key 的结果都会变。

一致性哈希则把节点和 key 都映射到一个逻辑环上：

• 对每个节点求 hash，放到环上
• 对每个请求 key 求 hash，也放到环上
• 顺时针找到第一个节点，就是目标实例

这样当新增或删除节点时，只会影响该节点附近的一小段 key，而不是全量重算。

flowchart TD
    K1[key1] --> H1[hash(key1)]
    K2[key2] --> H2[hash(key2)]
    N1[node-A]
    N2[node-B]
    N3[node-C]
    H1 --> N2
    H2 --> N3

2. 为什么必须引入虚拟节点

如果环上只有真实节点，分布往往不均匀。尤其节点数量少时，很容易出现某个节点负责大段区间。

解决方法是给每个物理节点创建多个虚拟节点：

• node-A#0
• node-A#1
• node-A#2
• …

这样可以把节点更均匀地打散到环上，减轻倾斜。

经验上：

• 小规模集群：每节点 50~100 个虚拟节点可作为起点
• 更关注均匀性：100~300 个
• 节点数很多时，虚拟节点数量不宜无脑拉高，否则本地构环成本会上升

3. 服务发现不是“拿个列表”这么简单

服务发现通常至少需要提供：

• 实例列表
• 实例状态：UP / DOWN / DRAINING
• 元数据：机房、权重、版本
• 变更通知机制：推送或轮询
• 租约/心跳机制

在路由层，常见做法是：

1. 从注册中心拿到健康实例列表
2. 过滤掉不应接流量的节点
3. 按权重生成虚拟节点
4. 构建新的哈希环
5. 原子替换本地路由表

重点在第 5 步：不要边更新边读。否则请求线程可能读到一半构建中的环。

4. 路由一致性与可用性的平衡

一致性哈希通常适用于：

• 缓存路由
• 会话粘性
• 分片请求
• 热点 key 稳定命中

但它并不意味着“绝不重试”或“绝对固定”：

• 如果目标实例不可用，需要沿环顺时针找下一个健康节点
• 如果业务必须强粘性，需要结合副本策略或回源策略
• 如果某个 key 超热点，可能还要做热点拆分，而不是只靠哈希

方案对比与取舍分析

在设计路由层前，最好先明确适用边界。

我的经验是：

• 纯无状态 API：不一定要上一致性哈希，普通负载均衡就够
• 依赖本地缓存/会话/热点分片：一致性哈希非常值得
• 节点变化频繁：服务发现必须和路由更新打通，否则收益会被抵消

实战代码（可运行）

下面用 Python 写一个可运行示例，模拟：

• 注册中心维护实例列表
• 客户端基于服务发现构建一致性哈希环
• 请求按 key 路由到目标实例
• 某实例下线后，观察映射变化

1. 核心实现

import hashlib
import bisect
import threading
from dataclasses import dataclass
from typing import List, Dict, Optional


def md5_hash(value: str) -> int:
    return int(hashlib.md5(value.encode("utf-8")).hexdigest(), 16)


@dataclass(frozen=True)
class ServiceInstance:
    instance_id: str
    host: str
    port: int
    weight: int = 1
    status: str = "UP"  # UP / DOWN / DRAINING

    @property
    def address(self) -> str:
        return f"{self.host}:{self.port}"


class ServiceRegistry:
    """
    一个极简注册中心示例：
    - register / deregister / update_status
    - get_instances
    """
    def __init__(self):
        self._lock = threading.Lock()
        self._instances: Dict[str, ServiceInstance] = {}

    def register(self, instance: ServiceInstance):
        with self._lock:
            self._instances[instance.instance_id] = instance

    def deregister(self, instance_id: str):
        with self._lock:
            self._instances.pop(instance_id, None)

    def update_status(self, instance_id: str, status: str):
        with self._lock:
            if instance_id in self._instances:
                old = self._instances[instance_id]
                self._instances[instance_id] = ServiceInstance(
                    instance_id=old.instance_id,
                    host=old.host,
                    port=old.port,
                    weight=old.weight,
                    status=status,
                )

    def get_instances(self) -> List[ServiceInstance]:
        with self._lock:
            return list(self._instances.values())


class ConsistentHashRing:
    def __init__(self, virtual_nodes: int = 100):
        self.virtual_nodes = virtual_nodes
        self._ring = []
        self._node_map = {}
        self._lock = threading.Lock()

    def rebuild(self, instances: List[ServiceInstance]):
        """
        只把 UP 状态实例放入哈希环。
        按 weight 扩展虚拟节点数量。
        """
        ring = []
        node_map = {}

        healthy_instances = [i for i in instances if i.status == "UP"]

        for inst in healthy_instances:
            replicas = self.virtual_nodes * max(1, inst.weight)
            for i in range(replicas):
                vnode_key = f"{inst.instance_id}#{i}"
                h = md5_hash(vnode_key)
                ring.append(h)
                node_map[h] = inst

        ring.sort()

        with self._lock:
            self._ring = ring
            self._node_map = node_map

    def get_node(self, key: str) -> Optional[ServiceInstance]:
        with self._lock:
            if not self._ring:
                return None
            h = md5_hash(key)
            idx = bisect.bisect(self._ring, h)
            if idx == len(self._ring):
                idx = 0
            return self._node_map[self._ring[idx]]

    def get_failover_node(self, key: str, excluded_instance_ids=None) -> Optional[ServiceInstance]:
        """
        顺时针寻找下一个未排除节点，模拟故障转移。
        """
        excluded_instance_ids = excluded_instance_ids or set()

        with self._lock:
            if not self._ring:
                return None

            h = md5_hash(key)
            idx = bisect.bisect(self._ring, h)

            visited = set()
            for offset in range(len(self._ring)):
                current_idx = (idx + offset) % len(self._ring)
                inst = self._node_map[self._ring[current_idx]]
                if inst.instance_id in visited:
                    continue
                visited.add(inst.instance_id)
                if inst.instance_id not in excluded_instance_ids:
                    return inst

            return None


class Router:
    def __init__(self, registry: ServiceRegistry, virtual_nodes: int = 100):
        self.registry = registry
        self.ring = ConsistentHashRing(virtual_nodes=virtual_nodes)

    def refresh(self):
        instances = self.registry.get_instances()
        self.ring.rebuild(instances)

    def route(self, key: str) -> Optional[ServiceInstance]:
        return self.ring.get_node(key)


def simulate():
    registry = ServiceRegistry()
    registry.register(ServiceInstance("node-a", "10.0.0.1", 8080, weight=1))
    registry.register(ServiceInstance("node-b", "10.0.0.2", 8080, weight=1))
    registry.register(ServiceInstance("node-c", "10.0.0.3", 8080, weight=1))

    router = Router(registry, virtual_nodes=100)
    router.refresh()

    keys = [f"user:{i}" for i in range(1, 21)]

    print("=== 初始路由 ===")
    before = {}
    for key in keys:
        node = router.route(key)
        before[key] = node.instance_id if node else None
        print(f"{key:10s} -> {before[key]}")

    print("\n=== node-b 下线后 ===")
    registry.update_status("node-b", "DOWN")
    router.refresh()

    moved = 0
    for key in keys:
        node = router.route(key)
        after = node.instance_id if node else None
        if before[key] != after:
            moved += 1
        print(f"{key:10s} -> {after}")

    print(f"\n发生迁移的 key 数量: {moved}/{len(keys)}")


if __name__ == "__main__":
    simulate()

2. 运行方式

python consistent_hash_router.py

你会看到两组路由结果：

• 初始情况下 key 分配到 node-a / node-b / node-c
• 当 node-b 下线后，只有部分 key 迁移到其他节点，而不是全部重排

这就是一致性哈希最核心的收益。

路由更新时序

真正线上系统里，注册中心、客户端缓存和请求线程之间的协作很重要。可以把时序理解成下面这样：

sequenceDiagram
    participant R as 注册中心
    participant C as 客户端路由器
    participant H as 一致性哈希环
    participant S as 服务实例

    R->>C: 推送最新实例列表
    C->>C: 过滤 DOWN / DRAINING
    C->>H: 基于健康实例重建哈希环
    H-->>C: 返回新环
    C->>C: 原子替换本地路由表
    C->>H: 按 key 查找目标节点
    H-->>C: 返回目标实例
    C->>S: 发起请求

线上实现时，建议注意两件事：

• 构建新环在临时对象完成
• 替换动作原子化

不要在共享结构上直接增删节点，否则并发请求下非常容易出现不可复现的路由异常。

容量估算：别只看算法，得看业务特征

很多人上来就问“一台机器配多少虚拟节点合适”，其实更应该先看业务。

需要估算的几个量

1. 总 QPS
2. 热点 key 占比
3. 单实例可承载峰值
4. 扩缩容频率
5. 节点故障时的瞬时转移比例

一个简化估算方法：

假设：

• 总 QPS = 20,000
• 5 个实例
• 理想均匀情况下，每实例 4,000 QPS
• 单实例安全上限 = 6,000 QPS

看起来很安全，对吧？
但如果有一个热点租户占 25% 流量，那么该 key 所在实例可能会吃到：

基础均摊流量 + 热点流量
≈ 4,000 + 5,000 = 9,000 QPS

这时即便哈希均匀，机器也照样爆。

所以一致性哈希优化的是整体映射稳定性，不是万能的热点治理方案。
遇到明显热点时，还要加：

• 热点 key 拆分
• 本地/多级缓存
• 单 key 限流
• 读写隔离
• 副本分流

常见坑与排查

这一部分我想写得更接地气一点，因为很多问题在白板上根本看不出来，只有线上才会露出来。

1. 节点列表顺序不一致，导致不同客户端构建出的环不同

现象：

• 同一个 key，在不同客户端被路由到不同实例
• 业务侧表现为缓存命中率异常、会话丢失、分片查询不稳定

原因：

• 客户端拿到的实例列表虽然内容相同，但顺序不同
• 某些实现里节点构建过程依赖输入顺序，导致结果不一致

排查方式：

• 打印每个客户端当前环摘要，比如节点数、前 10 个 vnode hash
• 对比服务发现返回的实例列表和构环输入列表
• 确认是否按固定字段排序，例如 instance_id

建议：

构环前统一排序，哪怕理论上 hash 后与顺序无关，也建议固定化输入，方便审计和排障。

2. 服务实例已经下线，但流量还在打过去

现象：

• 注册中心显示节点已 DOWN
• 但该实例日志里仍有请求进入
• 请求错误率升高，尤其是连接超时

原因可能有：

• 客户端本地缓存未及时刷新
• 推送丢失，轮询周期太长
• 连接池里还保留旧连接
• 节点状态从 UP 到 DOWN 没有“摘流”阶段

排查路径：

1. 看注册中心事件时间戳
2. 看客户端收到变更的时间
3. 看本地哈希环更新时间
4. 看连接池中是否仍存在旧目标地址

建议：

引入 DRAINING 状态：

• UP：可接收新流量
• DRAINING：不接新流量，但允许已有请求收尾
• DOWN：彻底移除

这比直接 DOWN 更平滑。

3. 虚拟节点过少，负载倾斜明显

现象：

• 明明 6 台机器，QPS 却是 1 台很高、2 台中等、其他很低
• 节点都健康，但 CPU 曲线明显不均

原因：

• 真实节点太少
• 虚拟节点数量不足
• hash 算法或 key 分布不够离散

排查方式：

• 统计每个实例承接的 key 数量或请求量
• 导出哈希环区间分布
• 对比 10、50、100、200 个虚拟节点的均匀性

建议：

• 从每节点 100 个虚拟节点开始压测
• 不要只看平均值，要看 P95/P99 节点负载差异
• 如果 key 天然偏斜，增加虚拟节点只能缓解，不能根治

4. 故障转移后引发雪崩

现象：

• 一台节点挂掉后，另外两台也陆续超时
• 最终像多米诺骨牌一样全线失败

原因：

• 故障节点负责的请求全部转移到少数邻近节点
• 下游没有限流和熔断
• 重试策略太激进，放大流量

建议：

• 重试次数控制在 1 次以内，且必须避开原节点
• 加入请求预算和并发上限
• 对热点 key 增加专门保护
• 节点摘除后短期内监控邻近节点负载

安全/性能最佳实践

路由系统常被认为只是“基础设施”，但它既关系性能，也关系安全边界。

性能方面

1. 本地缓存优先，避免每次请求访问注册中心

这是基本原则：

• 注册中心负责控制面
• 路由决策发生在数据面

如果每次请求都查注册中心，延迟和可用性都会出问题。

2. 用原子替换代替原地修改

推荐模式：

1. 拉取最新实例列表
2. 构建新的哈希环对象
3. 一次性替换旧对象引用

这样锁粒度小，对请求线程影响也更小。

3. 对环重建做节流

如果注册中心频繁抖动，例如 1 秒内多次变更：

• 不要每次都立刻全量重建
• 可以合并事件，在 100ms~500ms 窗口内批处理
• 但窗口不能太长，否则会影响故障摘除速度

4. 路由结果可做短期本地 memoization

对于热点 key，如果业务允许，可以做极短时间缓存，比如几十毫秒到几百毫秒，减少重复查环成本。
不过这要注意节点切换时的滞后问题。

安全方面

1. 不要信任注册中心返回的全部元数据

客户端应校验：

• 实例 ID 格式
• 地址是否合法
• 端口范围
• 权重是否越界

否则异常元数据可能把路由引向错误地址，甚至带来 SSRF 类风险。

2. 注册与发现链路要有鉴权

如果恶意实例可以伪造注册：

• 会被加入哈希环
• 流量可能被错误导向
• 造成数据泄露或中间人风险

至少要做到：

• 注册鉴权
• 心跳鉴权
• 注册中心访问控制
• 变更审计日志

3. 跨机房路由要显式约束

如果实例元数据里带有机房或可用区信息，优先同区路由。
否则一致性哈希虽然稳定，但可能把大量请求稳定地打到远端机房，延迟会持续偏高。

一个更完整的落地建议

如果你准备在实际项目里落地，我建议按下面顺序推进，而不是一步到位上复杂功能：

第一阶段：先把正确性做出来

• 服务发现拿到健康实例列表
• 客户端本地构建一致性哈希环
• 支持虚拟节点
• 节点下线后可重建路由表

这一步目标是：稳定映射 + 正确摘流

第二阶段：补齐可用性能力

• DRAINING 状态
• 故障转移到下一个健康节点
• 熔断、限流、超时和轻量重试
• 路由刷新失败时保留旧环

这一步目标是：节点异常时不把整个系统拖崩

第三阶段：针对业务优化

• 权重路由
• 同机房优先
• 热点 key 识别
• 多副本路由
• 灰度版本隔离

这一步目标是：把“能用”变成“好用”

总结

分布式架构中的流量路由，真正难的不是“选一个节点”，而是在节点不断变化的情况下，依然让请求尽量稳定、可控、可恢复。

把这篇文章压缩成几条最实用的建议，就是：

1. 有状态流量路由优先考虑一致性哈希

   • 特别适合缓存亲和、会话粘性、分片访问

2. 一致性哈希必须和服务发现联动

   • 只做静态哈希，不解决动态扩缩容问题

3. 务必使用虚拟节点，并通过压测确定数量

   • 不要拍脑袋定参数

4. 环更新要原子替换，避免并发读写问题

   • 这是很多线上诡异 bug 的根源

5. 把故障转移、摘流状态、限流熔断一起设计

   • 否则节点下线时很容易发生级联故障

6. 热点问题不要指望只靠哈希解决

   • 一致性哈希优化的是迁移量，不是热点治理万能药

如果你的系统特点是：

• 实例会动态变化
• 请求和 key 有绑定关系
• 缓存命中率或会话稳定性很重要

那么“一致性哈希 + 服务发现”基本就是一条值得认真投入的路线。
但如果业务完全无状态、后端没有本地性收益，那就别为了“看起来高级”而增加复杂度——这是我踩过坑之后特别想强调的一点。