Redis持久化（RDB、AOF、混合持久化）

save：save 命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
bgsave：bgsave 命令会 fork 一个子进程（注意是子进程，不是子线程）在后台生成快照文件，不会阻塞 Redis 服务器，服务器进程（父进程）可以继续处理命令请求。

当客户端发服务发出bgsave命令时，Redis服务器主进程会forks一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出

简而言之RDB持久化的步骤：

Redis会定期fork一个子进程
子进程会首先将数据集写入一个临时文件
当临时文件写入完成后，Redis会用这个临时文件替换上次持久化的

配置示例：

RDB可以通过配置自动触发快照的频率，例如在N秒内执行了M次写操作时

在Redis配置文件（redis.conf）中配置RDB的保存方式和频率，如下所示：

save 900 1         # 在900秒内，如果至少有1个键被修改，则执行一次RDB快照
2save 300 10        # 在300秒内，如果至少有10个键被修改，则执行一次RDB快照
3save 60 10000      # 在60秒内，如果至少有10000个键被修改，则执行一次RDB快照

（2）AOF

AOF（Append Only File）：记录每次对数据的操作到硬盘上

AOF持久化是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了。AOF解决了数据持久化的实时性，也是目前主流的Redis持久化方式，采用先写内存，后写日志

优点：数据更加持久，可以保证每一条写入命令都被持久化

缺点：生成的AOF文件较大，恢复数据的速度相对较慢

配置示例：

appendonly yes                # 启用AOF持久化
appendfsync everysec          # 每秒钟将写操作同步到AOF文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

从持久化中恢复数据

如果选择持久化方案，可以这样选择：

业务对于数据丢失不敏感，选 RDB
业务对数据完整性要求比较高，选 AOF

如果一台服务器上有既有RDB文件，又有AOF文件，该加载谁呢？==>优先AOF

数据的备份、持久化做完了，我们如何从这些持久化文件中恢复数据呢？

其实想要从这些文件中恢复数据，只需要重新启动Redis即可

📌选择合适的持久化方式

🔴RDB 通常用于需要快速恢复数据的情况，因为它只需要加载一个文件即可恢复数据。

🔴AOF 更适合需要更高数据完整性的场景，因为它可以记录每一次写操作，从而提供接近实时的数据恢复能力。

2、混合持久化

RDB、AOF持久化都有所弊端：

RDB 持久化能够快速地储存和恢复数据，但是在服务器停机时可能会丢失大量数据。
AOF 持久化能够有效地提高数据的安全性，但是在储存和恢复数据方面却要耗费大量的时间

为了让用户能够同时拥有上述两种持久化的优点

Redis 4.0 中提出了 RDB-AOF 混合持久化，混合使用 AOF日志和内存快照的方法

简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作

类似下面这样：

这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作

也就是说，不需要记录所有操作了，就不会出现文件过大的情况了，也可以避免重写开销

配置方式：

appendonly yes。           # 启用AOF持久化
aof-use-rdb-preamble yes

3、总结

Redis 需要持久化主要是为了保证数据的安全性和持久性，防止数据丢失

Redis 持久化功能默认是开启的，这样做的目的也是为了保证程序的稳定性，防止缓存雪崩、缓存击穿等以及保证数据不丢失。

若要手动关闭 Redis 持久化，需要将 RDB、AOF 和混合持久化全部关闭才行，并且关闭之后需要重启 Redis 服务才能生效