分布式缓存Redis

本文目录导读：

1. 为什么用Redis做分布式缓存？
2. Redis分布式缓存的核心架构模式
3. 缓存使用中的经典问题及解决方案
4. 数据一致性问题
5. 持久化策略
6. 淘汰策略
7. 总结与最佳实践

这是一个非常核心的技术话题，Redis作为当前最流行的分布式缓存之一，广泛应用于高并发、低延迟的场景。

下面我给你系统性地梳理一下Redis作为分布式缓存的核心概念、关键机制、常见问题和最佳实践。

为什么用Redis做分布式缓存？

1. 性能极高：基于内存操作，读写速度可达10万+ QPS（每秒查询率）,远超基于磁盘的数据库。
2. 丰富的数据结构：不只是String，还支持List、Set、ZSet（有序集合）、Hash、Geo等，能解决很多复杂场景（如排行榜、计数器、社交关系）。
3. 原子操作：支持对单个或多个键的原子性操作，适合做分布式锁、限流。
4. 持久化：虽然是缓存，但提供RDB（Redis数据库快照）和AOF（Append Only File，追加文件）两种持久化机制,保证数据不轻易丢失。
5. 高可用与扩展性：通过主从复制、Sentinel（哨兵）和Cluster（集群）,可以轻松构建大规模高可用的缓存服务。

---

Redis分布式缓存的核心架构模式

单机模式

• 特点：简单,部署一个Redis实例。
• 问题：单点故障（SPOF, Single Point of Failure），内存有限,无法应对高并发和大量数据。

主从复制 + 哨兵模式

• 结构：一主多从（Master负责写，Slave负责读）；Sentinel负责监控、通知和自动故障转移。
• 优点：
  • 读写分离：Master写，Slave读,分担读压力。
  • 高可用：Master宕机后,Sentinel自动选举一个Slave升级为Master。
• 缺点：
  • 数据是全量存储，所有节点存一样的数据,内存利用率不高。
  • 写操作仍然是单点（Master）,写性能有上限。

Redis Cluster 模式

• 结构：去中心化，数据自动分片到多个节点（16384个哈希槽）。
• 优点：
  • 自动分片：数据分布在不同节点，解决了单机内存瓶颈,支持TB级别数据。
  • 高可用：每个分片都有主从节点,部分节点宕机不影响整体。
  • 线性扩展：增加节点即可提高吞吐量和容量。
• 缺点：
  • 不支持多键操作（如跨槽的MGET或事务）。
  • 客户端实现相对复杂（需要知道槽位映射）。

---

缓存使用中的经典问题及解决方案

这是面试和实际开发中最常考察的点。

缓存穿透

• 问题：查询一个根本不存在的数据，由于缓存未命中，请求直接打到数据库，导致数据库压力过大,恶意攻击者常利用这一点。
• 解决：
  • 缓存空对象：即使数据库查询结果为空，也缓存这个空结果（设置较短的过期时间，如60秒）。
  • 布隆过滤器：在缓存前加一层布隆过滤器，如果判断数据不存在，直接拦截,不再查询数据库。

缓存击穿

• 问题：一个热点Key在缓存过期的瞬间，大量请求同时访问这个Key，全部穿透到数据库,导致数据库瞬间高负载。
• 解决：
  • 互斥锁：在缓存失效时，只允许一个线程去数据库加载数据并重建缓存,其他线程等待。
  • 逻辑过期：不设置物理过期时间，而是在Value中存储一个逻辑过期时间，后台异步线程更新缓存,避免缓存失效瞬间的冲击。

缓存雪崩

• 问题：大量缓存在同一个时间段集中过期，或者Redis实例宕机，导致所有请求全部打到数据库,造成数据库崩溃。
• 解决：
  • 过期时间加随机值：设置缓存过期时间时，加上一个随机数（如1-5分钟）,避免集体过期。
  • 使用多级缓存：本地缓存（如Caffeine）+ Redis缓存，即使Redis挂了,还有本地缓存兜底。
  • 限流降级：使用Sentinel、Hystrix等对数据库访问进行限流,保护后端。
  • 集群高可用：部署Redis Cluster,避免单点故障。

---

数据一致性问题

缓存和数据库的数据一致性是分布式系统中最头疼的问题。

• 策略选择：

  • 强一致性：代价极高，通常不推荐，可以考虑使用“延迟双删”或“分布式事务”（如2PC, Two-Phase Commit，两阶段提交）,但会影响性能。
  • 最终一致性：大部分业务场景的合理选择。

• 推荐方案（Cache Aside Pattern 旁路缓存模式）：

  1. 读操作：先读缓存，命中则返回；未命中则读数据库，然后写入缓存,最后返回。
  2. 写操作：
     • 正确做法：先更新数据库，再删除缓存。
     • 原因：删除缓存比更新缓存更安全，因为更新缓存可能涉及复杂计算,而删除可以在下一次读取时主动重建。
     • 注意：可能存在“删除缓存失败”的问题，可以通过“重试机制”或“订阅Binlog（如Canal）+ 异步更新”来保证最终一致性。

---

持久化策略

• RDB（快照）：
  • 原理：定时对内存数据进行全量快照，生成.rdb文件。
  • 优点：文件紧凑，恢复速度快,适合备份。
  • 缺点：可能会丢失最后一次快照之后的数据。
• AOF（追加文件）：
  • 原理：记录每次写操作的日志，fsync策略可配置。
  • 优点：数据安全性高（最多丢失1秒数据）。
  • 缺点：文件体积大,恢复速度慢。
• 建议：通常两者结合使用（AOF保证数据安全，RDB用于快速恢复和备份）。

---

淘汰策略

当内存不足时，需要淘汰一些Key，Redis提供了8种策略（主要分几类）：

• LRU（Least Recently Used，最近最少使用）：淘汰最近最少使用的数据（allkeys-lru或volatile-lru）。
• LFU（Least Frequently Used，最不经常使用）：淘汰访问频率最低的数据（allkeys-lfu或volatile-lfu）。
• TTL（Time To Live，生存时间）：淘汰即将过期的数据（volatile-ttl）。
• 随机淘汰（allkeys-random / volatile-random）。
• 禁止淘汰（noeviction）：内存满时直接报错。

生产建议：一般使用 allkeys-lru。

---

总结与最佳实践

维度	关键点
选型目的	解决数据库读写压力，提升系统响应速度。
关键指标	QPS、延迟、命中率、内存使用率、数据一致性。
常见问题	穿透（布隆过滤器/空值缓存）、击穿（互斥锁）、雪崩（随机过期/限流）。
一致性	优先保证最终一致性，推荐“先更新DB，再删缓存”。
运维	使用 INFO 监控命中率；设置 maxmemory；合理配置持久化策略。
小技巧	避免使用 KEYS *（阻塞）；使用 PIPELINE批量操作；大Key需拆分。

一句话概括：Redis作为分布式缓存，本质是利用内存的高速读写能力，通过合理的架构设计和缓存策略，在性能和一致性之间寻找平衡点,有效保护后端数据库。

如果你对某个具体方面（比如分布式锁的RedLock算法、Redis 7.0的新特性、或者如何用Redis实现一个抢红包系统）感兴趣,可以深入聊聊。