分布式缓存管理的本质是通过将热点数据分散存储在多节点内存中来降低数据库读写压力，其核心难点在于平衡数据一致性、高可用性与系统性能。
咱们给系统加缓存，就像是给高速公路修了立体交通枢纽，数据库是底层的地面道路，车一多就堵死，缓存就是高架桥，让大部分车流直接从天上走，不跟地面的红绿灯较劲，但高架桥怎么修、怎么管,学问大得很。
核心概念与业务场景
缓存穿透与击穿的防护策略
咱们做分布式缓存管理，最怕的不是缓存没命中,而是有人故意搞破坏或者业务逻辑有漏洞。
- 缓存穿透：黑客一直拿一个数据库里压根不存在的ID去查，缓存里没有，只能去查数据库，数据库也没有，每次都打到底层，解决这事儿，业内通用做法是上布隆过滤器，把所有可能存在的Key提前映射到位，请求来了先过一遍过滤器，不存在直接挡回去，或者把查到的空结果也缓存起来，设个短点儿的过期时间,比如5分钟。
- 缓存击穿：某个爆款商品突然过期了，瞬间几万个请求同时打过来查这个Key，直接把数据库压垮，这时候得用互斥锁，第一个查不到缓存的请求去查数据库并加锁，查完写回缓存再释放锁，其他请求要么等锁，要么直接返回旧数据，在Redis里，咱们可以用
SETNX（Set if Not eXists）命令来实现这个锁，命令类似SET lock_key unique_value NX PX 10000,拿不到锁的请求就休眠重试。
高并发场景下分布式缓存选型与实战
说到选型，很多新手都会纠结,咱们拿最典型的两个组件来比划比划。
Redis和Memcached哪个好：选型对比
这俩老伙计在圈子里用了好多年了，行业共识认为，单纯论极端的纯内存读写性能，Memcached由于是单线程且只做KV，在特定场景下会略快,但差距微乎其微。
| 特性 | Redis | Memcached |
|---|---|---|
| 数据结构 | 支持字符串、哈希、列表、集合等 | 仅支持字符串 |
| 持久化 | 支持RDB和AOF | 不支持，重启丢数据 |
| 集群模式 | 原生支持分片集群 | 需要客户端一致性哈希 |
| 单机QPS | 约10万 | 约10万 |
| 内存利用率 | 较高（支持压缩） | 极高（预分配内存池） |
多数情况下，咱们现在的业务复杂度高，需要存个列表、搞个排行榜啥的，Redis绝对是首选，如果是纯粹的、简单的KV缓存，且对内存利用率要求极高,Memcached依然能打。
Redis集群搭建实操路径
真正在生产环境搞Redis，不能单点裸奔，得上集群，咱们以Redis Cluster为例,走一遍基本操作：
- 准备至少6个节点（3主3从）。
- 修改
redis.conf配置：开启cluster-enabled yes，设置cluster-config-file nodes.conf，配置cluster-node-timeout 5000。 - 启动各个节点的Redis服务：
redis-server /path/to/redis.conf。 - 使用自带工具组建集群：
redis-cli --cluster create 192.168.1.1:7000 192.168.1.2:7000 ... --cluster-replicas 1。
这套走下来，一个高可用的分布式缓存集群就算立起来了，这里要注意，Redis Cluster采用哈希槽来分配数据，总共16384个槽位,集群会自动把这些槽位分配到不同的主节点上。
分布式缓存如何保证数据一致性
缓存和数据库是两套系统，只要涉及双写，就必然有一致性问题，这就像你左手拿个苹果，右手拿个橘子，想同时放进口袋,总有个先后顺序。
常见缓存读写策略
- Cache Aside（旁路缓存）：这是最常用的策略，读的时候，先读缓存，命中就返回；没命中就读数据库，然后写入缓存，更新的时候，先更新数据库，再删除缓存，为啥是删除而不是更新缓存？因为并发更新时，容易产生数据错乱，直接删掉，下次读的时候再重建,简单粗暴且安全。
- 延迟双删策略：为了防止在更新数据库的瞬间，有旧请求把旧数据又写回缓存，咱们通常采用延迟双删，先删缓存，再更新数据库，休眠个几百毫秒（比如1秒），再删一次缓存,这1秒就是等那些并发读旧数据的请求执行完。
业内专家指出，没有任何一种缓存一致性方案是绝对完美的，最终一致还是强一致，取决于你的业务能容忍多长时间的脏数据，如果是交易类的核心链路，建议直接走数据库，别用缓存；如果是商品展示、评论列表这种,延迟双删完全够用。
缓存与数据库双写不一致的实战排查
如果你发现数据总是对不上,按这个路径排查：
- 检查是不是更新数据库后没删缓存。
- 检查删除缓存操作是否失败（网络抖动导致删除未成功，可以引入消息队列重试）。
- 检查是不是读操作在写操作之前发生,导致旧数据被读回缓存。
分布式缓存雪崩怎么解决及预防策略
雪崩这词儿听着吓人，实际情况更吓人，大面积缓存同一个时间点失效，或者缓存集群整体宕机，所有的读请求全部像洪水一样涌向数据库,数据库瞬间就爆缸了。
集群高可用与限流降级
要防住雪崩,得从根子上找原因。
- 随机过期时间：给缓存过期时间加个随机值，比如基础过期时间是1小时，加上个0到5分钟的随机数,避免大批Key同时集体归西。
- 多级缓存架构：别把鸡蛋放在一个篮子里，本地缓存（如Caffeine）作为第一层，分布式缓存（Redis）作为第二层，Redis挂了,本地缓存还能顶一阵子。
- 限流降级机制：在应用层配置Sentinel或Hystrix，当数据库连接池快满时，直接拒绝部分请求或者返回默认降级页面,保住数据库的命。
Sentinel限流规则配置实操
咱们以Sentinel为例,给核心接口配个降级规则：
- 在项目中引入
sentinel-core和sentinel-annotation-aspectj依赖。 -
在接口方法上打上
@SentinelResource注解。 - 配置流控规则：设置QPS阈值为数据库能承受的极限值（比如单机2000）。
- 配置降级规则：当接口RT（响应时间）超过50ms的比例达到一定阈值，触发降级，直接返回
fallback方法里的兜底数据。
监控与告警配置
平时不管好，出事就抓瞎,咱们得盯紧几个核心指标：
- 内存使用率：
used_memory_rss,别让内存满了被操作系统OOM杀掉。 - 缓存命中率：通过
info stats看keyspace_hits和keyspace_misses，命中率如果突然下降,肯定有问题。 - 连接数：
connected_clients，如果客户端没做好连接池,连接数飙升会拖垮Redis。 - 慢查询日志：配置
slowlog-log-slower-than 10000（记录执行超过10毫秒的命令）,定期排查。
搞定分布式缓存管理，就是要在性能和架构复杂度之间找平衡，把穿透、雪崩、一致性问题提前在架构设计阶段想透彻,多实战多踩坑才能形成肌肉记忆。
分布式缓存管理常见问题解答
Q1: 分布式缓存和本地缓存有什么本质区别？
本地缓存存在于应用进程内，读写极快但容量受限于单机内存，且多节点间数据不共享，分布式缓存独立于应用部署，通过网络访问，容量大且支持多节点共享数据,适合存放大批热点数据。
Q2: Redis集群中某个节点宕机了怎么办？
Redis Cluster采用Gossip协议进行节点通信，当某个主节点宕机，它的从节点会在超时时间后被自动选举为主节点，继续提供服务，如果该节点没有从节点，整个集群会进入下线状态,相关Hash槽的数据将无法读写。
Q3: 大Key和热Key问题怎么处理？
大Key指单个Key的Value过大，容易造成网络阻塞，处理方法是拆分数据结构或单独存储，热Key指访问频率极高的Key，容易造成单节点压力过大，处理方法是将Value多份冗余存储在不同Key中，读取时随机访问,分散压力。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/529604.html
