redis 内存管理和持久化机制

---

前言

redis 内存管理与持久化

---

一、内存管理

redis我们的数据都是放在内存里面的，但是内存是有大小的，如果一直将数据放入，会导致内存溢出，这时候需要进行数据清理。

内存的大小由一个配置决定

maxmemory 100mb

如果配置是0，那么默认是电脑的内存，如果是32bit 隐式大小为3G。

数据清理，通过两张方式来实现。1、过期策略，2、淘汰策略

1、Redis过期策略

过期策略又分为惰性过期和定期过期

1.1、惰性过期

在Redis里面，就是每次在访问操作Key的时候，判断这个Key是不是过期了，如果过期了就删除。

该策略就可以最大化地节省CPU资源，只有访问的时候才去使用cpu判断一下, 但是这样却对内存非常不友好。如果没有再次访问，本来该key需要过期删除，结果一直堆积在内存里面，造成内存泄露。

是不是可以定期去扫描，然后判断是否过期删除？答案是肯定的，redis也制定了另一种方案，定期过期

1.2、定期过期

清理频率配置

定期就需要去定义这个循环周期，比如五分钟一次，这个参数由redis.conf中的hz配置来决定，它的取值范围是 1 到 500。
hz 参数定义了 Redis 每秒钟执行的事件循环次数，这包括检查和删除过期键的任务。默认情况下，hz 设置为 10，意味着每秒进行 10 次过期键的检查。
要修改这个值，你可以编辑 Redis 配置文件 (redis.conf) 或者在运行时通过 CONFIG SET 命令动态修改：

• 在配置文件中设置

打开你的 redis.conf 文件，并找到 hz 参数，将其值更改为所需的频率。例如，如果你想将频率提高到每秒20次，则设置如下：

hz 20

• 动态配置

如果你不想重启 Redis 服务，也可以使用 CONFIG SET 命令在线更改此参数。例如：

CONFIG SET hz 20

需要注意的是，虽然增加 hz 的值可以让 Redis 更快地处理同时到期的许多键，并且更加精确地处理超时，但这会占用更多的 CPU 资源。

因此，通常不建议将 hz 设置得过高（超过 100），除非是在对请求延时要求非常低的情况下。

从 Redis 6.2 开始，server.hz 的实际生效值可能会根据客户端连接的数量动态调整，以确保即使在高负载下也能保持良好的性能。这意味着配置文件中的 hz 只是一个初始值，而实际运行时的刷新频率是动态变化的。

清理流程

1. serverCron方法定时去执行清理，执行频率根据redis.conf中的hz配置的值
2. 执行清理的时候，不是去扫描所有的key，而是去扫描所有设置了过期时间的key（redisDb.expires）
3. 如果每次去把所有过期的key都拿过来，那么假如过期的key很多，就会很慢，所以也不是一次性拿取所有的key
4. 根据hash桶的维度去扫描key，扫到20(可配)个key为止。假如第一个桶是15个key ，没有满足20，继续扫描第二个桶，第二个桶20个key，由于是以hash桶的维度扫描的，所以第二个扫到了就会全扫，总共扫描35个key
5. 扫描出来的过期的key，进行删除
6. 如果取了400个空桶，或者扫描的删除比例跟扫描的总数超过10%，继续执行4、5步。
7. 也不能无限的循环，循环16次后回去检测时间，超过指定时间会跳出。

流程图：

2、Redis淘汰策略

策略

由于Redis内存是有大小的，并且里面的数据都没有过期，这样一直放入数据，使得内存满了的时候，Redis就不能放入新的数据，导致不可用，这是我们不愿意看到的。
所以，我们需要使用一些策略来解决这个问题来保证可用性，

官网提供了8种不同的策略

• noeviction（默认）：
  不进行任何淘汰。当内存使用超过限制后，所有写入操作将返回错误信息，而读取操作仍然可以正常执行。
• volatile-lru：
  使用 LRU (Least Recently Used) 算法从设置了过期时间的键中淘汰最久未使用的键。
• allkeys-lru：
  使用 LRU 算法从所有键中淘汰最久未使用的键，包括那些没有设置过期时间的键。
• volatile-lfu：
  使用 LFU (Least Frequently Used) 算法从设置了过期时间的键中淘汰最少使用的键。这个策略是在 Redis 4.0 版本引入的。
• allkeys-lfu：
  使用 LFU 算法从所有键中淘汰最少使用的键。同样是在 Redis 4.0 中新增的功能。
• volatile-random：
  随机地从设置了过期时间的键中挑选一个键进行淘汰。
• allkeys-random：
  随机地从所有键中挑选一个键进行淘汰。
• volatile-ttl：
  淘汰那些设置了过期时间且剩余生存时间最短的键，即优先删除即将过期的键。

我们可以在config中配置maxmemory-policy来指定相关的淘汰策略

maxmemory-policy noeviction //默认不淘汰数据，能读不能写

流程

1. redis有个淘汰池，默认大小是16，并且里面的数据是末尾淘汰制。
2. 每次指令操作的时候，会判断当前内存是否满足指令所需要的内存
3. 如果当前内存不能满足，会从淘汰池中的尾部拿取一个最适合淘汰的数据
   • 会取样（配置 maxmemory-samples）从Redis中获取随机获取到取样的数据，解决一次性读取所有的数据慢的问题
   • 在取样的数据中，根据淘汰算法，找到最适合淘汰的数据
   • 将最合适的那个数据跟淘汰池中的数据比较，是否比淘汰池中的更适合淘汰，如果更适合，放入淘汰池
   • 按照适合的程度进行排序，最适合淘汰的放入尾部
4. 将需要淘汰的数据从Redis删除，并且从淘汰池移除。

流程图：

算法分析

1、LRU

LRU，Least Recently Used 翻译过来是最久未使用，根据时间轴来走，仍很久没用的数据。只要最近有用过，我就默认是有效的。
根据使用时间，从近到远，越远的越容易淘汰

1、实现原理

• 首先，LRU是根据这个对象的访问操作时间来进行淘汰的，那我们需要知道这个对象最后的操作访问时间。
• 知道了对象的最后操作访问时间后，我们只需要跟当前的系统时间来进行对比，就能计算出对象已经多久没访问了

2、时间计算

• 它使用一个24位的时钟计数器，每秒递增一次。这个计数器提供的分辨率足以满足大多数应用场景的需求，同时大大减少了存储时间戳所需的内存空间。
• 每当一个键被访问时，就会更新它的 LRU 字段为当前的lruclock值。当时间超过24位（秒，大概是194天），lruclock又会从0开始。redisObject.lru则是记录当前时间。
  • 如果redisObject.lru < lruclock，直接通过 lruclock-redisObject.lru 得到这个对象多久没访问
  • 如果redisObject.lru > lruclock,通过 lruclock+（24bit的最大值-redisObject.lru）得到这个对象多久没访问

轮询
这里有个轮询的概念，它如果超过24位，又会从0开始。

以时钟为例
昨天10点访问的记录，现在是12点了，请问过了多久？12 - 10 = 2h
昨天10点访问的记录，现在是5点了，请问过了多久？24- 10 + 5 = 19h

这里的现在可能是今天，也可能是明天，就是轮询了多天，那该如何计算

对于redis而言，伪lru算法本来就不是非常精确的。所以redis只考虑1次轮询的情况，对于多次轮询，也只按1次轮询处理。
也就是说现在只当成今天处理，不会当成明天或者后天等。

3、知识点：
系统时间戳记录在全局变量中，每100ms更新一次。当函数查询key调⽤lookupKey中更新数据的Iru热度值时，就不⽤每次调⽤系统函数time，可以提⾼执⾏效率。

4、流程图：

2、LFU

LFU,LeastFrequentlyUsed，最不常⽤，按照使⽤频率删除，4.0版本新增。 它的衡量标准就是次数，次数越少的越容易被淘汰。每次操作访问一次，就+1; 淘汰的时候，直接去比较这个次数，次数越少的越容易淘汰。

1、redisObject.lru的前16bit表示时间，后8bit表示这个对象的访问频率。

前16bit代表的是这个对象最后访问时间的分单位。通过这个值能够得到这个对象多少分钟没访问。结合lfu-decay-time，来控制对象的访问频率。这样能有效控制很久没访问的数据一直保持热点。

lfu-decay-time 1	// 衰减因子，多少分钟没访问就减少一次

2、8bit最大值是255，用后8bit表示访问次数是不够的。redis在这里做了一些处理，让数据达到255很难。方案如下：

• 访问次数最大只能255，如果到了255，不往上加。实际到达255的几率不是很高。可以支撑很大很大的数据量。
• 访问次数属于随机添加，添加的几率根据基数值（LFU_INIT_VAL）、已有的counter值、配置server.lfu_log_factor相关，counter值越大，添加的几率越小，lfu-log-factor配置的值越大，添加的几率越小。
  假设基准值是100
• 访问次数 < 100，则每次访问则+1
• 访问次数 100 <= counter <= 255，要通过公式计算，越往上，增长因子越低。会让255很难达到，从而8位就能满足需求了。

3、官方的压测数据如下

二、持久化

Redis 作为一个内存数据库，其主要特性之一是高性能的数据操作，而这种高性能得益于数据存储在内存中。在某些情况下，如服务器重启、操作系统崩溃、电源故障等，内存中的数据会丢失。因此，Redis 需要持久化来保证数据的安全性和可恢复性。

redis持久化方式

• RDB
• AOF
• RDB + AOF

1、RDB

工作原理：

RDB 是通过创建数据集的时间点快照（snapshot）来实现的持久化机制。Redis 会将内存中的数据在特定时间点保存到磁盘上的一个二进制文件（默认名为 dump.rdb）中。

• 文件配置： 磁盘文件的路径和文件名都是可配置的

// 生成的快照文件名
dbfilename dump.rdb
// 快照文件保存的路径
dir ./// 开启数据压缩（默认开启），如果关闭，会导致.rdb文件变得很大
rdbcompression yes

• 自动触发：通过配置文件中的 save 选项来指定自动触发 RDB 快照的条件

save 900 1   # 900秒(15分钟)内有1个键被修改就保存快照
save 300 10  # 300秒(5分钟)内有10个键被修改就保存快照
save 60 10000 # 60秒(1分钟)内有10000个键被修改就保存快照

以上的配置在 redis.conf 完成

• 手动触发：Redis 提供了一些命令可以手动触发 RDB 快照
  • BGSAVE 命令：这个命令会在后台进行保存操作，Redis 会继续处理来自客户端的请求。
  • SAVE 命令：与 BGSAVE 不同，SAVE 命令在执行期间会阻塞 Redis 服务器，直到快照完成。

优点：

• 生成的rdb文件是一个非常紧凑的文件，所以很适合远程传输、备份和灾难恢复。
• 数据恢复速度快，因为文件格式非常紧凑。
• 对读取性能没有影响，适合用于读取密集型场景。

缺点：

• 安全性很低，可能会有数据丢失。假如每5分钟备份一次，断电宕机后会有5分钟的数据丢失。
• 经常fork子进程，所以比较耗CPU，对CPU不是很友好（对CPU要求高）。

2、AOF

工作原理：

AOF是通过将每一个写命令记录到日志文件（默认名为appendonly.aof）中实现的。Redis 在处理写命令时，会将这些命令追加到日志文件的末尾。在恢复数据时，Redis 会通过重新执行这些命令来重建数据集。

配置：
通过配置文件中的 appendonly 和 appendfsync 选项来启用并配置 AOF ，例如：

appendonly yes  # 启用AOF持久化
appendfsync everysec  # 每秒持久化一次
# 其他选项可以是：
# appendfsync always # 每次写操作后持久化（最安全但对性能影响最大）
# appendfsync no # 由操作系统决定何时持久化（性能最好，但最不安全）

AOF有个问题：随着时间的推移，写入的命令越来越多，相应的AOF的日志文件越来越大，文件中冗余内容会越来越多。如果redis再重启或做数据恢复，加载数据会很慢。
处理这个问题，则需要重写AOF

AOF 重写机制的工作原理

• Fork 子进程：
  • Redis 会 fork 一个子进程，这个子进程会创建一个新的 AOF 文件。
  • 子进程将根据当前内存中的数据来生成这个新的 AOF 文件，而不是直接复制现有的 AOF 文件。
• 命令压缩：
  • 新的 AOF 文件会包含相同的数据，但是会优化和压缩命令。例如，多个对同一个 key 的写操作可能会被压缩为一个 SET 或者其他合并操作。
• 追加命令：
  • 在子进程创建新 AOF 文件的过程中，主进程仍然在接受新写操作。将这些新的写操作记录到一个内存缓冲区中。
  • 当子进程完成新 AOF 文件的创建后，主进程将内存缓冲区中的新写操作追加到新的 AOF 文件。
• 文件替换：
  • 最后， Redis 会将旧的 AOF 文件替换成新的 AOF 文件。

触发条件和策略
AOF 重写可以通过自动触发和手动触发两种方式进行：

1. 自动触发
   Redis 可以根据配置的条件自动触发 AOF 重写。以下是与自动触发相关的配置选项：

# 设置当前 AOF 文件大小相对于上一次重写后的大小增加的百分比，当超过这个百分比时触发AOF重写。
# 比如设置为 100，表示当前 AOF 文件大小是上次重写后的两倍时触发重写。
auto-aof-rewrite-percentage 100# 设置触发 AOF 重写的最小 AOF 文件大小。
# 比如设置为 64mb，表示 AOF 文件至少达到 64MB 时才允许触发重写。
auto-aof-rewrite-min-size 64mb

2. 手动触发

管理员可以通过 Redis 命令手动触发 AOF 重写：

BGREWRITEAOF 命令:

BGREWRITEAOF

该命令在后台重写 AOF 文件，不会阻塞 Redis 的正常操作

AOF优缺点

优点：

• 提供更高的数据安全性，因为写命令几乎实时持久化，数据丢失风险小。
• AOF文件是可读的，可以通过文本编辑器阅读和编辑日志文件中的命令。
• 可以配置不同的频率来记录命令，使得持久化策略更灵活。

缺点：

• AOF日志文件通常比RDB快照文件大。
• 随着时间推移，日志文件会不断增长，需要定期重写（rewrite）日志文件，以缩减其大小。
• 数据恢复速度较慢，因为需要一条一条重放写操作。

3、AOF + RDB：
Redis 还支持同时开启两种持久化机制，以结合两者的优点。通常会选择 RDB 作为定期的全量备份方案，而 AOF 作为增量日志记录，确保在最后一次 RDB 快照之后的数据变更也能够持久化。

同时开启配置

# 启用 AOF 持久化
appendonly yes
appendfsync everysec# RDB 持久化配置
save 900 1
save 300 10
save 60 10000

这种混合配置可以在确保较好性能的同时，最大限度减少数据丢失的风险。