手写分布式缓存：从一致性哈希到扩容踩坑实录

我在一个内部短链服务上吃过一次大亏：数据量涨到几十亿之后，单节点的内存缓存明显扛不住，于是想当然地上了分片，结果扩容节点那晚，缓存命中率直接崩到个位数，数据库连接池被打满，服务差点雪崩。复盘时发现问题不在“缓存”，而在“分布式”这三个字——哈希重分布、节点感知、数据迁移，每一样都比单机缓存难得多。那之后我花了三周时间从零手写了一套轻量分布式缓存系统，专门用来验证和承载这类场景。

这套系统的定位很明确：不是要替代 Redis，而是给内部特定业务做一个可定制、可嵌入、能随业务需求增加淘汰策略和路由规则的 KV 缓存中间件。它包含一致性哈希路由、节点心跳管理、本地缓存引擎、客户端 SDK、扩容迁移等模块。整套代码跑通之后，我对分布式缓存的认知比之前用任何现成中间件都深。这篇文章就按我实现时的顺序，把设计逻辑、关键代码、真实踩坑全部记录下来，适合已经用过缓存中间件、但想搞清楚“背后到底怎么工作”的后端开发，也适合打算动手做小规模分布式系统的同学参考。

1. 为什么自己动手写一套分布式缓存

先回答一个绕不开的问题：这年头 Redis 遍地都是，自研缓存图什么？我的答案只有一个——分布式缓存的难点从来不在于“缓存”，而在于“分布式”。只把 Redis 搭成集群用，很多底层问题会被隐藏掉，一旦遇到“加节点全量重哈希”这类情况，就会措手不及。自己实现一遍，才能看清楚分片、路由、故障摘除、扩容迁移到底是怎么回事。

1.1 是造轮子吗：先看清缓存场景的特殊性

我并不是建议任何团队都去自研缓存。选这条路前，必须想清楚缓存场景和数据库场景有一个本质区别：缓存数据是可以丢的。

数据库如果丢了一条用户订单，那是事故；缓存如果丢了一个 key，最多就是多查一次数据库。这个“可容忍丢失”的语义，让分布式缓存的实现难度比分布式数据库低了一个量级。我不需要做复杂的 Raft 协商、多副本强一致、崩溃恢复，只需要保证三件事：数据尽量均匀分散到多个节点、某个节点挂了之后系统还能继续对外服务、扩容时不要引发大规模的缓存穿透。

当时我盘了一下内部需求，发现确实有几个用现成中间件反而不爽的场景：第一，业务希望自定义淘汰策略，比如按登录态优先级淘汰，而不是简单的 LRU；第二，部分缓存 value 需要压缩后存储，Redisson 那套序列化协议太重；第三，团队希望在缓存不可用时能自动降级到数据库，并且把这个降级逻辑做成配置开关，而不是散落在业务代码里。这些需求单拎出来都能用 Redis 拼，但拼多了等于在应用层重写一个缓存框架。

所以最后的结论是：自研这套系统，不追求承载所有业务，只做“分片缓存通路”的中间层。内部代号就叫 ring-cache，后面我会一直这么称呼它。

1.2 技术选型对比：自研轻量组件并非“头铁”

动手之前，我列了一个对比表，把可行方案放在一起看过一遍：

这里想强调一点，自研不是“头铁”，而是试错成本低。缓存系统即便写坏了，最坏的结果就是缓存 miss 后全部回源，不会造成数据错误。这一点给了项目很大的试错空间。如果你们业务对缓存命中率非常敏感，比如几十万 QPS 全靠缓存扛，那我不建议用自研系统直接接生产流量，更好的做法是先做一个旁路实验，等稳定性打出来了再逐步切流量。

2. 数据定位：一致性哈希和虚拟节点不是玄学

分布式缓存最基础的一件事，就是给定一个 key，系统必须立刻知道它该去哪个节点。很多人认为这有什么难的，hash(key) % N 不就完事了。第一次扩容前我也是这么想的，直到我用取模方案做了演示，加了一台机器后发现：大部分 key 的映射位置都变了，缓存几乎全部失效。

2.1 从 hash 取模说起：为什么节点一扩全世界都知道

假设现在有 3 个节点，key 的分布规则是 hash(key) % 3。当我把节点扩容到 4 个，规则变成 hash(key) % 4。绝大多数 key 的余数都变了，也就是说，它们原本在节点 A，现在可能应该去节点 B。问题是节点 B 上根本没有这些缓存，于是所有请求瞬间穿透到数据库。

如果数据库能扛住，那还算幸运；如果数据库扛不住，就是教科书级别的缓存雪崩。取模路由最大的问题是“路由结果与节点数量强绑定”，节点数量一变，历史数据几乎全部失效。

一致性哈希解决的正是这个问题。它把哈希值组织成一个环，不直接拿节点数量参与运算。新的节点加入时，只会影响环上相邻的一小段区域，其他区域的 key 完全不用动。

2.2 一致性哈希环与虚拟节点实现

我在 ring-cache 里用 Java 实现了一个很标准的 ConsistentHashRing，核心逻辑用 TreeMap 保存哈希环。TreeMap 的好处是可以直接使用 ceilingEntry 找到“顺时针遇到的第一个节点”，天然契合一致性哈希的查找方式。

java复制public class ConsistentHashRing {
    private static final int VIRTUAL_NODE_COUNT = 160;
    private final TreeMap<Integer, String> ring = new TreeMap<>();
    private final HashFunction hashFunction = new Murmur3HashFunction();

    public void addNode(String nodeId) {
        for (int i = 0; i < VIRTUAL_NODE_COUNT; i++) {
            int hash = hashFunction.hash(nodeId + "#" + i);
            ring.put(hash, nodeId);
        }
    }

    public void removeNode(String nodeId) {
        for (int i = 0; i < VIRTUAL_NODE_COUNT; i++) {
            int hash = hashFunction.hash(nodeId + "#" + i);
            ring.remove(hash);
        }
    }

    public String route(String key) {
        if (ring.isEmpty()) {
            return null;
        }
        int hash = hashFunction.hash(key);
        Integer target = ring.ceilingKey(hash);
        if (target == null) {
            target = ring.firstKey();
        }
        return ring.get(target);
    }
}

你可能注意到了虚拟节点。为什么一个物理节点要在环上放 160 个虚拟节点？因为如果不这么做，当集群里只有三五台机器时，哈希点在环上的分布会很不均匀，很可能出现某个节点承载了 40% 的数据，另一个节点只有 15%。引入虚拟节点的本质是“让一个物理节点在环上多占几个位置”，把分布的粒度打散，数据量越大越均匀。

160 这个数值不是拍脑袋定的。节点数量少时，太少会倾斜；太多会占用 TreeMap 内存，而且每次节点变更要重算的哈希次数也变多。实测下来，节点在 3 到 20 个范围内，160 个虚拟节点能让数据分布的标准差控制在 5% 以内，效果已经足够好。

2.3 顺时针查找与路由表实时性

路由查找的逻辑一句话就能讲清：把 key 的哈希值放在环上，沿顺时针方向找到的第一个虚拟节点，就是数据归属节点。如果环上的哈希值都小于 key 的哈希值，说明已经绕了一圈，回到环首即可。

真正需要留意的不是查找算法，而是路由表的实时性。当节点动态上下线时，所有客户端或者其他节点上的路由环都必须感知到这个变化，否则就会出现 data moved。我在 ring-cache 的做法是路由环采用写时复制思想，节点变更后构建一份新的 TreeMap 并通过 volatile 引用发布，这样读请求不需要加锁，写变更也只发生在节点增减的瞬间。核心代码类似：

java复制public class RoutingTable {
    private volatile ConsistentHashRing ring;

    public void refresh(Set<String> onlineNodes) {
        ConsistentHashRing newRing = new ConsistentHashRing();
        for (String node : onlineNodes) {
            newRing.addNode(node);
        }
        this.ring = newRing;
    }

    public String route(String key) {
        return ring.route(key);
    }
}

路由环更新的调用时机非常关键。如果节点 A 心跳超时，但它的进程还没退出，此时直接把它从路由环里摘掉，可能会导致“请求已经到了 A、但路由表说 A 不存在”的错乱。所以在刷新路由环前必须确认节点确实不可用，这套判断机制放到下一节讲。

3. 节点成员管理：心跳、状态同步和脑裂让步

有了路由环，下一步就是让所有节点互相知道对方的存在。从单机缓存到分布式缓存，最容易被忽视的就是“成员管理”。节点什么时候加入、什么时候离开、谁来判断它挂了，这些问题没想清楚，后面全是坑。

3.1 节点发现机制：最少依赖的种子节点设计

成员管理最成熟的做法之一是引入 ZooKeeper/etcd 做服务注册与发现。但 ring-cache 希望尽量降低部署依赖，所以我选了一个更朴素的方案：配置文件里写死一组种子节点地址，新节点启动后先联系任意一个种子节点，上报自己的地址，再由种子节点把当前集群的成员列表广播给新节点。

这套机制和 etcd 那类比当然显得“土”，但对一个缓存系统来说已经够用。注册信息就两类：IP+端口、节点启动时间。广播协议也非常简单，直接走 TCP 报文：

json复制{
  "type": "JOIN",
  "node": "192.168.1.10:7001",
  "startedAt": 1710000000000
}

每个节点收到 JOIN 后，更新本地成员列表，并把自己知道的其他节点同步给新加入的节点，同步完了再触发一次路由环的 refresh。这个方案最大的缺点是当节点数量超过几十台时，广播风暴会变得明显，所以我也没打算让它支撑大规模集群，内部几十个节点的规模完全是够用的。

3.2 心跳与状态判定

节点加入之后，成员管理要解决的核心问题就是故障检测。我的第一版实现很简单：每个节点每隔 1 秒向其他所有节点发送一个 PING，收到 PONG 就认为对方存活，连续 3 次没收到 PONG 就标记为下线。

这个逻辑在测试环境永远正常，因为测试环境网络非常稳定。但在线上，一个 200 毫秒的 GC 暂停就可能让心跳线程没能及时发送报文，PONG 也延迟了，于是其他节点就把这台机器摘掉了。

吸取教训后，我把故障判定改成“连续失败次数 + 超时阈值”。心跳仍然每秒发一次，但超时时间设置为 5 秒，连续 5 次超时才会把节点标记为 offline。这个参数本质上是在“故障发现速度”和“误判概率”之间做权衡。想快速摘除故障节点，就会因为网络抖动而误杀；想避免误杀，就要接受故障节点多存活一段时间。缓存场景下，我宁愿接受后者——多等几秒，最多就是部分请求失败或穿透数据库，比全集群雪崩好太多。

3.3 缓存场景下我们必须接受的“脑裂事实”

网络分区是分布式系统绕不开的话题。假设集群被切成了两半，两边都无法联系对方，这时如果两边都认为自己才是合法集群，就会出现脑裂。分布式数据库对脑裂是零容忍的，因为两边同时写同一份数据会造成不可逆的错误。

缓存系统不同。我们已经接受了“数据可以丢”，所以面对网络分区时采用了一个很务实的策略：少数派节点继续对外提供服务，但数据可能在分区恢复后不是最新版本；业务侧通过 TTL 兜底，过期后重新从数据库加载就行。

这意味着我不会去实现复杂的租约或选举机制，而是把一致性责任大部分交给数据源和过期时间。这个设计一开始会让人心里不踏实，但想明白后会发现非常省事。缓存系统最大的妥协就在于：它不需要证明自己是对的，只需要在绝大部分时间里足够快，出错时能快速恢复即可。

4. 节点本地的缓存引擎：并发、淘汰和过期到底怎么做

分布式缓存的能力最终要落到每个节点的本地存储上。路由做得再漂亮，如果每个节点的缓存引擎性能不行、淘汰逻辑有问题，整体效果也会大打折扣。我在这一部分投入的时间最多，因为单机缓存引擎才是“缓存”二字的本体。

4.1 数据结构选型：ConcurrentHashMap 与 LRU 怎么共存

最自然的本地存储实现是用 ConcurrentHashMap 保存 key-value，因为它的并发读性能极好。但 ConcurrentHashMap 本身不维护访问顺序，要实现真正的 LRU 淘汰，还得额外维护一个双向链表，每次读写都要移动链表节点。这在高并发下会引入严重的竞争，因为所有线程都去抢同一把“移动链表节点”的锁。

我当时的取舍是放弃“严格 LRU”，采用分片近似 LRU：把本地缓存划分为 16 个分片，每个分片内部维护一个 LinkedHashMap，并开启 accessOrder 来记录访问顺序。这样每个分片只有少量线程竞争，锁粒度大大降低。

java复制public class LruShard {
    private final int maxCapacity;
    private final LinkedHashMap<String, CacheEntry> map;

    public LruShard(int maxCapacity) {
        this.maxCapacity = maxCapacity;
        this.map = new LinkedHashMap<>(16, 0.75f, true) {
            @Override
            protected boolean removeEldestEntry(Map.Entry<String, CacheEntry> eldest) {
                return size() > maxCapacity;
            }
        };
    }

    public synchronized CacheEntry get(String key) {
        return map.get(key);
    }

    public synchronized void put(String key, CacheEntry entry) {
        map.put(key, entry);
    }
}

你可能会担心 synchronized 性能不够。实测下来，在 8 核心的机器上，16 个分片可以把锁竞争摊得很薄，整体性能达到每秒 20 万次读写，完全够内部服务用。如果想更激进，可以用 Caffeine 那种基于 W-TinyLFU 的算法，但那个实现复杂度很高，对大多数场景来说分片 LRU 的性价比已经很高了。

4.2 过期策略：惰性删除加周期扫描，参考 Redis 但不照搬

TTL 过期是缓存系统最容易写错的地方。很多人第一反应是“我 put 的时候启动一个定时任务，到时间就删”，但这样做在 key 数量很大时会非常浪费。一个 key 一个 Timer，内存还没省下来，定时器倒先占了大量资源。

我参考 Redis 的做法做了两层设计。第一层是惰性删除：每次 get 的时候检查这条记录的 expireAt 是否小于当前时间，是的话直接返回 null，并把 key 从 map 中移除。第二层是周期扫描：每秒随机抽取一批 key，检查过期情况，比如每次抽查 100 个，如果过期比例超过 25%，就继续抽。这个策略避免了全量扫描，也保证了过期 key 不会在内存中停留太久。

java复制public class CleanupTask implements Runnable {
    private final LocalCache cache;

    @Override
    public void run() {
        int expired = 0;
        for (int i = 0; i < 100; i++) {
            String key = cache.randomKey();
            if (key == null) {
                return;
            }
            if (cache.isExpired(key)) {
                cache.delete(key);
                expired++;
            }
        }
        if (expired > 25) {
            // 过期比例偏高，下一轮继续扫
        }
    }
}

这里有一个被忽略的细节：缓存系统里的 TTL 不只是为了让数据按时失效，它还是缓存与数据库之间数据一致性的最后防线。任何主动删 key 的逻辑都可能因为消息丢失或代码 bug 而没执行，TTL 保证了在最坏情况下，数据也会在一段时间后重新从数据库加载。所以 TTL 不要设置太长，内部业务里普通配置缓存我一般控制在 3 到 10 分钟之间。

4.3 内存控制和淘汰策略实现要点

LRU 和 TTL 解决的是淘汰顺序和过期时间，但内存上限必须提前规划。我在每个节点上设置了 maxMemory，比如 4GB。写入数据时，如果发现当前占用超过了 95% 的上限，会触发一次全量的逐出扫描，把最久没访问的 5% 数据淘汰掉。这个操作比较重，所以不能频繁触发，宁可提前在达到 80% 时就主动降低逐出阈值。

另一个容易犯的错是把 value 直接存成对象引用。如果缓存模块和业务模块在同一个 JVM 里，业务侧修改了对象字段，缓存里的数据也跟着变了，排查起来极其困难。我在 ring-cache 中强制要求 value 必须可序列化，并且默认走 byte[] 存储，业务侧自己负责序列化和反序列化。虽然多了一次序列化开销，但隔离性大大提高，线上再也没有出现过“缓存被业务改坏”的诡异问题。

内存淘汰还得分清“优先淘汰谁”。对于本地缓存，我暴露了一个淘汰策略接口，业务方可以按需实现。普通业务用 LRU 足够，但遇到登录态这类“要求过期时间严格”的场景，也可以使用 TTL 优先策略，把即将过期的 key 先淘汰出去。这种可扩展性正是自研缓存系统相对 Redis 的一个优势。

5. 一条读写请求的完整旅程：路由、代理转发与客户端 SDK

前面的章节把存储、节点管理、路由分片都讲完了，现在要把这些模块串起来，回答一个最实际的问题：当业务代码执行 cache.get("userId_123") 时，这条请求到底经历了什么？

5.1 服务端代理 vs Smart Client：两种形态怎么选

读写请求跨节点的方案有两种主流形态。第一种是服务端代理模式，客户端把所有请求发给一个代理节点，由代理节点根据 key 计算目标节点并转发，类似 Codis 的做法。这个模式对客户端友好，但会引入额外一跳，代理节点本身也可能成为瓶颈。第二种是 Smart Client 模式，客户端 SDK 自己持有哈希环，直接根据 key 算出目标节点，然后直连目标节点，类似 Redis Cluster 官方客户端的做法。ring-cache 用的是第二种。

Smart Client 的实现难点在于，SDK 必须能感知集群成员变化。节点上线、下线、心跳超时摘除时，SDK 里的哈希环需要实时刷新。如果 SDK 持有的环和真实的环不一致，就会出现请求发到节点 A，但 A 说“这个 key 不归我管”。

5.2 请求流程：GET、SET、TTL 如何落到具体节点

以一次 GET key 为例，完整流程如下：

1. SDK 计算 key 的哈希值，在当前哈希环上找到目标节点地址。
2. SDK 通过 Netty 客户端向目标节点发起 GET 请求。
3. 目标节点收到请求后，再次用本地路由环计算 key 的真实归属节点。
4. 如果目标节点发现“key 属于另一个节点 B”，则返回 MOVED 响应，并附带节点 B 地址。
5. SDK 收到 MOVED 后，在新地址更新本地路由环，然后重新发送请求到节点 B。
6. 节点 B 本地查找缓存，命中则直接返回，未命中则去数据库加载，回填缓存后返回。

code复制客户端 SDK 请求流程伪代码：
target = ring.route(key)
response = sendGet(target, key)
if response.isMoved():
    ring.refreshNode(response.getNewTarget())
    target = response.getNewTarget()
    response = sendGet(target, key)

这里 MOVED 重定向机制很重要。它保证了即使 SDK 的路由环暂时落后于真实状态，也不会返回错误数据，而是先纠正自己的路由再重试一次。这个设计借鉴了 Redis Cluster 的思路，能让客户端与服务端在路由视图上有短暂不一致时的系统仍然可用。需要提醒的是，一旦收到大量 MOVED，说明 SDK 的环确实过期了，需要立即触发全量路由刷新，否则每个 key 都会浪费一次额外的网络请求。

SET 流程类似，不同的是在节点本地写入时还要带上 TTL。LLT 过期时间的语义是“从现在起多少毫秒”。如果业务需要对某个 key 续期，SDK 需要支持 touch 命令，用来更新 TTL 而不修改 value。这个能力在使用分布式锁或限流时非常有用。

5.3 超时、重试与降级：保证后端不被打垮

缓存系统的存在意义是保护数据库，但如果缓存本身出现故障，而应用层逻辑又“永不放弃”，那么所有请求都会打到数据库，形成雪崩。所以我在 SDK 里设计了超时和降级参数。

单个请求的超时时间一般设置为 50 毫秒。超过这个时间，就认为本次缓存访问失败，直接降级到数据库，而不是继续等待。重试次数设为 0 或 1，超过一次就不再尝试。很多系统正是因为在缓存超时后重试了三次，导致数据库同时接收到三倍流量，瞬间被打挂。

降级逻辑也必须做成可配置的。某些读多写少的场景，如果缓存不可用，可以接受直接查数据库；但某些高并发写场景，缓存挂掉时不能让请求无限量涌入数据库，而应该进行限流或快速失败。我封装了一个 CacheRoute 接口，把“查询缓存失败后怎么处理”交给上层策略决定，默认策略是“查询数据库，同时尝试异步回填缓存”。“渐进式降级”听起来简单，但如果没有提前做好，故障发生时人脑很难冷静分析，最后就是看着监控一片红无能为力。

6. 扩容迁移和踩坑记录：测试环境正常，线上却把数据库打穿了

最后一章分享最容易翻车的扩容迁移，以及几个真实事故的排查过程。前几个章节讲的是“正常怎么运行”，这一章讲的是“异常时怎么活下来”。

6.1 新节点加入时的迁移策略：为什么不能只改路由

当新节点加入集群时，如果直接把路由环刷新，让新节点参与路由，那么一部分原本属于旧节点的 key 会被路由到新节点。可新节点上没有任何缓存，这些 key 全部会 miss，数据库又会迎来一波峰值。

最直观的方案是做一次全量迁移：新节点加入后，从旧节点把属于新节点的 key 复制过来。这个方案的问题在于“判断 key 属于谁”需要遍历旧节点上的所有 key。如果单节点有几千万 key，全量遍历会占用大量 CPU 和 IO，迁移期间旧节点的服务能力会大幅下降。而且，缓存是动态变化的，迁移过程中旧 key 又过期、又新增，倒腾一轮之后可能发现迁过来的数据很多已经过时了。

我更推荐的是“懒迁移 + 预热”的组合方案。

懒迁移的含义是：节点加入后，路由环刷新，但旧数据不立刻搬。访问 key 时先按新路由找到新节点，新节点发现没有数据，再向旧节点发起一个内部 GET 请求，从旧节点取到数据后回填到新节点。这个过程只搬运“被访问到”的数据，流量越大数据搬得越快，流量小的时候也不必浪费资源。

如果担心新节点上线后突然被大量访问造成回源压力，可以对流量做预热：先按旧节点读取热点 key 列表，把这些 key 预先写入新节点。这个步骤可以配合一个后台任务慢慢做，任务限速，比如每秒最多从旧节点读取 5000 个 key。

6.2 迁移期间如何保持命中率

懒迁移的代价是迁移期内命中率会出现短暂下降，因为很多 key 第一次访问时需要二次查询。我的经验是，扩容动作最好在低峰期执行，并且可以先“双订阅”一段时间的备份流量，让新节点通过懒迁移积累热数据，等命中率自然爬升，再把业务流量正式切过去。

另外一个调整余地是虚拟节点的变更粒度。如果一次加入一个物理节点，而这个节点对应 160 个虚拟节点，路由环的变化是分散的，迁移量被摊薄到集群的各个区域，对整体命中率的冲击比大段摘除要平滑很多。这也是虚拟节点在迁移层面的隐形价值——它不只解决了均衡分布，还降低了单次拓扑变更的影响半径。

6.3 线上事故复盘：三个真实问题让我改了三版设计

第一个问题是网络抖动误杀节点。上线第二周，机房网络出现一次轻微抖动，持续不到两秒。但由于心跳超时设置为 3 秒，很多节点在抖动恢复前就被标记为 offline。路由环连续通知所有 SDK 把 offline 节点摘除，请求纷纷转向其他节点，数据库压力瞬间翻了 4 倍。

排查过程很有意思：监控面板上数据库 QPS 先上涨，然后才开始大量报错，而缓存命中率是在数据库上涨两三分钟后才跌下来的。我在日志里看到大量 node offline 记录才意识到，真正的元凶不是数据库变慢，而是网络抖动触发了“缓存节点大规模被判死”。修复方式就是前面提到的，把超时时间调到 5 秒，连续 5 次失败才确认下线。虽然故障发现变慢了，但误杀问题彻底消失。

第二个问题是热点 key 打爆单节点。某个活动的商品详情被广泛分享，而分享出去的链接都指向同一个 key。一致性哈希只能保证 key 在环上分布均匀，但它不感知访问频率。这个 key 被路由到节点 A，节点 A 的 CPU 被打到满载，其他节点却很空闲。

解决方案借鉴了缓存多副本的思路：当 SDK 检测到某个 key 的访问频率超过阈值，就自动在 key 后面拼接随机后缀，生成多个变形 key，让它们分散到不同节点。业务读取时随机选取其中一个变形 key 读取，如果 miss 再访问原 key 并从数据库加载，写回所有变形 key。这样一个热点 key 的访问量就被拆到多个节点上。关键点是变形 key 的 TTL 要略短于原 key，避免数据不一致窗口太长。

第三个问题是超大 value 打满网卡。一个业务方把一份 3MB 的业务配置塞进了缓存，这个 key 的读取频率还不低。尽管单次请求的响应时间正常，但网卡带宽被大量占满，其他正常请求排队，最终表现为接口整体 P99 延迟上升。排查时我用 tcpdump 抓包，发现内网流量远超预期，定位到是某个大 key 的问题。后续在缓存层强制限制 value 不能超过 256KB，超过则拒绝写入并告警；业务方如果确实需要缓存大对象，要先做压缩，压缩后仍然超限就拆成多段分别缓存，读取时在多节点并发拼装。这也算是一次教训：分布式缓存设计的粒度可以是 key，但性能监控的粒度必须细化到字节。

6.4 稳下来之后：核心参数与后续演进方向

系统稳定运行后，我总结了一套相对靠谱的核心参数：心跳周期 1 秒，超时阈值 5 秒，连续失败次数 5 次；路由环写时复制更新；本地缓存分片数量 16；虚拟节点数 160；SDK 请求超时 50 毫秒，重试次数不超过 1 次。这套参数经受过少量线上故障考验，核心思路就是“宁可慢半拍，绝不误杀”。

后续如果要继续演进，我可能会在三个方向补充：一是加入节点维度的监控上报，把每台机器的内存占用、淘汰次数、网络 RT 推送到监控系统，方便做容量规划；二是实现更平滑的权重调节，让新加入的节点通过调低虚拟节点数先承接少量流量，再逐步放开，避免一上线就承接全部路由压力；三是为跨机房容灾预留 Multi-Ring 互备方案，把每个机房独立哈希环的数据做异步汇总，机房故障时切换到另一套环。这些方向都是在对这套系统理解足够深之后才能明显看出价值的，直接看 Redis 源码反而不一定有这么直观的感受。

最后说一个个人体会：自研分布式缓存最大的收获不是“我写出了一个系统”，而是踩完这些坑之后，再回头看 Redis 的集群方案，每一处设计都能读懂它背后的妥协。比如它的 cluster 模式为什么要求客户端缓存槽位信息、为什么要借助 Gossip 传播节点状态、为什么要用异步迁移而不是同步搬迁，这些决策我之前只是背诵，现在是真正理解了。如果你也想走一遍这条路，建议先别碰网络通信和一致性哈希，先在你熟悉的语言里把一个本地并发缓存做到性能达标、TTL 准确、淘汰可控。单机这步走扎实，后面搭建分布式骨架时你会清楚很多。