背景与问题

在分布式系统里，缓存集群扩容看起来像一件“加几台机器就行”的小事，但真正做过的人都知道，麻烦通常不是出在“加机器”本身，而是出在加完之后，数据路由怎么变、流量怎么切、命中率怎么稳、故障怎么兜底。

很多团队早期会用最直接的分片方式：

shard = hash(key) % N

这种方式在节点数固定时很简单，但一旦从 N=4 扩到 N=5，几乎所有 key 的路由结果都会变化。结果就是：

• 大量缓存失效，命中率瞬间下跌
• 后端数据库被突发流量打穿
• 应用实例对新旧节点认知不一致，出现热点和抖动
• 缩容时更危险，容易把仍有价值的数据直接“遗忘”

我在实际项目里踩过一个很典型的坑：业务高峰前临时扩容缓存节点，结果没有做平滑迁移，命中率从 92% 直接掉到 48%，数据库 CPU 飙升，最后不是缓存扛住了流量，而是数据库先报警了。问题本质不在“缓存不够”，而在于扩缩容策略缺少一致性哈希和服务治理的配合。

所以，这篇文章不只讲一致性哈希本身，还会把它放到一个更真实的架构语境里：服务发现、节点健康检查、权重调度、灰度切流、故障摘除、容量估算。我们从“为什么会抖”一路讲到“怎么平滑扩缩容”。

方案对比与取舍分析

在进入原理之前，先把几种常见方案摆在桌面上，便于理解为什么一致性哈希是缓存场景中的主流选择。

1. 取模分片

公式：

hash(key) % N

优点：

• 实现简单
• 路由速度快
• 节点固定时性能稳定

缺点：

• 节点数变化时，大量 key 重映射
• 扩缩容几乎必然带来缓存雪崩风险
• 对服务治理能力要求高，否则切换过程很脆弱

2. 范围分片

比如按用户 ID 范围分桶：

• 0~999999 在节点 A
• 1000000~1999999 在节点 B

优点：

• 容易理解
• 便于做局部迁移

缺点：

• 数据倾斜明显
• 热点 key 容易集中
• 动态扩缩容需要人工拆分和迁移

3. 一致性哈希

将节点和 key 都映射到一个哈希环上，key 落到顺时针遇到的第一个节点。

优点：

• 节点增减时，只影响局部 key
• 更适合频繁扩缩容
• 配合虚拟节点可以缓解数据倾斜

缺点：

• 实现复杂度高于取模
• 节点视图不一致时，可能出现路由分裂
• 需要配合服务治理才能真正稳定落地

结论很直接：一致性哈希解决的是“少迁移”，服务治理解决的是“稳迁移”。这两者要一起上，才是工程上可用的方案。

核心原理

一致性哈希：先把“环”想明白

一致性哈希的核心思路是：

1. 把整个哈希空间组织成一个首尾相连的环
2. 将缓存节点通过哈希映射到环上的多个位置
3. 将 key 也哈希到环上
4. key 顺时针找到第一个节点，作为归属节点

这样做的最大价值在于：

• 新增节点：只会接管它前驱区间的一部分 key
• 移除节点：它负责的 key 只会转移给后继节点

也就是说，扩缩容不会导致全局 key 洗牌。

为什么要虚拟节点

如果每台物理节点只在环上放一个点，哈希分布可能很不均匀，造成：

• 有的节点负责大量 key
• 有的节点几乎没流量
• 某个节点故障时，后继节点瞬间接收太多请求

因此我们通常为每个物理节点创建多个虚拟节点。比如一台机器放 100~300 个虚拟节点。这样环上的点更密，负载更均衡。

服务治理为什么必须参与

光有一致性哈希，还不够应对真实生产环境。因为真实环境里存在这些变量：

• 节点可能短暂抖动，不该立刻摘除
• 应用实例可能还没感知到新节点
• 某些节点容量更大，应该承载更多 key
• 扩容时需要先少量引流，再全量切换
• 节点下线前要先排空，而不是直接消失

这时服务治理要解决的问题包括：

• 服务发现：所有客户端获取统一的节点列表
• 健康检查：避免把请求路由到不可用节点
• 权重控制：大节点多放虚拟点，小节点少放
• 灰度发布：扩容时先小流量验证
• 摘除与恢复：节点故障时快速剔除，恢复时平滑回归

架构设计：一致性哈希 + 服务治理

下面这张图可以帮助建立整体认知。

flowchart LR
    A[应用实例 A] --> D[服务发现/治理中心]
    B[应用实例 B] --> D
    C[应用实例 C] --> D

    D --> E[节点列表 + 权重 + 健康状态]
    E --> F[一致性哈希环构建器]

    F --> G[Cache Node 1]
    F --> H[Cache Node 2]
    F --> I[Cache Node 3]
    F --> J[Cache Node 4]

    K[业务请求 key] --> F

这里的关键点是：

• 哈希环不是手写死的，而是由服务治理中心下发的节点元数据动态生成
• 客户端本地持有一个“当前生效的环”
• 当节点变更时，客户端更新节点视图并重建哈希环
• 重建过程需要可控，不能一收到变更就立刻把流量全切过去

节点状态机设计

在扩缩容和故障场景下，我建议不要只用“在线/离线”两个状态。至少要有下面几个状态：

• UP：正常服务
• JOINING：新节点加入，先接少量流量
• DRAINING：准备下线，不再接新流量，但保留已有数据访问
• DOWN：不可用，立即摘除

stateDiagram-v2
    [*] --> JOINING
    JOINING --> UP: 灰度验证通过
    UP --> DRAINING: 缩容/维护
    DRAINING --> DOWN: 排空完成
    UP --> DOWN: 健康检查失败
    DOWN --> JOINING: 恢复后重新灰度

这个状态机的意义很大：

• 扩容不是“上来就全量”
• 缩容不是“立刻消失”
• 故障恢复也不应瞬间全量回流

容量估算：别等满了才扩

缓存扩缩容如果只靠告警触发，通常会偏晚。更靠谱的做法是提前估算容量。

估算维度

至少看这几项：

1. 总 key 数
2. 平均 value 大小
3. 副本数
4. 内存碎片率
5. 保留冗余
6. 热点 key 增长速度

一个简化估算公式可以这样写：

总容量 ≈ key数 × (平均key大小 + 平均value大小 + 元数据开销) × 副本数 × 安全系数

其中安全系数建议至少留到 1.3 ~ 1.5，因为你还要考虑：

• 内存碎片
• 热点突增
• 扩容期间双写或双读的额外开销
• 某些节点短时失效时的流量接管

扩容阈值建议

我个人更推荐在以下条件时提前扩容：

• 内存使用率长期高于 70%
• P99 延迟持续上升
• 命中率开始下降且数据库回源增加
• 热点 key 集中在少数节点
• 单节点 QPS 接近容量上限的 60%~70%

因为扩容不是瞬时完成的，你需要为“迁移期”和“验证期”预留缓冲。

实战代码（可运行）

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

• 节点注册到治理中心
• 根据节点状态和权重构建一致性哈希环
• 查询 key 路由
• 扩容与缩容时的 key 迁移比例

你可以直接保存为 consistent_hash_demo.py 运行。

import hashlib
import bisect
import random
from collections import defaultdict
from dataclasses import dataclass


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


@dataclass
class Node:
    node_id: str
    host: str
    port: int
    weight: int = 1
    status: str = "UP"  # JOINING / UP / DRAINING / DOWN

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


class ServiceRegistry:
    def __init__(self):
        self.nodes = {}

    def register(self, node: Node):
        self.nodes[node.node_id] = node

    def update_status(self, node_id: str, status: str):
        if node_id in self.nodes:
            self.nodes[node_id].status = status

    def list_routable_nodes(self):
        routable = []
        for node in self.nodes.values():
            # JOINING 节点先不参与正式路由；DRAINING 节点不接新 key
            if node.status == "UP":
                routable.append(node)
        return routable

    def list_all_nodes(self):
        return list(self.nodes.values())


class ConsistentHashRing:
    def __init__(self, virtual_nodes_factor: int = 100):
        self.virtual_nodes_factor = virtual_nodes_factor
        self.ring = []
        self.node_map = {}

    def rebuild(self, nodes):
        self.ring.clear()
        self.node_map.clear()

        for node in nodes:
            vnode_count = self.virtual_nodes_factor * node.weight
            for i in range(vnode_count):
                vnode_key = f"{node.node_id}#{i}"
                h = md5_hash(vnode_key)
                self.ring.append(h)
                self.node_map[h] = node

        self.ring.sort()

    def get_node(self, key: str):
        if not self.ring:
            return None
        h = md5_hash(key)
        idx = bisect.bisect_left(self.ring, h)
        if idx == len(self.ring):
            idx = 0
        return self.node_map[self.ring[idx]]

    def distribution(self, keys):
        result = defaultdict(int)
        for key in keys:
            node = self.get_node(key)
            if node:
                result[node.node_id] += 1
        return dict(result)


def calc_migration_ratio(old_ring: ConsistentHashRing, new_ring: ConsistentHashRing, keys):
    changed = 0
    for key in keys:
        old_node = old_ring.get_node(key)
        new_node = new_ring.get_node(key)
        if old_node and new_node and old_node.node_id != new_node.node_id:
            changed += 1
    return changed / len(keys)


def print_distribution(title, dist):
    print(f"\n{title}")
    total = sum(dist.values())
    for node_id, count in sorted(dist.items()):
        ratio = count / total * 100 if total else 0
        print(f"  {node_id}: {count} keys ({ratio:.2f}%)")


def main():
    registry = ServiceRegistry()

    # 初始 3 节点
    registry.register(Node("node-a", "10.0.0.1", 6379, weight=1, status="UP"))
    registry.register(Node("node-b", "10.0.0.2", 6379, weight=1, status="UP"))
    registry.register(Node("node-c", "10.0.0.3", 6379, weight=1, status="UP"))

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

    old_ring = ConsistentHashRing(virtual_nodes_factor=120)
    old_ring.rebuild(registry.list_routable_nodes())
    old_dist = old_ring.distribution(keys)
    print_distribution("初始分布", old_dist)

    # 扩容一个新节点
    registry.register(Node("node-d", "10.0.0.4", 6379, weight=1, status="UP"))

    new_ring = ConsistentHashRing(virtual_nodes_factor=120)
    new_ring.rebuild(registry.list_routable_nodes())
    new_dist = new_ring.distribution(keys)
    print_distribution("扩容后分布", new_dist)

    ratio = calc_migration_ratio(old_ring, new_ring, keys)
    print(f"\n扩容后 key 迁移比例: {ratio:.2%}")

    # 模拟缩容：node-b 下线
    shrink_registry = ServiceRegistry()
    for node in registry.list_all_nodes():
        if node.node_id != "node-b":
            shrink_registry.register(node)

    shrink_ring = ConsistentHashRing(virtual_nodes_factor=120)
    shrink_ring.rebuild(shrink_registry.list_routable_nodes())
    shrink_dist = shrink_ring.distribution(keys)
    print_distribution("缩容后分布（移除 node-b）", shrink_dist)

    shrink_ratio = calc_migration_ratio(new_ring, shrink_ring, keys)
    print(f"\n缩容后 key 迁移比例: {shrink_ratio:.2%}")

    # 模拟权重不一致的情况：node-d 更大，分配双倍权重
    weighted_registry = ServiceRegistry()
    weighted_registry.register(Node("node-a", "10.0.0.1", 6379, weight=1, status="UP"))
    weighted_registry.register(Node("node-b", "10.0.0.2", 6379, weight=1, status="UP"))
    weighted_registry.register(Node("node-c", "10.0.0.3", 6379, weight=1, status="UP"))
    weighted_registry.register(Node("node-d", "10.0.0.4", 6379, weight=2, status="UP"))

    weighted_ring = ConsistentHashRing(virtual_nodes_factor=120)
    weighted_ring.rebuild(weighted_registry.list_routable_nodes())
    weighted_dist = weighted_ring.distribution(keys)
    print_distribution("按权重分布（node-d 权重=2）", weighted_dist)


if __name__ == "__main__":
    main()

运行结果能看什么

你会看到几类现象：

1. 初始 3 节点分布大体均衡
2. 新增节点后，只有一部分 key 迁移
3. 移除节点时，迁移范围主要集中在被移除节点负责的 key
4. 节点权重提高后，分配到的 key 明显更多

这就是一致性哈希最核心的工程收益：控制迁移范围，而不是避免迁移本身。

扩缩容流程设计

代码能跑只是第一步，线上真正关键的是流程。我建议采用下面这个扩容流程。

sequenceDiagram
    participant Ops as 运维/平台
    participant Registry as 服务治理中心
    participant Client as 业务客户端
    participant NewNode as 新缓存节点
    participant OldNodes as 旧缓存集群

    Ops->>NewNode: 启动新节点
    NewNode->>Registry: 注册 JOINING
    Registry-->>Client: 下发变更事件
    Client->>Registry: 拉取节点列表
    Client->>Client: 构建灰度哈希环
    Client->>NewNode: 小流量探测
    NewNode-->>Client: 响应健康
    Ops->>Registry: 节点状态切换为 UP
    Registry-->>Client: 下发正式变更
    Client->>Client: 重建正式哈希环
    Client->>NewNode: 接入正式流量

推荐的扩容步骤

1. 新节点以 JOINING 状态注册

不要一上线就参与正式路由。先让它完成：

• 预热
• 健康检查
• 基础监控接入
• 与旧集群网络连通性验证

2. 灰度流量验证

可以用两种办法：

• 按比例放量：1% -> 5% -> 20% -> 100%
• 按 key 范围灰度：只让部分租户或部分业务线流量进入

这个阶段重点观察：

• 命中率
• 延迟
• 连接数
• 拒绝率
• 回源流量

3. 切换为 UP

确认新节点稳定后，再让客户端把它纳入正式哈希环。

4. 缩容先进入 DRAINING

对准备下线的节点：

• 不再接收新的 key
• 保留对旧 key 的读能力一段时间
• 等请求自然排空后再下线

这样做虽然流程复杂一点，但比“直接删节点”稳定得多。

常见坑与排查

这一节我尽量写得像真实排障笔记，因为这些坑非常常见。

坑 1：不同客户端的节点列表不一致

现象

同一个 key，在不同应用实例上算出来的目标节点不同。

常见原因

• 服务发现变更传播延迟
• 某些实例本地缓存了旧节点列表
• 节点排序规则不一致
• 权重配置没同步

排查方法

1. 对比各实例当前使用的节点清单
2. 打印哈希环版本号
3. 打印某个 key 的 hash 值和命中的 vnode
4. 检查服务治理事件是否丢失或延迟

建议

• 节点元数据必须带版本号
• 客户端重建环时必须按固定排序
• 变更采用“全量快照 + 增量事件”的方式兜底

坑 2：虚拟节点太少导致分布不均

现象

某个节点内存和 QPS 明显高于其他节点。

常见原因

• 每个物理节点只配了几个虚拟节点
• 哈希函数质量一般
• 节点权重设计不合理

排查方法

• 统计 key 分布比例
• 观察节点 QPS 标准差
• 对比不同 vnode 数下的分布结果

建议

• 一般从 100~300 个虚拟节点/权重单位起步
• 用统一哈希函数，不要各语言实现不一致
• 高配节点用更高权重，而不是盲目增加机器数

坑 3：扩容后命中率突然下降

现象

节点是加了，但数据库压力却更大了。

本质原因

虽然一致性哈希只迁移部分 key，但迁移的那部分 key 在新节点上是冷数据。如果没有预热，还是会出现明显回源。

解决思路

• 对热点 key 做主动预热
• 采用“旧节点 miss 后回源，回填新节点”的策略
• 对超热点数据使用本地缓存 + 集群缓存两级架构
• 高峰前不要做激进扩容

坑 4：节点频繁抖动导致环频繁重建

现象

缓存命中率和延迟周期性波动。

常见原因

• 健康检查过于敏感
• 网络抖动导致节点一会儿 UP 一会儿 DOWN
• 客户端收到变更就立即重建环

建议

• 健康检查做连续失败阈值
• 增加摘除冷静期
• 对频繁变更做合并更新
• 环重建要限频

坑 5：缩容时数据“凭空消失”

现象

缩容后，部分热点 key 命中率长期恢复不上来。

常见原因

• 节点直接下线，没有排空
• 业务读路径只认新环，不读旧节点
• 缩容时间选在业务高峰

建议

• 缩容走 DRAINING -> DOWN
• 缩容窗口尽量选低峰期
• 必要时短期保留“双环读”策略

安全/性能最佳实践

缓存集群扩缩容常被当成“性能问题”，但我建议同时从安全性、稳定性、可观测性三个角度看。

1. 服务发现链路要鉴权

如果攻击者能伪造节点注册或篡改节点状态，客户端就可能把流量打到错误目标，后果非常严重。

建议至少做到：

• 节点注册需要身份认证
• 节点元数据传输走 TLS
• 治理中心的变更操作要审计
• 客户端只信任签名或白名单节点

2. 哈希环更新要可回滚

扩缩容不是一定成功的。尤其是新节点版本不一致、网络路径异常时，很容易需要快速撤回。

建议：

• 保留最近几个环版本
• 支持一键回滚到前一版本
• 变更前后打点对比命中率和延迟

3. 本地缓存节点视图，但设置过期与兜底

完全实时依赖治理中心，会让客户端在控制面异常时无法工作；但完全不更新，也会造成脑裂。

比较稳妥的做法是：

• 本地缓存最近一次成功的节点视图
• 设置过期时间
• 周期性全量拉取
• 增量事件失败时降级到全量刷新

4. 双环读策略要有限度

某些团队会在扩缩容时做“双环读”：

1. 先查新环节点
2. miss 再查旧环节点
3. 命中则回填新节点

这个策略确实能缓解命中率下降，但也有边界：

• 增加一次网络跳数
• 放大客户端逻辑复杂度
• 在高并发下可能带来额外连接压力

所以它更适合作为短期过渡策略，而不是常态方案。

5. 热点 key 单独治理

一致性哈希能解决整体均衡，但对极端热点 key 帮助有限。一个超级热点 key 无论如何都只会路由到某个目标节点。

可选手段：

• 热点 key 本地缓存
• 多副本读扩散
• 热点探测后主动拆分
• 对部分热点采用特殊路由策略

6. 指标体系要完整

如果只看“缓存节点活着没”，那扩缩容几乎等于盲飞。建议重点观察这些指标：

• 命中率
• 回源 QPS
• 单节点 QPS/连接数
• P95/P99 延迟
• 内存使用率和碎片率
• 哈希环版本分布
• 节点变更频率
• 热点 key 排名

一个更贴近生产的落地建议

如果你现在正准备在团队里上线这个方案，我建议按下面的节奏推进，而不是一次性做满。

第一阶段：先替换路由算法

目标是把 hash(key) % N 替换成一致性哈希，并引入虚拟节点。

这一阶段先不追求复杂治理能力，先确认：

• key 分布是否更均衡
• 扩容时迁移比例是否下降
• 客户端实现是否跨语言一致

第二阶段：接入服务治理

加入：

• 服务发现
• 节点健康状态
• 权重管理
• 版本化节点视图

这一阶段的核心目标是：客户端看到的是统一、可控、可回滚的节点列表。

第三阶段：做灰度扩缩容

把节点状态机和灰度机制补齐：

• JOINING
• UP
• DRAINING
• DOWN

同时接入观测指标和回滚机制。

第四阶段：治理热点与异常场景

最后再补：

• 双环读
• 热点 key 特殊处理
• 故障摘除冷静期
• 全量快照兜底

这样做的好处是，系统复杂度跟着收益逐步上升，不会一开始就把自己拖进运维泥潭。

总结

一致性哈希并不是“缓存扩缩容的银弹”，但它确实解决了最核心的问题：节点变化时，尽量只迁移必要的数据。不过真正能让这套方案在生产里稳定运行的，不只是哈希环本身，而是它背后的服务治理能力：

• 节点发现是否一致
• 状态切换是否可控
• 故障摘除是否稳妥
• 扩缩容是否支持灰度
• 监控和回滚是否完善

如果你只记住一句话，我建议记这个：

一致性哈希负责“少动数据”，服务治理负责“稳动流量”。

最后给几个可执行建议：

1. 不要再用简单取模做会扩缩容的缓存分片
2. 虚拟节点数量要足够，并结合权重设计
3. 扩容先灰度，缩容先排空
4. 客户端必须使用版本化节点视图
5. 命中率、回源、环版本分布要一起监控
6. 双环读只作为过渡，不要长期依赖

边界条件也要说清楚：如果你的节点规模很小、几乎不扩缩容、业务对短时命中率下降不敏感，那么一致性哈希 + 完整服务治理可能有些“重”。但只要你的缓存集群开始承载核心流量，或者扩缩容已经影响到数据库和业务稳定性，这套方案基本就不是“可选项”，而是“必修课”了。