【不背八股】10.Redis知识点汇总

1. Redis 简介

Redis 是一个内存型数据库（in-memory database），数据主要存储在内存中，支持快速读写操作，同时可以将数据持久化到磁盘。它属于NoSQL 数据库的一种，主要用于存储键值对（key-value）。

Redis 有以下应用场景：

• 1.缓存系统

  • 作用：将热点数据缓存在内存中，减少数据库访问压力，提升系统响应速度。
  • 示例：存储用户会话信息、商品详情缓存、首页推荐数据。

• 2.消息队列

  • 作用：利用列表（List）和发布/订阅（Pub/Sub）实现异步消息传递和任务队列。
  • 示例：订单处理、日志异步处理、异步邮件发送。

• 3.实时计数器

  • 作用：高效地统计访问量、点赞数、PV/UV 等指标，支持秒级更新。
  • 示例：文章阅读数统计、秒杀活动库存管理。

• 4.排行榜

  • 作用：利用有序集合（Sorted Set）实现实时排行，按分值自动排序。
  • 示例：游戏积分排行、商品热度排行。

• 5.分布式锁

  • 作用：通过 SETNX 或 RedLock 实现多实例间的互斥操作，保证分布式系统的数据一致性。
  • 示例：防止秒杀活动中库存超卖、保证任务只被一个节点执行。

2. Redis 数据类型

(1) String（字符串）

• 说明：最基本的数据类型，可以存储字符串、数字、二进制数据（如图片、JSON）。
• 适用场景：缓存单个对象、计数器、分布式锁等。

(2) Hash（哈希）

• 说明：存储字段-值（field-value）映射，适合表示对象。
• 适用场景：存储用户信息、配置参数。

(3) List（列表）

• 说明：按照插入顺序存储字符串，可以从两端推入或弹出。
• 适用场景：消息队列、任务队列、时间轴。

(4) Set（集合）

• 说明：无序、元素唯一的集合。
• 适用场景：去重、交集、并集计算。

(5) Sorted Set（有序集合）

• 说明：在集合的基础上，每个元素关联一个分值（score），按分值排序。
• 适用场景：排行榜、带权重的队列。

(6) 特殊数据结构

• Bitmap（位图）：用二进制位存储布尔值，适合用户签到、活跃统计。
• HyperLogLog：用于基数统计，近似计算去重数量，内存占用小。
• Geospatial（地理位置）：存储地理坐标，支持附近位置查询。

3. 持久化机制

Redis 是一个以内存为主的数据库，所有数据都存放在内存中，一旦服务宕机或重启，内存数据会丢失。为了保证数据在异常情况下不会全部丢失，Redis 提供了 持久化机制，将数据从内存保存到磁盘，以便在重启后进行恢复。

Redis 的持久化主要有三种方式：RDB 快照、AOF 日志、混合持久化。

(1) RDB（快照）

• 说明：Redis 会在指定的时间间隔内，把某个时刻的所有数据保存成一个二进制快照文件（dump.rdb）。
• 优点：文件体积较小，恢复速度快，非常适合做数据备份。
• 缺点：属于定时快照方式，如果 Redis 在两次快照之间宕机，会丢失最近一段时间的数据。
• 适用场景：数据对实时性要求不高，但需要快速恢复的场景，比如定时备份。

(2) AOF（追加文件）

• 说明：将 Redis 执行的每一条写操作命令，以追加的形式记录到日志文件（appendonly.aof）中，重启时通过回放日志恢复数据。
• 优点：持久性更强，几乎可以做到秒级的数据不丢失。
• 缺点：日志文件可能会很大，恢复速度相对 RDB 慢，需要定期重写（rewrite）文件以减小体积。
• 适用场景：对数据安全性要求较高的系统，如金融、订单等关键业务。

(3) 混合持久化（RDB + AOF）

• 说明：Redis 4.0 引入的机制，结合了 RDB 和 AOF 的优点：先保存一份 RDB 快照，再把之后的写命令追加到 AOF 文件。
• 优点：既保证了恢复速度（RDB 的优势），又减少了数据丢失风险（AOF 的优势）。
• 缺点：实现更复杂，文件格式比单独使用 RDB 或 AOF 更难解析。
• 适用场景：需要在数据安全性和恢复效率之间取得平衡的大多数生产环境。

4. 过期删除与内存淘汰策略

Redis 是基于内存的数据库，内存的利用效率和数据管理方式直接影响系统的性能和稳定性。为了保证内存不会无限膨胀，Redis 提供了两类机制：过期删除（针对设置了过期时间的 key）和 内存淘汰（当内存达到上限时）。

(1) 过期删除策略

当 key 设置了过期时间，过期后需要被删除，Redis 使用了三种方式：

• 定时删除：在设置过期时间时，同时创建一个定时器，到期立即删除。优点是内存能及时释放，缺点是定时器过多会占用 CPU。
• 惰性删除：访问 key 时才检查是否过期，如果过期则删除。优点是节省 CPU，缺点是过期数据可能长时间占用内存。
• 定期删除：周期性抽样检查部分 key，删除其中的过期数据，是前两种策略的折中。

Redis 实际上采用 惰性删除 + 定期删除 相结合的方式。

(2) 内存淘汰策略

当 Redis 占用的内存达到 maxmemory 上限时，如果有新的写入请求，就会触发淘汰机制。常见策略包括：

• noeviction：默认策略，不再接受写入请求，只能读。
• allkeys-lru：在所有 key 中，淘汰最近最少使用的 key。
• volatile-lru：在设置了过期时间的 key 中，淘汰最近最少使用的 key。
• allkeys-random：在所有 key 中，随机淘汰一个。
• volatile-random：在设置了过期时间的 key 中，随机淘汰一个。
• volatile-ttl：在设置了过期时间的 key 中，优先淘汰剩余生存时间最短的 key。

生产环境中，最常见的是 allkeys-lru。

5. 集群与高可用

在实际应用中，单机 Redis 会遇到两个主要问题：

1. 单点故障：一旦 Redis 进程或机器宕机，整个服务会中断。
2. 扩展性不足：单机内存和 CPU 有限，无法应对大规模数据和高并发。

为了解决这些问题，Redis 提供了多种高可用与集群方案：主从复制、哨兵模式 和 集群模式。

(1) 主从复制（Replication）

主从复制是 Redis 提供的最基本的高可用手段。通过一主多从架构，主节点（Master）处理写操作，从节点（Slave）复制主节点数据并提供只读服务。

工作原理

• 从节点启动时，会向主节点发送 PSYNC 同步请求。
• 主节点将当前快照（RDB 文件）发送给从节点，从节点加载后完成初始全量复制。
• 随后，主节点会将新的写命令不断发送给从节点，保持数据实时同步。

结构如下图[1]所示：

优点

• 提高读性能，可通过读写分离来分担主节点压力。
• 从节点可作为热备份，提高数据安全性。

缺点

• 主节点宕机后，需要人工干预来切换。
• 写请求仍是单点瓶颈，无法水平扩展。

(2) 哨兵模式（Sentinel）

哨兵（Sentinel）是一个独立的 Redis 进程，用来监控主从集群的运行状态。当主节点故障时，哨兵会自动将某个从节点提升为新的主节点，并通知客户端更新连接信息。

工作原理

• 哨兵进程会定期向主节点和从节点发送心跳包，判断它们是否存活。

• 如果多数哨兵认为主节点下线，则会发起 故障转移（Failover）：

  • 从存活的从节点中选举一个作为新主节点。
  • 修改集群配置，让其它从节点转向新主节点复制。
  • 通知客户端更新主节点地址。

结构如下图[1]所示：

优点

• 自动故障转移，无需人工干预。
• 多哨兵协作，避免单点故障。

缺点

• 数据仍然存储在单机，无法突破内存上限。
• 部署和维护比单纯主从复杂。

(3) 集群模式（Redis Cluster）

集群模式是官方提供的分布式集群方案，既支持 数据分片（解决存储瓶颈），也支持 高可用（节点故障自动转移）。

工作原理

• 数据被划分为 16384 个槽位（hash slots）。
• 每个 Redis 节点负责一部分槽位的数据。
• 客户端根据 key 计算槽位（CRC16 算法），然后直接访问对应的节点。
• 每个主节点（Master）都可以有若干从节点（Slave）做备份。
• 当某个主节点宕机时，其从节点会自动接管，实现高可用。

优点

• 水平扩展，突破单机内存和性能限制。
• 内置高可用，部分节点故障不影响整体运行。
• 支持大规模分布式部署。

缺点

• 不支持跨槽的事务和 Lua 脚本。
• 集群运维和数据迁移复杂度较高。

6. 常见问题与解决方案

在 Redis 的实际使用过程中，会遇到一些性能和稳定性问题。下面总结几类常见问题及应对方案。

(1) 缓存雪崩

大量缓存数据在同一时间失效，导致请求瞬间全部打到数据库，引发数据库压力激增甚至宕机。

原因

• 缓存数据设置了相同的过期时间
• 热点数据同时失效

解决方案

• 给缓存设置随机过期时间，避免同时过期
• 使用互斥锁或队列来控制并发请求
• 重要数据设置为“永不过期”，由异步任务更新

(2) 缓存穿透

请求的数据既不在缓存中，也不在数据库中，导致每次请求都会落到数据库。恶意攻击时会产生大量无效请求。

原因

• 查询不存在的数据
• 黑客通过构造请求绕过缓存

解决方案

• 对空结果进行缓存（如设置短期过期时间）
• 使用布隆过滤器拦截不存在的 key
• 增加请求参数校验，避免非法请求

(3) 缓存击穿

热点 key 在失效的瞬间，有大量并发请求访问该 key，导致请求同时落到数据库。

原因

• 某些数据访问量极高
• 数据恰好在高并发时失效

解决方案

• 设置互斥锁（Mutex）保证只有一个线程去加载数据
• 使用逻辑过期（在缓存中标记过期时间，后台异步更新）
• 热点数据采用双缓存（主缓存 + 备用缓存）

(4) 大 key 问题

某个 key 存储的数据量过大，导致查询、删除或迁移操作耗时严重。

原因

• 使用 Hash、List、Set 等存储了海量元素
• 应用层未做分片，导致单 key 承担过多数据

解决方案

• 拆分大 key，将数据分散到多个小 key
• 分批次删除或迁移，避免一次性操作阻塞主线程
• 在上线前通过 redis-cli --bigkeys 工具排查大 key

参考

[1] 小林coding-图解redis：https://www.xiaolincoding.com/redis