分布式缓存Redis是应对高并发、低延迟场景的核心基础设施，它能将数据存储在内存中，以极快的速度响应请求，从而大幅减轻后端数据库的压力，并提升系统吞吐量。
什么场景下需要引入Redis分布式缓存
很多团队在系统初期，单体应用加一个关系型数据库就能跑得挺顺，但中大型网站或高并发业务会发现，随着用户量和数据量增长，数据库的响应时间会明显变慢，尤其是在秒杀、热点新闻、排行榜这类场景下,直接读库的代价太高。
缓存穿透、缓存击穿与缓存雪崩
这三个概念是分布式缓存绕不开的坎。缓存穿透指查询一个不存在的数据，由于缓存中没有，请求直接打到数据库，如果恶意攻击，数据库会瞬间被压垮。缓存击穿指一个热点key在失效的瞬间，大量并发请求同时涌入数据库。缓存雪崩是大量key同时失效，或者缓存节点宕机,导致数据库压力陡增。
- 缓存穿透的解决方案：布隆过滤器、缓存空对象（设置较短的过期时间）
- 缓存击穿的解决方案：互斥锁（如Redis的SETNX）、逻辑过期
- 缓存雪崩的解决方案：过期时间加随机数、缓存集群高可用、降级限流
读写分离与数据一致性
Redis作为缓存，通常需要与数据库保持数据同步。读写分离的核心思路是：读请求优先走缓存，写请求更新数据库，同时更新或删除缓存，但这里有个老生常谈的问题：Redis缓存和数据库双写一致性。
业内共识是，无法做到强一致性，只能追求最终一致性，常用的策略是先更新数据库，再删除缓存，如果删除失败，可以通过消息队列重试，或者订阅数据库的binlog来异步同步，对于缓存与数据库一致性的疑问，多数场景下，最终一致性已经足够，强一致性需要引入分布式事务,代价极高。
分布式缓存Redis的核心机制与优势
基于内存的极致性能
Redis的所有数据都存储在内存中，读写速度极快，单机QPS（每秒查询数）可达10万+，相比关系型数据库的磁盘IO，内存访问的延迟通常只有微秒级。Redis的IO多路复用模型也是其高性能的关键，它能高效处理大量并发连接,避免线程上下文切换的开销。
丰富的数据结构满足复杂场景
Redis不仅仅是一个缓存，更是一个数据结构服务器，它支持String、Hash、List、Set、Sorted Set等基础类型，还有HyperLogLog、Bitmap、GEO、Stream等高级结构。
- String：最常用，用于存储简单的字符串、数字，适合做计数器、分布式锁。
- Hash：适合存储对象，比如用户信息、商品详情,可以像操作数据库字段一样更新单个属性。
- List：双向链表，适合做消息队列、最新消息列表,比如微博的时间线。
- Set：无序集合，适合做标签、去重、共同好友，求交集、并集运算非常高效。
- Sorted Set：有序集合，每个元素带一个分数，自动按分数排序，排行榜功能首选。
- HyperLogLog：用于基数统计，比如统计UV，占用内存极小,误差在可接受范围内。
- GEO：地理位置信息，可以计算两地距离、附近的人。
- Stream：Redis 5.0引入的持久化消息队列，支持消费组,比List更可靠。
持久化保障数据不丢失
虽然Redis是内存数据库，但它提供了RDB和AOF两种持久化机制。
- RDB：快照方式，在指定时间间隔将内存中的数据生成二进制文件保存到磁盘，优点是恢复速度快,适合做备份和灾难恢复。
- AOF：记录每次写操作命令，追加到文件末尾，数据安全性更高，但文件体积较大,恢复速度相对较慢。
- 生产环境通常两者结合使用，RDB做冷备,AOF做增量恢复。
如何部署和优化Redis分布式缓存
部署模式选择
Redis的部署模式有多种,需要根据业务规模和数据量决定。
| 部署模式 | 特点 | 适用场景 |
|---|---|---|
| 单机模式 | 简单，数据不持久，有丢失风险 | 缓存量小，允许丢失数据的场景 |
| 主从模式 | 一主多从，读写分离，主节点挂了可从节点升级 | 小规模应用，需要高可用 |
| 哨兵模式
|
在主从基础上增加监控和自动故障转移 | 中等规模，需要自动容灾 |
| 集群模式 | 数据分片，无中心节点，水平扩展 | 海量数据，高并发写入，Redis集群是业界主流方案 |
对于Redis集群的部署，至少需要3个主节点，每个主节点可以配一个从节点，数据通过哈希槽（16384个槽）分布到不同节点，客户端直接连接集群，无需代理层,性能损耗小。
内存淘汰策略与过期键处理
当Redis内存达到上限时，会触发内存淘汰策略,常见的策略有：
- noeviction：不淘汰，写入失败,直接返回错误。
- allkeys-lru：从所有key中淘汰最近最少使用的。
- volatile-lru：从设置了过期时间的key中淘汰最近最少使用的。
- allkeys-random：随机淘汰。
- volatile-ttl：淘汰即将过期的key。
对于缓存场景，推荐使用allkeys-lru或volatile-lru，保证热点数据不被淘汰，过期键的清理是惰性删除+定期删除结合的，Redis会每秒定期抽查一部分key，发现有过期就删除,同时在请求时再检查一次。
键值设计与命名规范
好的键名设计能提升可读性和维护性，建议遵循项目名:业务名:对象ID:字段的格式，比如myapp:user:1001:profile，避免使用过长的键名，会占用内存，对于Redis分布式缓存的键值对，要合理设置过期时间,避免无效数据长期占用内存。
实战：用Redis分布式缓存优化高频查询
假设一个电商平台的商品详情页，后台接口需要查商品信息、库存、评价、促销活动等多个表，未优化前，每次请求都查数据库,并发稍高就出现慢查询。
优化思路：将商品ID作为key，整个详情页的JSON序列化数据作为value，缓存到Redis，过期时间设为5分钟，当用户访问时，先查Redis，命中直接返回，不命中则查数据库,组装数据再写入缓存。
- 对于热门商品，可以设置较长的过期时间，甚至用逻辑过期,后台异步更新。
- 对于库存这类频繁更新的数据，可以单独缓存，用Redis的incr/decr原子操作，更新库存时同步更新Redis，包裹在数据库事务中,保证最终一致。
- 对于促销活动，可以预先将活动数据加载到Redis,活动开始后直接读取缓存。
这个方案能减少90%以上的数据库直接查询，接口响应时间从300ms降到10ms左右。广州地区某电商公司采用类似方案后,系统撑住了双十一的峰值流量。
常见问题解答
Redis分布式缓存和本地缓存（如Ehcache）怎么选？
本地缓存数据在应用进程内，速度最快，但多个服务器之间无法共享，且会占用应用自身内存，Redis分布式缓存通过网络访问，数据集中管理，适合多实例共享。两者的选择依据主要是场景：单机应用或缓存数据很小，用本地缓存；需要跨进程共享、数据一致性要求高、缓存量大的业务，用Redis，实践中，两者可以结合使用，形成多级缓存，本地缓存优先，未命中再查Redis,进一步降低Redis压力。
缓存和数据库一致性怎么保证？
强一致性极难实现，业界没有银弹，主流方案是先更新数据库，再删除缓存，如果删除失败，启用重试机制（如消息队列），如果对一致性要求比较严格，可以使用订阅binlog的方式（如Canal），将数据库变更同步到Redis，对于大多数互联网业务，最终一致性已经足够,用户很少能感知到毫秒级的延迟差异。
多大的Redis集群足够支撑日活千万的应用？
这取决于缓存的数据量和QPS。Redis集群的扩展性很强，通过增加节点可以线性提升性能，一个3主3从的Redis集群，每个主节点8G内存，大约能支撑总缓存量24G（因为从节点不存储数据，只做备份），日活千万的应用，如果是读多写少的场景，QPS大概在几万到十几万，3主3从的集群足以应对，如果业务场景写入频繁，或需要存储大量摘要数据，可以增加到6主6从或更多，关键在于监控内存使用率和命中率,及时调整。
分布式缓存Redis的核心价值在于用空间换时间，用内存换速度，它让系统在高并发下依然保持稳定和快速响应，合理设计数据模型、淘汰策略和集群架构,是发挥其最大效用的关键。