Redis 基础详解

六、Redis 持久化

持久化概念：意外断电或重启之后，内存的数据会丢失，所以内存的数据要保存到磁盘中。利用磁盘等将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制就叫做持久化

持久化方式：

• 快照（ RDB ）：将某个时间点的工作状态保存下来，恢复时可直接恢复指定时间点的工作状态
• 日志（ AOF ）：将对数据的所有操作过程记录下来，恢复数据时重新执行这些操作

1、RDB 快照

基本概念

在默认情况下，Redis 将内存数据库快照保存到名字为 dump.rdb 的二进制文件中。

你可以对 Redis 进行设置，让他在 “ N 秒内数据集至少有 M 个改动 ” 这一条件被满足时，自动保存一次数据集。

例如：以下设置会让 Redis 在满足 “ 60 秒内有之少 1000 个键被改动 ” 这一条件时，自动保存一次数据集

save

# save 60 1000 // 关闭RDB只需要将所有的save保存策略注释掉即可

还可以手动执行命令生成 RDB 快照，进入 Redis 客户端执行命令 save 或 bgsave 可以生成 dump.rdb 文件，每次命令执行都会将所有 Redis 内存快照到一个新的 RDB 文件里，并覆盖原有 RDB 快照文件。

bgsave

bgsave 的写时复制（ COW ）机制

Redis 借助操作系统提供的写时复制技术 ( Copy-On-Write,COW )，在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入RDB文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

	  |--1、发送指令-->|		 |--2、调用fork函数，生成子进程-->|      |--3、创建rdb文件-->|	
bgsave| 			  |	redis|							     |redis|				  |.rdb
	  |<--2、返回消息--|		 |<--------2、返回消息------------|	   |				  |

save 与 bgsave 对比：

配置自动生成rdb文件后台适用的是bgsave方式

2、AOF（ Append-Only File ）

快照功能并不是非常耐久 ( durable )：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。

从1.1版本开始，Redis 增加了一种完全耐久的持久化方式：AOF持久化，将修改的每一条指令记录进文件 appendonly.aof 中 ( 先写入 os cache，每隔一段时间 fsync 到磁盘 )

AOF 以日志的方式记录每次操作的命令，重启之后执行 AOF 中保存的命令恢复数据，较为主流

比如执行命令 set zs 666，AOF 文件里会记录如下数据

*3
$3
set
$2
zs
$3
666

这是一种resp协议格式数据，星号后面的数字代表命令有多少个参数，$ 号后面的数字代表这个参数有几个字符

注意：如果执行带过期时间的 set 命令，AOF 文件里记录的并不是执行的原始命令，而是记录 key 过期的时间戳

比如执行 set zs 888 ex 1000，对应 AOF 文件里记录如下

*3
$3
set
$2
zs
$3
888
*3
$9
PEXPIREAT
$2
zs
$13
1604249786301

可以通过修改 redis.conf 配置文件来打开 AOF 功能：

# appendonly yes

从现在开始，每当 Redis 执行一个改变数据集的命令时 ( 比如 SET )，这个命令就会被追加到 AOF 文件的末尾。

这样的话，当 Redis 重新启动时，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三个选项：

appendfsync always：每次有新命令追加到AOF文件时就执行一次fsync,非常慢,也非常安全。
appendfsync everysec：每秒fsync 一次,足够快,并且在故障时只会丢失1秒钟的数据。[推荐]
appendfsync no：从不fsync，将数据交给操作系统来处理。更快，也更不安全的选择

推荐 ( 并且也是默认 ) 的措施为每秒 fsync 一次，这种 fsync 策略可以兼顾速度和安全性。

AOF 文件里可能有太多没用指令，所以 AOF 会定期根据内存的最新数据生成 aof 文件

例如，执行了如下几条命令:

127.0.0.1:6379> incr readcount
(integer) 1
127.0.0.1:6379> incr readcount
(integer) 2
127.0.0.1:6379> incr readcount
(integer) 3
127.0.0.1:6379> incr readcount
(integer) 4
127.0.0.1:6379> incr readcount
(integer) 5

重写后 AOF 文件里变成

*3
$3
SET
$2
readcount
$1
5

如下两个配置可以控制 AOF 自动重写频率

# auto-aof-rewrite-min-size 64mb   //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
# auto-aof-rewrite-percentage 100  //aof文件自上一饮次重写后文件大小增长了100%则再次触发重写

当然 AOF 还可以手动重写，进入 Redis 客户端执行命令 bgrewriteaof 重写 AOF

注意：AOF 重写 Redis 会 fork 出一个子进程去做（ 与 bgsave 命令类似 ），不会对 Redis 正常命令处理有太多影响

3、RDB 和 AOF，该怎么选？

生产环境可以都启用，Redis 启动时如果既有 RDB 文件又有 AOF 文件则优先选则 AOF 文件恢复数据，因为 AOF 一般来说数据更安全一点