Redis是一个内存数据库，所以其运行效率非常高。但也存在一个问题：内存中的数据是不持久的，若 主机宕机 或 Redis 关机重启，则内存中的数据全部丢失。
当然，这是不允许的。 Redis 具有持久化功能，其会按照设置以 快照 或 操作日志 的形式将数据持久化到磁盘。
根据持久化使用技术的不同，Redis 的持久化分为两种： RDB（Redis DataBase） 与 AOF （Append Only File）。
Redis有两种持久化方案：
- RDB持久化
- AOF持久化
1.RDB持久化
RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。
当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。
1.1 执行时机
RDB持久化在四种情况下会执行：
- 执行save命令
- 执行bgsave命令
- Redis停机时
- 触发RDB条件时
1）save命令
执行下面的命令，可以立即执行一次RDB：
$ redis-cli
127.0.0.1:6379> save # 有Redis的主进程来执行RDB,会阻塞所有的命令
ok
save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。
2）bgsave命令
下面的命令可以异步执行RDB：
127.0.0.1:6379> BGSAVE
Background saving started
这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。
3）停机时
Redis停机时会执行一次save命令，实现RDB持久化。
4）触发RDB条件
Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：
# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1
# 在 300 秒 (5 分钟) 内发生 10 次写操作
save 300 10
# 在 60 秒 (1 分钟) 内发生 1 万次写操作
save 60 10000
RDB的其它配置也可以在redis.conf文件中设置：
# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
1.2 RDB原理
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术：
- 当主进程执行读操作时，访问共享内存；
- 当主进程执行写操作时，则会拷贝一份数据，执行写操作。
1.3 RDB小结
RDB方式bgsave的基本流程？
- fork主进程得到一个子进程，共享内存空间
- 子进程读取内存数据并写入新的RDB文件
- 用新RDB文件替换旧的RDB文件
RDB会在什么时候执行？save 60 1000代表什么含义？
- 默认是服务停止时
- 代表60秒内至少执行1000次修改则触发RDB
RDB的缺点？
- RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
- fork子进程、压缩、写出RDB文件都比较耗时
2.AOF持久化
2.1 AOF原理
AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。
2.2 AOF配置
AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF的命令记录的频率也可以通过redis.conf文件来配：
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
三种策略对比：
2.3 AOF文件重写
因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
如图，AOF原本有三个命令，但是set num 123 和 set num 666都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。
所以重写命令后，AOF文件内容就是：mset name jack num 666
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
3.RDB与AOF对比
RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。
4.Redis 4.0 混合持久化
4.1 混合持久化原理
重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。
Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。
于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。
混合持久化的加载流程如下：
4.2 混合持久化配置
在redis的配置文件当中有一个aof-use-rdb-preamble参数来开启 混合持久化，默认是yes开启的。混合持久化结合了 RDB 和 AOF 的优点，Redis 5.0 默认是开启的。
4.3 混合持久化优缺点
优点：
混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF的优点，有减低了大量数据丢失的风险。
缺点：
- AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
- 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。
评论区