redis持久化

因为redis的数据是保存在内存中的，因此重启服务器，数据就会丢失。

redis提供了数据持久化方案。redis将数据保存到磁盘上，假如服务器重启后，通过磁盘中的文件恢复到内存中就可以了

持久化的3种模式：

• rdb,生成某一个时刻的快照，然后保存到二进制文件中
• aof,记录每一条写命令，追加到文件中，打开可以看到具体的操作记录
• 混合模式，它是上面两种方式的结合【一个日志文件既有rdb部分也会有aof的部分】redis在执行read write会清空日志做一次全量的rdb持久化，之后在按照aof模式把命令追加到aof文件中。在这种持久化方式下，Redis会同时生成RDB文件和AOF文件。当Redis重新启动时，优先使用AOF文件恢复数据，以确保数据的完整性。混合持久化适用于对数据安全性和性能要求较高的场景。

---

混合模式：

混合持久化并不是一种全新的持久化方式，而是对已有方式的优化。混合持久化只发生于 AOF 重写过程。使用了混合持久化，重写后的新 AOF 文件前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。

整体格式为：[RDB file][AOF tail]

开启：混合持久化的配置参数为 aof-use-rdb-preamble，配置为 yes 时开启混合持久化，在 redis 4 刚引入时，默认是关闭混合持久化的，但是在 redis 5 中默认已经打开了。

关闭：使用 aof-use-rdb-preamble no 配置即可关闭混合持久化。

混合持久化本质是通过 AOF 后台重写（bgrewriteaof 命令）完成的，不同的是当开启混合持久化时，fork 出的子进程先将当前全量数据以 RDB 方式写入新的 AOF 文件，然后再将 AOF 重写缓冲区（aof_rewrite_buf_blocks）的增量命令以 AOF 方式写入到文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

redis混合持久化
Redis4.0实现了RDB和AOF混合方式，相比于单RDB或者单AOF更安全，执行效率更高
在系统崩溃时，可以通过RDB文件进行快速的恢复，而AOF文件可以用于恢复最近的修改。
RDB持久化可以减少AOF文件的大小，从而减少磁盘空间的使用。
在RDB持久化中，Redis可以使用子进程来将快照写入磁盘，这样可以避免主进程的阻塞。

混合持久化的优点：

高数据安全性：结合了AOF持久化的高数据安全性。
快速恢复：利用RDB持久化的快速数据恢复速度。
提高从节点同步效率：利用RDB文件进行快速同步。

混合持久化的缺点：

较大的存储空间：AOF 文件里面的 RDB 部分不再是 AOF 格式，可读性差。相比于RDB文件占用较多的磁盘空间。

文献：面试必问的 Redis：RDB、AOF、混合持久化 - 知乎

---

持久化触发

手动触发

save,会让redis处于阻塞的状态，直到rdb持久化完成，中间不会在处理其他请求。线上环境要谨慎使用

bgsave,它会fork出一个子进程，由子进程用来执行持久化，主进程继续响应客户端请求。在fork时会有短暂的阻塞

自动触发

配置命令，在m秒内，执行命令最终执行的是bgsave,【在m秒内，有n个key发生改变，就会触发】

save 900 1
save 300 10
save 60 10000

bgsave的执行过程：

---

RDB模式：

优点

容灾性好，方便备份

性能最大化，fork出一个子进程来操作，对主进程没有影响

数据比较多时，相对于aof启动效率比较高

缺点：

会造成数据丢失

AOF模式：

同步策略：

everysec：每秒同步一次（默认）

always:每次操作后都要同步一次

no:由操作系统调度进行同步

重写策略：

会自动筛选出有意义的命令，把过程命令省略掉，生成新的AOF文件

手动触发重写

手动触发，执行bgrewiteaof命令

自动触发重写

auto-aof-rewrite-percentage:当前AOF文件大小和最后一次重写后的大小之间的比例等于或等于指定的增长百分比，如100代表64mb+64*100%就能触发重写

auto-aof-rewrite-min-size:当AOF文件大小大于该值时候才可能重写

优点：

数据安全，不会造成数据的丢失

缺点：

比rdb重启效率低，运行效率比rdb低

文献：Redis持久化AOF详解_aof-use-rdb-preamble_shark-chili的博客-CSDN博客

---

Redis过期时间的判定 

在Redis内部，每当我们设置一个键的过期时间时，Redis就会将该键带上过期时间存放到一个过期字典中。当我们查询一个键时，Redis便首先检查该键是否存在过期字典中，如果存在，那就获取其过期时间。然后将过期时间和当前系统时间进行比对，比系统时间大，那就没有过期；反之判定该键过期。

过期键删除策略

Redis设置key时，都会设置一个过期时间，那么当过期时间到了，怎么处理

Redis同时使用了惰性过期和定期过期

惰性过期：

只有当这个key被访问时，才会判断是否过期，过期则清除掉。它可以节省cpu的资源，但是会浪费内存的资源，会出现大量过期的key没有被访问过，从而不会被清除，导致内容占用越来越大

定期过期：

每间隔一段时间，扫描一定数量的设置了过期时间的key,假如过期了则删除

Redis 默认每秒进行10次过期扫描：

1.从过期字典种随机20个key

2.删除这20个key中已过期的

3.如果超过25%的key过期，则重复第一步

同时，为了保证业务不受影响，Redis还设置了扫描的时间上限，默认不会超过25ms

---

内存淘汰策略：

假如内存不足时，redis会根据设置的淘汰策略，删除一些不常用的数据，保证redis的正常使用

• noeviction:当内存使用超过配置的时候会返回错误，不会驱逐任何键（默认）
• allkeys-lru：加入键的时候，如果过限，首先通过LRU算法驱逐最久没有使用的键
• volatile-lru：加入键的时候如果过限，首先从设置了过期时间的键集合中驱逐最久没有使用的键
• allkeys-random：加入键的时候如果过限，从所有key随机删除
• volatile-random：加入键的时候如果过限，从过期键的集合中随机驱逐
• volatile-ttl：从配置了过期时间的键中驱逐马上就要过期的键
• volatile-lfu：从所有配置了过期时间的键中驱逐使用频率最少的键
• allkeys-lfu：从所有键中驱逐使用频率最少的键

  ---

  LRU最近最少使用

根据最近被使用的时间，离当前最远的数据优先被淘汰

LFU 最不经常使用 

前保存时间，后保存访问频率【为防止溢出采用逻辑函数计算】