Redis是目前应用最广泛的分布式缓存系统，它通过内存存储和丰富的数据结构，为高并发应用提供了毫秒级的响应能力，是解决数据库性能瓶颈的关键组件。
Redis分布式缓存和本地缓存，到底有什么区别？
很多团队在选型时都会纠结到底用本地缓存还是Redis，本地缓存常见的有Ehcache、Caffeine、Guava Cache，它们和Redis虽然都做缓存,但本质差异很大。
本地缓存的局限性
- 数据存储在各节点内存中，节点之间无法共享数据,导致缓存不统一。
- 受限于单机内存容量，难以支撑大规模数据缓存,扩展成本高。
- 重启服务后缓存数据全部丢失,不具备持久化能力。
- 无法跨进程或跨语言共享,微服务环境下每个服务实例必须各自维护一份缓存。
Redis的天然优势
- 作为独立服务部署，所有应用实例共享同一份缓存,保证数据一致性。
- 支持集群模式,通过分片可扩展至数百GB乃至TB级别内存。
- 内置RDB和AOF两种持久化机制,重启后数据可恢复。
- 单机读QPS普遍在10万以上,集群模式下线性扩展。
从实际场景看，单机应用或对一致性要求不高的场景，本地缓存确实轻量够用，但一旦涉及分布式系统、多个服务实例共享数据、或者需要高可用与持久化，Redis是更合适的选择，行业共识认为，在多数互联网企业的生产环境中,Redis已经取代了传统本地缓存作为主缓存层。
如何解决Redis缓存穿透与雪崩？方案对比
缓存穿透和雪崩是Redis使用中最常见的两类问题,处理不好会直接拖垮后端数据库。
缓存穿透的三种解决方案对比
- 布隆过滤器：在请求到达Redis之前，先通过布隆过滤器判断Key是否存在，如果不存在，直接拒绝，避免无效查询穿透到数据库，布隆过滤器占用内存极小，但存在一定误判率，不过不影响业务，因为误判只会导致少量请求打到数据库,不会造成大问题。
- 缓存空对象：当查询结果为空时，仍然将空值写入Redis并设置较短的过期时间（如30秒），这样下次同样的请求直接从缓存返回空，避免反复查询数据库，缺点是可能占用额外缓存空间,且无法防止大量随机Key攻击。
- 接口限流与参数校验：对非法参数（如ID为负数或超大值）直接返回错误，减少恶意请求进入缓存层，通常配合前两种方案一起使用,形成多层防护。
缓存雪崩的预防策略
缓存雪崩指大量缓存集中过期，或Redis实例宕机,导致请求全部转向数据库。
- 过期时间加随机值：在设置缓存时长时，在基础过期时间上增加一个随机数（如1-5分钟）,避免大量Key在同一时刻失效。
- 多级缓存：本地缓存作一级，Redis作二级，Redis挂掉后本地缓存依然能扛住部分流量,为恢复争取时间。
- 限流与降级：当监测到数据库压力过大时，通过Sentinel或Hystrix等组件对请求进行限流,直接返回兜底数据或友好提示。
缓存击穿的处理方案
缓存击穿指热点Key在过期瞬间被大量并发请求访问,导致数据库压力飙升。
- 互斥锁：只允许一个线程去重建缓存，其他线程等待，通常借助Redis分布式锁实现，保证只有一个请求访问数据库,其余等待锁释放后直接从缓存读取。
- 热点数据永不过期：对极端热点数据不设置过期时间，而是通过后台异步任务定期更新缓存，这样从根本上避免了击穿可能,但需要额外维护更新逻辑。
Redis分布式锁实现原理与实战
分布式锁是Redis在分布式协调场景下的经典应用,常用于控制并发访问共享资源。
基于SET NX EX的简单实现
- 使用
SET key value NX EX 30，NX表示键不存在时才设置，EX设置过期时间（秒）,这样只有一个客户端能成功。 - 获得锁后执行业务逻辑，最后通过
DEL key释放锁。 - 必须设置过期时间，防止客户端崩溃导致死锁，过期时间要大于业务执行时间,否则锁提前释放会造成并发问题。
原子性释放锁的Lua脚本
简单DEL释放锁存在风险：如果客户端A的锁过期，但业务还没完成，客户端B获取了锁，此时A执行完直接DEL会删除B的锁,所以释放锁时要检查value是否是自己设置的。
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
通过Lua脚本保证比较和删除的原子性,避免误删。
成熟方案：Redisson
Redisson封装了分布式锁的自动续期机制，默认每10秒检查一次，如果业务未完成会自动延长锁的超时时间，防止锁在执行中途过期，同时支持Redlock算法，在多个Redis节点上获取锁,解决单点故障问题。
业内专家指出，在大多数业务场景下，使用Redisson的RLock即可满足需求，无需自行实现复杂逻辑,只有在极端一致性要求下才需要引入Zookeeper或Etcd。
Redis集群部署方案对比与成本分析
选择集群架构直接影响系统的可用性、扩展性以及运维成本。
三种集群架构的核心差异
| 架构模式 | 数据分布 | 故障转移 | 扩展性 | 一致性保证 |
|---|---|---|---|---|
| 主从复制 | 每个主节点同步到从节点，数据不分片 | 需手动或借助哨兵切换 | 读扩展，写瓶颈仍为主节点 | 主从异步复制，可能丢失少量数据 |
| 哨兵模式 | 在主从基础上增加哨兵监控和自动切换 | 自动选举新主节点 | 不支持写扩展，读可扩展 | 异步复制，主从切换期间可能丢失数据 |
| Redis Cluster | 数据分片到16384个槽，每个节点负责部分槽 | 自动故障迁移，槽重新分配 | 水平扩展，增加节点自动迁移槽 | 最终一致性，网络分区时可能丢失数据 |
部署成本需要考虑哪些
- 硬件成本：Redis对内存敏感，大容量实例需要高内存服务器，同时CPU和网络带宽也影响性能，集群模式下节点越多,网络开销越大。
- 运维成本：自建集群需要搭建监控、日志、备份、扩容流程，哨兵和Cluster配置复杂,运维人员需要掌握底层原理。
- 云服务成本：国内主流云厂商均提供Redis服务，按规格和容量计费，大多数情况下，使用云Redis可以省去运维成本，但实例单价高于自建，在杭州、上海等地域，Redis实例的带宽费用可能因机房不同有所差异,需要根据实际流量评估。
从实际部署来看，中小团队优先选择云Redis，大厂或对成本敏感的企业会选择自建Cluster，两种方案各有适用场景,没有绝对优劣。
Redis分布式缓存最佳实践总结
- 缓存策略：读多写少且数据变化不频繁的场景适合缓存,频繁更新的数据要谨慎设置过期时间。
- 淘汰策略：内存满时，lru（最近最少使用）是默认策略，也可以根据业务选择allkeys-lru或volatile-lru。
- 数据一致性：先更新数据库再删除缓存，配合延迟双删策略,最大程度保证最终一致性。
- 监控与告警：定期检查Redis内存使用率、命中率、慢查询,及时调整参数。
关于Redis分布式缓存的常见问题
Q1：Redis分布式缓存和本地缓存能一起用吗？
可以，这就是多级缓存策略，本地缓存（如Caffeine）作为一级缓存，响应最快；Redis作为二级缓存，提供共享和持久化，当本地缓存未命中时，查询Redis，再落盘数据库，这样既能减少网络开销，又能保证数据一致性，但需要注意本地缓存的数据更新问题，通常通过Redis的Pub/Sub或消息队列推送变更通知。
Q2：Redis缓存穿透和缓存击穿有什么区别？
穿透针对的是请求不存在的数据，击穿针对的是热点数据缓存失效瞬间的高并发，穿透的解决方案是使用布隆过滤器或缓存空对象，从源头拦截无效请求；击穿的解决方案是使用分布式锁或永不过期策略，控制重建缓存的并发，两者核心区别在于请求的数据是否存在,以及并发模型不同。
Q3：Redis分布式锁会失效吗？
在极端情况下会失效，Redis主节点获得锁后未同步到从节点就宕机，从节点升级为主节点，此时其他客户端可以重新获取锁，导致锁失效，Redlock算法通过在多个独立节点获取锁来降低这种风险，但无法达到100%的强一致性，如果业务对锁的可靠性要求极高,建议使用Zookeeper或Etcd等强一致协调服务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/558738.html
