从零实现分布式缓存：一致性哈希、主从复制与性能调优实战

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

先交代一个背景：我是在一个中等规模的微服务架构里维护一套共享数据服务的。业务端需要频繁读取一批实时性要求不高的配置数据和基础资料，这些数据存储在MySQL里，单表千万级，读多写少，业务高峰时QPS能冲到几千。我们最开始直接在服务里用本地Map做缓存，但很快发现几个问题：不同实例之间缓存不互通，一个服务有多个副本时，数据更新后A机器刷新了，B机器还在用旧值；本地缓存膨胀的时候没有全局视角，内存压力根本无从统一控制。后来引进了Redis，大部分场景确实解决了，但有些定制化需求始终没法很好满足——比如我们想要按业务前缀做缓存分片、想要批量预热、想要给某些Key单独设置不同的淘汰策略，这些在Redis里也能做到，但要做深度的统一封装和维护，成本其实不小。

所以就有了这个念头：如果自己实现一个分布式缓存系统，到底要解决哪些核心问题？我能不能在现有基础设施之上，用一套轻量的方案把这些业务诉求全部收敛起来？

所谓分布式缓存，本质就是由多个节点共同提供缓存服务，对外暴露统一读写接口，对内处理数据分布、节点通信、数据一致性、过期清理、高可用这些问题。一个最小的可用版本，其实并不需要做得像Redis那么庞大，但必须能跑通下面的链路：

• 客户端写入一个KV对，系统要根据Key计算出它应该由哪个节点负责存储。
• 节点之间要能互相发现，知道谁在线，谁掉了。
• 某个节点宕机后，它的数据要能通过其他机制恢复或重新分布，至少不能导致整个缓存服务不可用。

这篇文章就是我基于上述需求，从零实现的一个分布式缓存系统全过程记录。我会从核心结构设计、节点寻址、数据一致性、过期清理、高可用选主、监控调优这几个方面展开，期间穿插大量我在实际编码和压测中踩过的坑。如果你正准备入门分布式系统，或者在工作中需要为特定场景定制一套缓存方案，这篇文章应该能帮你省下不少摸索的时间。

2. 缓存系统的核心抽象与数据存储层设计

动手编码前，我先把整个系统抽象成了几个独立的模块：

• Storage：单机存储引擎，负责KV数据的保存、过期清理和内存淘汰。
• HashRing：一致性哈希环，负责Key到节点的映射。
• Gossip / Peer Discovery：节点发现与状态同步。
• Replication：主从复制，保障高可用。
• Client SDK：统一的读写入口，封装路由、重试、序列化逻辑。

这一章我先重点讲Storage的设计，因为它决定了整个缓存系统的性能底座。

2.1 存什么：KV基础结构的选型

实现的第一个版本我用了Go语言，存储层直接用sync.Map加自定义过期时间字段。当然这只是原型版本，后来压测发现sync.Map的并发读写性能在高竞争场景下并不理想，于是改成了分片锁结构。

go复制type CacheShard struct {
    sync.RWMutex
    items map[string]*Item
}

type Item struct {
    Value      []byte
    ExpireAt   int64
    CreateTime int64
    AccessTime int64
    Weight     int
}

type Cache struct {
    shards [256]*CacheShard
}

func NewCache() *Cache {
    c := &Cache{}
    for i := 0; i < 256; i++ {
        c.shards[i] = &CacheShard{
            items: make(map[string]*Item),
        }
    }
    return c
}

func (c *Cache) getShard(key string) *CacheShard {
    // 用哈希值取低8位作为分片索引
    h := fnv32(key)
    return c.shards[h&255]
}

这里分片数是256，实际上你可以在初始化时根据预估的并发度去调整。分片锁的思路很简单：不要所有读写都抢一把全局锁，而是把Key分散到多个互不干扰的桶里，每个桶各自加锁。这样并发冲突的概率会大幅下降，吞吐量基本可以线性扩展。

为什么不直接用map[string]*Item加全局sync.RWMutex？因为缓存系统的高频操作就是读，读多写少，全局锁即使分成读写锁，当写操作发生时所有读都会被阻塞。分片锁后，写一个Key只会锁住它所在的分片，其他分片的读写完全不受影响。

2.2 过期清理：惰性删除还是定期扫描

缓存系统不可避免要处理一个核心问题：过期Key什么时候被清理，怎么清理。

第一版我立刻想到用一个后台goroutine定期扫描所有Key，过期就删。但这个方案很快暴露了问题：当数据量到百万级别，全量扫描非常消耗CPU，而且扫描间隔内那些过期Key依然占据内存空间。

后来我改成了经典的“惰性删除 + 定期抽样删除”组合：

• 惰性删除：每次Get/Set操作时，先检查Key的ExpireAt是否小于当前时间，如果是就直接返回不存在。
• 定期抽样：后台定时任务每隔一段时间，从所有分片中随机抽取一批Key，删除其中过期的部分。

抽样删除的伪代码如下：

go复制func (c *Cache) CleanupExpired(percent int) {
    for _, shard := range c.shards {
        shard.Lock()
        now := time.Now().Unix()
        // 随机抽样，最多抽样100个Key
        for key, item := range shard.items {
            if item.ExpireAt > 0 && item.ExpireAt < now {
                delete(shard.items, key)
            }
        }
        shard.Unlock()
    }
}

实际生产中你不会对所有分片一次性全部扫描，可以随机选一部分分片扫描，更均匀地摊薄CPU消耗。抽样比例可以做成可配置参数，比如默认每100ms扫描1/10的分片，这样全量扫描完一轮大概需要1秒，控制在一个可接受的范围内。

注意：如果一个Key被设置了永久不过期（ExpireAt为0），那它不参与任何过期清理，只受内存淘汰机制约束。

2.3 内存淘汰：LRU还是LFU，这是个选择

缓存不是无限存的，当内存达到上限或者单节点可用内存不足时，需要主动淘汰一些数据。我给系统内置了三种策略：LRU（最近最少使用）、LFU（最不经常使用）、Random（随机淘汰）。默认用LRU。

LRU实现我复制了一份经典的双链表加哈希表结构。哈希表负责O(1)查找节点，双向链表负责维护访问顺序：每次访问一个Key，就把对应节点移动到链表头部；链表尾部就是最久未访问的节点，淘汰时直接删除尾部。

go复制type Node struct {
    key   string
    value []byte
    prev  *Node
    next  *Node
}

type LRU struct {
    head *Node
    tail *Node
    size int
}

但在实际运行中我遇到了一个值得注意的问题：当读取频率非常集中时，一个偶然而短暂的批量访问（比如热点活动刮起一阵查询高峰）可能会把一批使用频率不高但稳定的基础数据挤出缓存，导致这部分数据频繁回源数据库，反而拉高了整体延迟。

所以后来我在生产环境把关键数据改成了LFU。LFU的核心思想是统计Key的访问次数，淘汰访问次数最少的Key。实现上我简化成了“每个Key维护一个访问计数，定期对计数做衰减（防止老的访问次数永远不会淘汰）”。这比LRU在高频缓存场景下更符合访问倾斜的分布，不过实现复杂度略高，所以我把两种策略都留在代码里，初始化时按业务场景选择。

3. 数据分片与节点寻址：一致性哈希的实战选型

单节点缓存再快，也有内存上限，也有单点故障问题。分布式缓存必须解决“一个Key到底去哪台机器上找”的问题。这个环节我最初用的是取模路由，后来迁移到了一致性哈希。

3.1 为什么不直接用取模路由

取模路由很简单：假定你有N个缓存节点，把Key的哈希值对N取模，结果就是节点编号。在节点数固定、数据几乎不迁移的情况下，这个方法非常高效，甚至连哈希环都不用建。但它有一个致命问题：一旦节点数量变化（比如新增一台机器，或者一台机器宕机被剔除出集群），绝大多数Key的映射关系都会被改变，引发大规模的缓存失效和回源。

对于一个要求快速响应、回源成本高的业务场景，这种雪崩式失效是不能接受的。

3.2 一致性哈希的环形结构与虚拟节点

一致性哈希把整个哈希值空间组织成一个首尾相接的环，范围一般是0到2^32-1。每个真实节点会对应环上的多个虚拟节点，虚拟节点可以理解为真实节点在环上的多个影子，主要作用是为了解决数据分布不均的问题。

具体实现：

go复制type HashRing struct {
    nodes       map[string]*NodeInfo // 真实节点
    ring        []uint32             // 环上所有虚拟节点的哈希值，排序后存储
    virtualNum  int
}

func (h *HashRing) AddNode(id string) {
    for i := 0; i < h.virtualNum; i++ {
        vhash := crc32.ChecksumIEEE([]byte(fmt.Sprintf("%s-%d", id, i)))
        h.ring = append(h.ring, vhash)
    }
    sort.Slice(h.ring, func(i, j int) bool { return h.ring[i] < h.ring[j] })
}

func (h *HashRing) GetNode(key string) string {
    hash := crc32.ChecksumIEEE([]byte(key))
    idx := sort.Search(len(h.ring), func(i int) bool { return h.ring[i] >= hash })
    if idx == len(h.ring) {
        idx = 0
    }
    // 这里需要根据虚拟节点反查真实节点
    return h.ringToNode[h.ring[idx]]
}

这里有两个细节：

• 虚拟节点数量设置多少合适？我测试过从16到1024不等，最终选择了一个真实节点配置128个虚拟节点。太少会导致节点间数据量差异明显，比如只有3台机器时各节点负载可能差出20%以上；太多则会增加内存和排序开销，实际上对分布均匀性的提升在128之后会非常有限。
• crc32的碰撞率极低，不要用md5，太慢。

3.3 节点变化时的数据迁移策略

加入一致性哈希后，新增或删除一个节点时，只有该节点在环上对应的区间段需要迁移数据，其他区间不受影响。实现迁移时我给每个节点设计了一个region区间表，节点启动时会向配置中心或集群元数据节点拉取自己负责的区间段。

当某个节点离开时：

• 如果是正常退出：它把自己的数据分区转移给后继节点，然后通知集群更新路由表。
• 如果是异常宕机：路由表不会立刻把它的区间标记为不可用，而是会触发数据恢复流程，通常是被选为主节点的节点从持久化副本中取回数据，并临时接管这部分区间。

一致性哈希解决的是“数据应该放哪”的问题，但它不解决“宕机后数据从哪来”的问题。后者需要配合主从复制和持久化机制，下一章我会展开讲。

4. 缓存数据一致性：更新策略与失效场景

很多人以为分布式缓存最难的是怎么存和怎么找，其实真正难的是数据一致性问题。生产者写入新值后，缓存里的旧数据什么时候更新、怎么更新，这是最容易出错、也最容易引发线上事故的地方。

4.1 常见更新策略对比：Cache Aside, Read/Write Through, Write Behind

Cache Aside（旁路缓存）是最常用的策略，也是我们系统默认的策略。它的核心流程是：

• 读请求：先查缓存，命中直接返回；不命中，回查数据库，放入缓存，返回。
• 写请求：先更新数据库，再删除缓存（或者更新缓存）。

这里有一个关键点：为什么写的时候先更新数据库，而不是先更新缓存？因为如果先写缓存、数据库更新失败，缓存里就是新值而数据库是旧值；下一次读请求就会命中新值，但业务上这个新值是不可靠的。反过来先写数据库再删缓存，即使删缓存失败导致短暂读到旧值，下次写操作也会再次触发删除，最终可以收敛到新值。

Read/Through和Write Behind主要用于需要把缓存作为主要存储入口的场景，比如数据库写入成本很高或者希望批量合并写入。但Write Behind有丢失数据的风险，因为数据先落在缓存，再异步刷回数据库，如果缓存宕机，这段时间的写入就没了。所以常规业务里我不太推荐Write Behind作为默认方案。

4.2 双删与延迟双删：处理并发写下的脏数据

缓存跟数据库一致性最容易出问题的场景是并发写：A请求更新数据库为10，B请求更新数据库为20，但A先删了缓存，B后删了缓存，最终缓存可能是旧值。

我加了一个简单的处理，就是延迟双删：

1. 先删除缓存。
2. 更新数据库。
3. 休眠一小段时间（比如500ms）。
4. 再次删除缓存。

延迟双删的原理是：在更新数据库期间如果有读请求把旧值重新放进了缓存，第二次删除会把这个旧值再清一次，给后续读请求一个生成新值的机会。虽然不能100%避免极端情况，但在绝大多数业务场景下已经足够。

4.3 缓存失效风暴：惊群效应与时间抖动

说到缓存失效，有一个特别容易踩的坑：大量Key设置了相同的过期时间，在同一时刻集体失效。如果这些Key对应的都是数据库热点数据，缓存失效瞬间会有大量读请求同时打到数据库，让数据库的QPS瞬间冲到峰值，这就是所谓的缓存失效风暴，也叫惊群效应。

我们的处理方式有两个层面：

• 设计阶段：给每个Key的过期时间加上一个随机偏移量。比如基础过期时间是10分钟，但实际值会加一个rand.Intn(60)秒。这样一来，原本同一时刻集体过期的Key，会分散到接下来的一分钟里陆续过期。
• 读路径：对不命中的情况加分布式锁或单机锁，保证同一时刻只有一个请求去回源数据库，其他请求等待锁释放后直接读回填的缓存。这个方案我后面细说。

分布式锁的实现，在我们的系统里是基于独立注册中心（不是缓存自身）的临时节点完成的。因为如果基于缓存本身做锁，缓存宕机时锁也就失效了，容易造成先回源后无缓存可用的死循环。

5. 高可用与节点管理：从主从复制到选主

缓存系统要做到高可用，光有数据分布还不够。单个节点宕机后，它的数据要能被其他节点接管，同时集群要能感知节点离线并自动调整路由。

5.1 主从复制的实现细节

我给每个数据分片设置了一个主节点和若干个从节点。写入操作只接受主节点，主节点接收写入后，立即写自己的本地存储和操作日志（WAL），然后异步把日志推送给所有从节点。从节点回放日志后更新自己的内存数据。

这里有一个关键权衡：如果要求强一致，主节点要等待所有从节点确认写入后才能返回；但这会显著提高写入延迟，在分布式缓存这种追求高性能的场景下并不划算。我们的选择是主节点写入本地成功后立即返回，从节点的复制是异步进行的。代价是：如果主节点在推送日志前挂掉，最近一小段写入可能丢失。对于缓存系统来说，这个窗口期通常可以接受，因为缓存本身就能从原始数据源回源重建。

WAL日志的设计其实不难，核心就是“先写日志再改内存”，这样即使进程崩溃，重启后也能通过回放日志恢复内存状态。

5.2 选主机制：心跳与最简版Raft

最初我直接用注册中心的临时节点来做主节点抢占，节点上线时去注册中心抢一个带有效期的锁，抢到了就当主节点。这个方案简单，但面临一个问题：如果主节点只是网络抖动，注册中心锁过期释放，从节点抢到锁成为新主，而旧主进程其实还活着，就会产生双主问题，也就是脑裂。

后来在需要强一致的配置变更场景我实现了简化版的Raft选主逻辑：

• 所有节点维护一个term编号。
• 候选者发起投票请求，获得多数节点同意后成为主。
• 主节点定期向从节点发送心跳，从节点在超时时间内收不到心跳就会发起新一轮选主。

Raft解决脑裂的关键在于：两个节点同时认为自己可能是主时，只有拿到多数投票的节点才能成为主，另一个节点会失败。这样就保证了只有一个主节点能够决定日志提交。

提示：如果本身没有很强的分布式一致性诉求，我不建议一开始就搞完整Raft。先跑通临时节点抢占方案，等真正遇到脑裂问题再升级到Raft也不迟，否则前期开发量会翻好几倍。

5.3 故障恢复与数据重建

主节点宕机后，新主节点会根据WAL日志恢复数据。为了保证恢复效率，我采用了“定期快照 + 增量WAL”的方式：

• 节点每10分钟生成一个全量内存快照文件，保存到本地磁盘。
• WAL里只保留最后一次快照之后的新操作记录。
• 恢复时，先加载快照，再回放增量日志。

这种方式下，正常节点重建数据的时间基本可以控制在几十毫秒级别，因为快照的加载方式是直接反序列化成HashMap，不需要逐条执行操作。

对于从节点接管主节点的场景，数据恢复路径更简单：注册中心通知路由表更新，客户端将这段时间内落到宕机节点的读写请求，切换到该分片的新主节点，新主节点用快照加WAL重建数据。因为缓存本身允许短暂的不命中，所以即使重建过程中少量数据缺失，也不会引发大问题，最多是多回源几次数据库。

6. 序列化、协议与客户端SDK的工程化细节

缓存系统内部的存储、复制、路由都设计完了，但对外提供的接口还是必须考虑工程化：客户端用什么协议通信，数据用什么格式序列化，网络异常时怎么重试，这些细节往往决定了系统好不好用。

6.1 自定义二进制协议还是直接HTTP

第一版我用了HTTP的JSON接口，开发快，调试方便。但压测后发现问题集中在两点：JSON序列化开销太大，同样的数据用JSON传输比二进制大概多出30%-50%的字节量；HTTP连接每次都要走完整的HTTP头，在高并发小数据量的场景下非常浪费。

后来我换成了自定义的二进制协议。协议格式大致是：

text复制+--------+--------+--------+--------+
| Magic  | OpCode | KeyLen | Payload|
| 1 byte | 1 byte | 4 byte | ...    |
+--------+--------+--------+--------+

• Magic字段用于校验包的有效性，固定值0xCE。
• OpCode表示操作类型：1=Get，2=Set，3=Delete，4=Expire。
• KeyLen表示Key的长度，Payload依次包含Key和Value（Value长度可以从总包长减去头部计算）。

序列化方面，对于普通字符串直接存原始字节，对于结构体数据我默认用Msgpack而非JSON。Msgpack的格式紧凑、序列化速度快、跨语言支持也不错，非常适合缓存这类对性能和体积都敏感的场景。

这里的实际收益：在100万次Set操作压测里，二进制协议加Msgpack的吞吐比JSON加HTTP高出约2.5倍，平均延迟从约1.2ms降到了0.5ms左右。

6.2 客户端SDK的路由与重试策略

客户端SDK是整个分布式缓存系统的门面。一个合格的SDK至少要做好三件事：

1. 从注册中心拉取集群节点列表，并构建一致性哈希环，所有读写请求走本地路由，不再每次询问注册中心。
2. 对路由目标节点发起请求时，如果节点不可用，需要根据策略重试到其他节点，但重试次数必须有限制，绝不能无限重试。
3. 本地缓存一份路由表的快照，当注册中心暂时不可用时，用旧路由表也能完成读写，只是会退化到部分可用。

具体重试策略我设计成了两级：

• 如果请求目标是主节点且失败，会尝试从节点读（读请求允许从节点处理）。但写请求不会自动转移，因为写转移可能导致数据复制冲突。写请求失败后直接返回错误，由业务层决定是否回源数据库。
• 如果连续多个节点都失败，SDK会触发一次路由表刷新，强制同步注册中心的最新节点列表。这样避免了因为本地路由表陈旧导致的持续请求失败。

6.3 连接管理：长连接池与空闲清理

分布式缓存的客户端经常要跟多个节点通信。简单做法是每次请求新建一个TCP连接，但TCP握手和挥手在这种高QPS场景下会带来大量的系统调用和延迟。我们维护了一个连接池，按节点维度分别存储，空闲连接超过30秒自动关闭，新建连接时设置最长空闲时间避免连接泄漏。

内存占用方面，每个连接默认缓冲区设置为8KB，高并发场景下缓冲区可以调整到16KB或32KB，但不要太大，否则连接多了内存会暴涨。这个细节我在压测时踩过坑，原本每个连接设置了64KB的读写缓冲，连接数到2000后内存直接吃掉了128MB，对缓存服务本身来说是不可接受的。

7. 压测结果与踩坑记录：几个真实的性能坑

写完核心功能后，我搭建了三节点集群，用单机客户端做了压测。以下是真实压测数据和几个印象深刻的坑。

7.1 压测环境与数据

• 三台8C8G的虚拟机，网络延迟小于0.1ms。
• 每台节点物理上使用最多4GB内存作为缓存。
• 客户端压测工具是自研的，模拟100个并发goroutine，每个goroutine随机执行Get或Set操作，比例7:3。
• 数据量：Key长度为16字节，Value长度为128字节，总共预写入100万条。

压测结果：

这个结果对一次自研系统来说中规中矩，也在我们预期范围内。如果要有更高性能，可以做进一步优化，比如批量数据更新、批量读取、减少内存拷贝等，但对于我们要支撑的业务量，这个性能已经足够了。

7.2 坑一：高并发下锁竞争还是打满了CPU

最开始压测的时候，我只有分片锁，但分片数设的是64。128并发压测时CPU直接跑到95%以上，但QPS只有不到一万。用profiler一分析，发现大量goroutine都在等待sync.RWMutex的写锁，即使不同Key在不同分片上，写入频率一高，同一分片内的写请求还是会严重排队。

解决方式很直观：把分片数从64提升到512，同时尽量让相同前缀的Key落在同一分片里，减少跨分片操作。这一改，QPS直接翻了一倍多，CPU占用反而降到了65%。所以分片数量一定要根据并发度和Key分布来调整，不是随便选一个数就行。

7.3 坑二：从节点复制延迟导致的数据偏移

我之前把复制设计成纯异步的，没有做任何延迟监控。压测时发现一个现象：高并发写主节点的情况下，从节点复制日志有延迟波动，延迟从几毫秒跳到几百毫秒。

后来排查发现，延迟主要出现在两个地方：一是日志推送goroutine少，当批次数据写入量很大时，单goroutine发送不过来；二是从节点回放日志时，跟正常的读请求抢锁，导致回放阻塞。

我的改进方案：

• 每个从节点对应一个独立的复制通道，通道内批量打包日志发送，减少小包发送的频率。
• 从节点的日志回放走“无锁批量写入”路径，即回放时把一批更新合并成一次大事务，锁粒度从单Key升级到整个分片。

这两个改动完成后，复制的延迟基本降到了10ms以内。

7.4 坑三：内存占用比预估高了很多

初版上线后，我观察集群内存，发现每台机器的内存占用比预期多了差不多30%。查了一圈，最根本的原因是Go的map[string]*Item中每个Item都持有[]byte，而[]byte有自身的对象头和切片头，加上Map内部也会有额外的指针开销，实际内存远大于纯数据大小。

对策是给存储层增加了一层序列化压缩：Value在写入前进行轻量级压缩（使用Snappy，压缩率虽不高但压缩速度快），并在Item里只保留压缩后的字节数组。测试下来，100万条128字节的Value，整体内存占用降低了20%左右。对于更大的Value，压缩收益会更明显。

8. 缓存的监控与性能调优方向

如果缓存系统只是实现完就上线，没有配套的监控和调优手段，后期的稳定性完全靠运气。我从一开始就为系统埋好了埋点：

8.1 关键指标：命中率、延迟分布、淘汰次数、复制延迟

监控体系里，我认为以下五个指标是最核心的：

• 命中率：命中次数 /（命中次数 + 未命中次数）。命中率一旦下降，通常意味着过期时间设置不合理、淘汰策略太激进或数据分布不均。
• P99延迟：保证绝大多数请求的质量，如果P99比平均值高出一个数量级，说明有长尾延迟，多半是GC停顿或网络拥塞。
• 内存淘汰次数：记录LRU/LFU淘汰的Key数量，一旦飙升，说明内存容量已经逼近上限。
• 复制延迟：主从节点之间日志回放的延迟，如果长期过高，可能引发读从节点数据滞后的问题。
• 路由表更新频率：频繁更新说明集群节点不稳定，往往是网络抖动或节点心跳过期导致。

具体实现上，我用Prometheus的client库暴露指标接口，Grafana做可视化看板。这里插一句：在Go生态里，用Prometheus客户端几乎是最省事的方案，不用自己写监控存储和查询，接入量也很成熟。

每个指标尽量打上节点ID和分片ID的标签，方便排查具体业务分片的问题。

8.2 常见性能瓶颈与优化方法

从理论到实践，分布式缓存的性能瓶颈往往集中在这几个点：

• 网络IO：使用长连接连接池，尽量合并小包，批量读取缓存。
• 内存泄漏：Go语言一般不容易泄漏，但要注意[]byte切片拷贝时可能保留底层大数组的引用。比如你从一个大数组里截取一小段，只要这个小切片还被引用，整个大数组都无法被GC回收。
• GC延迟：当节点内存很大（比如几十GB）时，GC停顿会变长。解决方案包括减少指针数量（用[][]byte扁平存储替代map[string][]byte），或将对象分配在堆外的内存池中。
• 路由热点：即使一致性哈希均衡，某个Key如果被大量请求访问，依然会出现单点热点。针对热点Key，可以在客户端本地做一级短TTL缓存，把压力从分布式缓存层剥离。

8.3 热点Key与本地缓存层的结合

热点Key是我们业务中非常典型的问题——某些配置项或者爆款商品信息被大量用户同时读取，虽然分布式缓存已经能抗住，但单节点QPS还是会飙到几万，网卡和CPU都承受压力。

我的处理方式：在客户端SDK内部加了一层可配置的本地缓存，只对标记为hot的Key生效，TTL通常是5-15秒。本地缓存命中后，根本不需要走网络请求，客户端直接返回，这样热点Key的读压力会被大幅削减。代价是本地缓存与分布式缓存之间可能存在最多几秒的短暂不一致。对于我们的业务场景，这个不一致完全在可接受范围内。

实现上需要注意：本地缓存一定要控制总条数和最大内存，否则每个服务进程都会多一份热点数据的复制品，大量微服务加起来浪费很可观。我给本地缓存默认设2000条、内存上限64MB，并启用了LRU淘汰。

9. 从0到1的分布式缓存系统演进路线

如果你是第一次接触分布式缓存，或者正在考虑选型，我建议你不要直接复刻我上面所有设计，而是按阶段逐步迭代。

第一阶段：单机缓存。实现存储、过期、淘汰、序列化、客户端接口。把基本的读写链路跑通，性能压测达到单机上万的QPS。

第二阶段：分布式路由。引入一致性哈希和节点发现，把写操作分散到多个节点，实现跨节点读写。注意观察数据是否均匀分布，路由是否稳定。

第三阶段：高可用与数据恢复。加入主从复制、快照和WAL日志，实现节点故障时的自动切换和数据重建。这一步是分布式缓存系统最关键的分水岭。

第四阶段：监控、调优与运维自动化。增加Prometheus监控、日志、告警，以及可视化的控制台或命令行工具，让系统可以“看得见、排得清”。

每一阶段我都建议做一次完整的压测和故障演练，不要等到全部都实现了再一次性压测。否则一旦发现基础架构的某处缺陷，改动成本会急剧上升。

10. 经验总结：从实际项目中获得的几点忠告

写到这里，分享几个我在整个实现过程中总结出来、觉得对后来人最有价值的经验：

第一个经验是不要一开始就追求“分布式”。先把单机缓存做到极致，再用一致性哈希往外扩展，会省掉大量重构成本。我们第一版单机缓存跑通花了一周，但第二版加一致性哈希只花了两天，因为底层存储和接口都已经稳定了。

第二个经验是标准化的存储协议重于花哨的算法。很多人在设计缓存系统时花了大量精力研究哈希算法和选主协议，却忽略了三件基础但关键的事：异常时怎么办、连接怎么管理、字段怎么序列化。实际上，我们的系统在线上运行后，出现最多的故障不是路由错误，也不是数据不一致，而是连接泄漏和序列化版本没对齐。

第三个经验是监控的数据一定要留足时间。我建议至少保存30天的QPS、延迟、命中率等核心指标。因为有些性能问题不是立刻暴露的，而是缓慢退化——比如内存缓慢增长、延迟逐渐变高，如果没有历史数据做对比，你不会意识到系统在恶化。

最后，我强烈建议你在实现自己的缓存系统时，完整地读一遍Redis的源码中关于内存管理和过期删除的部分。Redis作为业内最经典的分布式缓存实现，它的很多设计思路非常值得借鉴，但你不要试图完全复刻它，而是从里面提取适合你业务场景的关键机制。我们用到的分片锁、快照加载、惰性删除加定期扫描，都明显能看到Redis设计思路的影子。在我自己动手实现了这套系统后，再看Redis的设计，理解完全不一样了——纸上得来终觉浅，亲手造过一遍轮子，才算真正理解了轮子。