详谈redis数据持久化（RDB、AOF）

通过在 redis-cli 客户端中执行 save 命令可立即进行一次持久化保存。 save 命令在执行期间会阻塞 redis-server 进程，直至持久化过程完毕。而在 redis-server 进程阻塞期间， Redis 不能处理任何读写请求，无法对外提供服务。

(2) 手动 bgsave 命令

通过在 redis-cli 客户端中执行 bgsave 命令可立即进行一次持久化保存。不同于 save 命令的是，正如该命令的名称一样， background save ，后台运行 save 。 bgsave 命令会使服务器进程 redis-server 生成一个子进程，由该子进程负责完成保存过程。在子进程进行保存过程中，不会阻塞 redis-server 进程对客户端读写请求的处理。

自动触发

Redis内部有触发RDB的机制，可以在redis.conf文件中找到, 默认配置如下：

可以根据需求，手动修改，如下：

redis 配置文件 save 指令设置： 
save 3600 1        # 3600秒内如果超过1个key被修改则生成 RDB
save 300 100       # 300秒内如果超过100个key被修改则生成 RDB
save 60 10000      # 60秒内如果超过10000个key被修改则生成 RDB

自动条件触发的本质仍是 bgsave 命令的执行。只不过是用户通过在配置文件中做相应的设置后， Redis 会根据设置信息自动调用 bgsave 命令执行。具体配置方式，后面会详解

查看持久化时间

4.1.3 RDB的执行原理

bgsave开始时会fork（复制）主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

4.2 AOF

4.2.1 什么是AOF

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

4.2.2 开启和配置AOF

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF

在redis.conf文件里修改以下配置：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

4.2.3 AOF优化——重写功能

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

4.3混合持久化机制

redis在4，0版本引入了混合持久化机制，重启redis时会先加载RDB文件来快速恢复大部分数据，再重放AOF增量部分来保证数据的完整性，这种方式结合了两者的优点，兼顾恢复速度与数据安全性。

5. RDB和AOF对比

6. 面试回答★

6.1 redis做为缓存，数据的持久化是怎么做的？（一次性回答）

        redis自身存在两种方案，分别叫RDB和AOF，以此来保障数据的持久化。其中RDB默认开启AOF默认关闭。

        RDB全称Redis Database Backup file，即Redis数据备份文件，也被叫做Redis数据快照。它整个是个二进制文件，在保存的时候，文件体积是比较小，恢复数据的速度快，但是它有可能会丢数据。

        AOF全称是Append Only File。Redis处理的每一个写命令都会记录在这个AOF文件中，可以看做是一个命令日志文件。它整个文件的体积会比较大，当redis实例岩机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复数据，所以恢复数据的速度会慢一些，但是它丢数据的风险要小很多。一般在实际开发中我们都是结合两者去使用的。