你有没有过这种经历？早上赶着查资料，点开一个网页转圈转了十秒，差点以为手机坏了。可换个时间再试，又快得飞起。这背后，很可能就是分布式缓存策略在作怪。
为什么单机缓存不够用了？
以前网站用户少，把热点数据存在一台服务器内存里就够了。就像你家路由器只连三五台设备，网速稳得很。但现在动辄上百万访问量，一台机器扛不住，数据也放不下。更麻烦的是，不同地区的用户访问同一个服务，如果都往一个地方跑，延迟高不说，还容易堵。
分布式缓存是怎么工作的？
简单说，就是把缓存数据像快递仓库一样分布到多个节点上。比如你在广州下单，系统就近从深圳的缓存节点取数据；北京的用户就走天津节点。这样不仅速度快，还能防止单点挂掉全站瘫痪。
常见的实现方式是用一致性哈希算法来分配数据。假设我们有 3 台缓存服务器：
hash(key) % 3这个公式能把每个数据 key 映射到对应的机器上。但扩容时传统取模会大面积失效。一致性哈希通过构建虚拟环结构，让新增节点只影响部分数据迁移，大大减少抖动。
实际场景中的策略选择
电商大促前，商品详情页访问暴增。这时候可以采用“本地缓存 + 远程缓存”两级结构。Nginx 层先查本机内存，命中不了再去 Redis 集群拉取。像 Guava Cache 或 Caffeine 就适合做这一层的小型高速缓存。
同时设置合理的过期时间很重要。促销信息可能只有效一小时，缓存设成 55 分钟比较稳妥。而用户头像这类静态资源，可以缓存几天甚至更久。
别忘了缓存穿透和雪崩
有人恶意查不存在的商品 ID，每条请求都打到数据库，这就是缓存穿透。解决办法之一是用布隆过滤器提前拦截非法请求。
另一个风险是缓存雪崩——大量 key 同时过期，瞬间涌向数据库。可以通过错峰过期来缓解，比如给原本 60 分钟的 TTL 加上 1~5 分钟的随机偏移：
expire_time = 60 * 60 + random(60, 300)这样一来，压力就被平摊开了。
现在主流的方案基本都基于 Redis Cluster 或 Memcached 集群搭建。配合 Spring Cache 或自研中间件，能灵活控制哪些接口走缓存、哪些强制刷新。关键不是堆硬件，而是策略要跟业务节奏对上拍。