Redis 持久化

一、Redis 持久化

​ Redis 提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。RDB，简而言之，就是在不同的时间点，将 Redis 存储的数据生成快照并存储到磁盘等介质上；AOF，则是换了一个角度来实现持久化，那就是将 Redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。其实 RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 Redis 重启的话，则会优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高。如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变成一个纯内存数据库，就像 memcache 一样。

1、为什么需要持久化？

1. 将数据存储到硬盘是为了以后可以重用数据，将数据进行备份。
2. redis的数据都是存放到内存中的，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证redis在内存中的数据不会丢失，这种机制就叫redis持久化机制。

2、持久化的方式

Redis提供两种不同的持久化方式:

• 快照持久化（RDB）:是将 redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
• 持久化（AOF）:英文是 Append Only File，即只允许追加不允许改写的文件。AOF 方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

二、RDB持久化

1、执行命令

1. Save命令：将内存数据镜像保存为rdb文件，是由于Redis单线程模型，期间会阻塞Redis的服务进程，Redis就不处理任何指令，直到rdb文件执行完成。
2. Bgsave命令：父进程启动一个子进程，由子进程将内存数据保存到硬盘上，处理期间不会影响其他指令。
3. 通过配置自动触发Bgsave命令的原理计数器记录了在上一次成功持久化后，redis进行了多次操作，其值在每次操作后都会加1，在完成持续化时清零。

2、RDB的优点

• RDB是一个紧凑压缩的二进制文件，代表数据在某一个时间点的快照。非常适合备份，全景复制。比如每三个小时执行bgsave备份，并把RDB文件上传到备份服务器中，用于防止Redis服务器不可恢复性问题。
• RDB恢复数据速度快于AOF的方式。

3、RDB缺点

• RDB方式没有办法做到实时、秒级别的持久化。因为bgsave每次运行都要fork操作创建子线程，是一个重量级的操作，操作频繁成本比较高。
• RDB文件是一个中特制的二进制文件，涉及到不同的Redis版本可能会发生老版本无法兼容新版本。

三、AOF持久化

1、AOF三个步骤

修改config中的配置appendonly yes

2、追加方式

1. appendfsync always： 只要有读写的时候

2. appendfsync everysec ：1秒钟周期

3. appendfsync no：当业务不繁忙的时候，这种是最不可靠的

AOF	类型	安全性	性能
appendfsync	always	低	高
appendfsync	everysec	比较高	比较高
appendfsync	no	高	低

3、AOF为什么需要重写？

1. 重写后文件，占用空间资源会变小。
2. 进程内超时的数据不再写入到AOF文件中。
3. 文件包含已删除命令。
4. 重复命令，合并为一个。

4、AOF的重写过程

1. 父进程执行fork()，创建一个子进程。
2. 父进程处理客户端请求，父进程把所有修改命令会写入到aof_rewrite_buf中，并根据redis配置文件策略持久化到AOF文件中。
3. 子进程把新AOF文件写入完成后，子进程传递通讯消息给父进程，父进程更新信息。

四、Redis持久化终极方案

在开发中我们很少使用rdb来恢复内存状态，因为这样会丢失大量的数据，经常会使用AOF进行重放指令操作，这将是一个漫长的过程，需要花费很长的时间。Redis4.0引入了一个新的持久化选项——混合持久化，先读取快照进行恢复，然后读取增量的AOF日志，这里的AOF是继上一次产生快照后，产生的增量日志，不再是以前的全量日志。

参考官方文档：Redis 持久化