缓存不是加了就完事
很多团队一开始做系统优化，第一反应就是上缓存。Redis 装好，数据一丢，确实快了。可等到用户量上来，服务节点多了，问题就来了：为什么有些请求还是慢？为什么刚更新的数据在某些机器上看得到，在另一些机器上却看不到？
根源往往不在缓存本身，而在缓存策略和集群管理的配合上。缓存不是单点工具，它是分布式系统中的一环，必须和集群行为协同设计。
缓存策略要跟着业务走
比如电商详情页，商品信息变化不频繁，适合长时间缓存。但购物车、库存这类数据，实时性要求高，缓存过期时间就得压短，甚至主动失效。如果统一设成 10 分钟过期，用户可能看到的是十分钟前的库存，下单时才发现早已售罄。
再比如，有些接口查询条件复杂，直接缓存整个响应体可能浪费内存。这时候可以按 key 做细粒度控制，比如用 user:123:cart 和 product:456:stock 分开存储，更新时只清对应 key，不影响其他数据。
集群环境下缓存的坑
单机 Redis 简单直接，但扛不住流量。上集群后，数据被分片到多个节点，客户端请求打到哪个节点，直接影响命中率。如果没做好一致性哈希或使用了简单的取模分片，扩容时大量 key 失效，缓存雪崩风险陡增。
还有多实例部署的应用，每个实例都带本地缓存（比如用 Caffeine）。这时候问题来了：一个节点更新了数据库，本地缓存清了，其他节点的本地缓存还留着旧数据。用户请求被负载均衡打到不同机器，看到的结果就不一致。
怎么管好缓存集群
一是选对模式。Redis Cluster 自动分片，适合大规模场景；Codis 通过代理层实现分片，运维稍重但控制更灵活；如果读多写少，加几个只读副本也能缓解主节点压力。
二是加一层“协调机制”。比如用消息队列广播缓存失效指令，所有应用实例监听同一个 topic，收到 invalidate user:123 消息后同步清除本地缓存。虽然多了一次网络调用，但数据一致性有了保障。
<?xml version="1.0" encoding="UTF-8"?>
<cache-config>
<local-cache name="userCache" max-entries="10000" ttl="300000"/>
<redis-cluster nodes="192.168.1.10:6379,192.168.1.11:6379" />
<invalidation-topic name="cache-invalidate" broker="kafka://localhost:9092"/>
</cache-config>三是监控不能少。光看命中率不够，还得拆开看：哪个分片请求最多？哪些 key 频繁未命中？有没有大 key 把某个节点拖垮？把这些指标接进监控系统，才能及时发现异常。
别让缓存成为故障放大器
曾经有个系统，缓存集群挂了，所有请求直接打到数据库，瞬间把 DB 打满，整个服务瘫痪。后来加上了降级策略：当探测到 Redis 不可用，自动切换为短时本地缓存 + 限流，虽然数据稍旧，但核心功能还能用。
缓存本是为了提升性能，但如果管理不到位，反而会成为系统的脆弱点。合理的策略设计，加上对集群行为的充分理解，才能让它真正发挥价值。