Redis八股

发表于 更新于 分类于 阅读次数： Waline： 本文字数： 4.8k 阅读时长 ≈ 9 分钟

Redis过期key删除策略

常用的过期数据的删除策略就下面这几种：

  1. 惰性删除：只会在取出/查询 key 的时候才对数据进行过期检查。这种方式对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。
  2. 定期删除：周期性地随机从设置了过期时间的 key 中抽查一批，然后逐个检查这些 key 是否过期，过期就删除 key。相比于惰性删除，定期删除对内存更友好，对 CPU 不太友好。
  3. 延迟队列：把设置过期时间的 key 放到一个延迟队列里，到期之后就删除 key。这种方式可以保证每个过期 key 都能被删除，但维护延迟队列太麻烦，队列本身也要占用资源。
  4. 定时删除：每个设置了过期时间的 key 都会在设置的时间到达时立即被删除。这种方法可以确保内存中不会有过期的键，但是它对 CPU 的压力最大，因为它需要为每个键都设置一个定时器。

Redis 采用的那种删除策略呢？

Redis 采用的是 定期删除+惰性/懒汉式删除 结合的策略，这也是大部分缓存框架的选择。定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，结合起来使用既能兼顾 CPU 友好，又能兼顾内存友好。

也就是，首先惰性删除，在查询一个 key 的时候，Redis 首先检查该 key 是否存在于过期字典中（时间复杂度为 O(1)），如果不在就直接返回，在的话需要判断一下这个 key 是否过期，过期直接删除 key 然后返回 null。

然后除此之外，Redis会有定期删除，也就是周期性地随机从设置了过期时间的key中抽查一批，看这些key是否过期。并且Redis设置了下面几个参数：

1
2
3
4
5
6
7
#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* Max % of CPU to use. */
#define ACTIVE_EXPIRE_CYCLE_ACCEPTABLE_STALE 10 /* % of stale keys after which we do extra efforts. */
#define ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP 20 /* Keys for each DB loop. */
# 默认为 10
hz 10
# 默认开启
dynamic-hz yes

依次的含义如下：

  • 每次执行时间最多为25ms，超过阈值则中断这一次定期删除循环，以避免使用过多的 CPU 时间。

  • 如果这一批过期的 key 比例超过一个比例，就会重复执行此删除流程，以更积极地清理过期 key。相应地，如果过期的 key 比例低于这个比例，就会中断这一次定期删除循环，避免做过多的工作而获得很少的内存回收。

  • 每次会随机选择 20 个设置了过期时间的 key 判断是否过期。

  • 定期删除的频率是由 hz 参数控制的。hz 默认为 10，代表每秒执行 10 次，也就是每秒钟进行 10 次尝试来查找并删除过期的 key。

    hz 的取值范围为 1~500。增大 hz 参数的值会提升定期删除的频率。如果你想要更频繁地执行定期删除任务，可以适当增加 hz 的值，但这会加 CPU 的使用率。根据 Redis 官方建议，hz 的值不建议超过 100，对于大部分用户使用默认的 10 就足够了。

  • dynamic-hz 这个参数开启之后 Redis 就会在 hz 的基础上动态计算一个值。Redis 提供并默认启用了使用自适应 hz 值的能力，

Redis内存淘汰机制

Redis 的内存淘汰策略只有在运行内存达到了配置的最大内存阈值时才会触发，这个阈值是通过redis.conf的maxmemory参数来定义的。64 位操作系统下，maxmemory 默认为 0 ，表示不限制内存大小。32 位操作系统下，默认的最大内存值是 3GB。

Redis 提供了 6 种内存淘汰策略：

  1. volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
  2. volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰。
  3. volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。
  4. volatile-lfu：从已设置过期时间的数据集中挑选最不经常使用的数据淘汰。
  5. allkeys-lru：从数据集中移除最近最少使用的数据淘汰。
  6. allkeys-random：从数据集中任意选择数据淘汰。
  7. allkeys-lfu：从数据集中移除最不经常使用的数据淘汰。
  8. no-eviction（默认内存淘汰策略）：禁止驱逐数据，当内存不足以容纳新写入数据时，新写入操作会报错。

Redis持久化机制

Redis支持三种持久化方式：

  • RDB（快照）
  • AOF（只追加文件）
  • RDB 和 AOF 混合持久化

RDB

Redis 可以通过创建快照来获得存储在内存里面的数据在 某个时间点 上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。

Redis 提供了两个命令来生成 RDB 快照文件：

  • save : 同步保存操作，会阻塞 Redis 主线程；
  • bgsave : fork 出一个子进程，子进程执行，不会阻塞 Redis 主线程，默认选项。

AOF

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入到 AOF 缓冲区中，然后再写入到 AOF 文件中（此时还在系统内核缓存区未同步到磁盘），最后再根据持久化方式（ fsync策略）的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

AOF 持久化功能的实现可以简单分为 5 步：

  1. 命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。
  2. 文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数（系统调用），write将数据写入到了系统内核缓冲区之后直接返回了（延迟写）。注意！！！此时并没有同步到磁盘。
  3. 文件同步（fsync）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
  4. 文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
  5. 重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。
image-20250310143135656

三种AOF刷盘策略

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式（ fsync策略），它们分别是：

  1. Always：主线程调用 write 执行写操作后，后台线程立即会调用 fsync 函数同步 AOF 文件（刷盘），fsync 完成后线程返回，这样会严重降低 Redis 的性能（write + fsync）。
  2. Everysec：主线程调用 write 执行写操作后立即返回，由后台线程每秒钟调用 fsync 函数（系统调用）同步一次 AOF 文件（write+fsync，fsync间隔为 1 秒）
  3. No：主线程调用 write 执行写操作后立即返回，让操作系统决定何时进行同步，Linux 下一般为 30 秒一次（write但不fsync，fsync 的时机由操作系统决定）。

AOF为什么是在执行完命令之后记录日志？

关系型数据库（如 MySQL）通常都是执行命令之前记录日志（方便故障恢复），而 Redis AOF 持久化机制是在执行完命令之后再记录日志。

  • 避免额外的检查开销，AOF 记录日志不会对命令进行语法检查；
  • 在命令执行完之后再记录，不会阻塞当前的命令执行。

这样也带来了风险：

  • 如果刚执行完命令 Redis 就宕机会导致对应的修改丢失；
  • 可能会阻塞后续其他命令的执行（AOF 记录日志是在 Redis 主线程中进行的）。

AOF重写

当 AOF 变得太大时，Redis 能够在后台自动重写 AOF 产生一个新的 AOF 文件，这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。

由于 AOF 重写会进行大量的写入操作，为了避免对 Redis 正常处理命令请求造成影响，Redis 将 AOF 重写程序放到子进程里执行。

AOF 文件重写期间，Redis 还会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾，使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作。

AOF校验

AOF 校验机制是 Redis 在启动时对 AOF 文件进行检查，以判断文件是否完整，是否有损坏或者丢失的数据。这个机制的原理其实非常简单，就是通过使用一种叫做 校验和（checksum） 的数字来验证 AOF 文件。这个校验和是通过对整个 AOF 文件内容进行 CRC64 算法计算得出的数字。如果文件内容发生了变化，那么校验和也会随之改变。因此，Redis 在启动时会比较计算出的校验和与文件末尾保存的校验和（计算的时候会把最后一行保存校验和的内容给忽略点），从而判断 AOF 文件是否完整。如果发现文件有问题，Redis 就会拒绝启动并提供相应的错误信息。AOF 校验机制十分简单有效，可以提高 Redis 数据的可靠性。

RDB vs AOF

数据安全性：

  • AOF提供更好的数据安全性，根据刷盘策略，当Redis服务宕机时，也只会丢失近一秒或者最后一次写入的数据。
  • RDB在两次快照之间，如果Redis服务宕机，这段数据会完全丢失。

占据空间：

  • AOF存储每一次写命令，通常AOF文件都会更大，占据更多磁盘空间。
  • RDB存储经过压缩的二进制内容，文件更小。

恢复速度：

  • 使用AOF文件恢复数据，需要重写执行每一条命令，速度非常慢（特别是如果没有进行AOF重写）。
  • 使用RDB文件恢复数据，直接解析还原数据即可，速度非常快。

性能影响：

  • AOF的always刷盘策略会频繁进行磁盘IO吗，会对Redis的写入性能造成一定影响。
  • RDB使用bgsave生成策略时，创建子线程进行，不会阻塞主线程，对服务性能影响较小。

Redis线程模型

Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。

Redis 通过 IO 多路复用程序 来监听来自客户端的大量连接（或者说是监听多个 socket），它会将感兴趣的事件及类型（读、写）注册到内核中并监听每个事件是否发生。I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗。

为什么使用单线程模型？

  • 单线程编程容易并且更容易维护；
  • Redis 的性能瓶颈不在 CPU ，主要在内存和网络；
  • 避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。
  • 通过 I/O 多路复用机制，实现了一个 Redis 线程处理多个 IO 流的效果。

Redis哪些地方有多线程？

多线程处理网络IO：

在Redis6.0之后，也采用了多个IO线程来处理网络请求，这是因为随着网络硬件的性能提升，Redis的瓶颈有时会出现在网络IO处理上。但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，执行命令仍然是单线程顺序执行。

后台线程：

Redis有三个后台线程来处理一些费时的操作：

  • 通过 bio_close_file 后台线程来释放 AOF / RDB 等过程中产生的临时文件资源。
  • 通过 bio_aof_fsync 后台线程调用 fsync 函数将系统内核缓冲区还未同步到到磁盘的数据强制刷到磁盘（ AOF 文件）。
  • 通过 bio_lazy_free后台线程释放大对象（已删除）占用的内存空间。