Redis 学习笔记2：持久化

目录

• 1 什么是持久化
  • 1.1 aof
  • 1.2 rdb
• 2 RDB持久化
  • 2.1 RDB 是什么
  • 2.2 手动触发
• 3 AOF持久化
  • 3.1 aof 是什么
  • 3.2 appendfile 文件说明：
  • 3.3 aof 重写机制
  • 3.4 redis 4.0 后混合持久化机制
• 4 AOF和RDB的总结
  • 1、redis提供了rdb持久化方案，为什么还要aof？
  • 2、如果aof 和rdb同时存在，听谁的？
  • 3、rdb和aof的优劣势
    • 1 RDB：
    • 2 AOF：
  • 4、性能建议（只针对单机版redis持久化做性能建议）：

1 什么是持久化

Redis 支持RDB和AOF 两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题。当下次重启时利用之前持久化的数据快照文件即可实现数据恢复。

配置文件：

save 100 时间，单位是s，100s内修改1次就会做更新

1.1 aof

aof 实时存储：

1、aof的参数

• dir 存储路径 /. 表示在哪里启动，文件在哪里生成
• appendonly：默认no，如果设置为yes，就打开了实时存储
• appendfilename 存储文件的名字

1.2 rdb

rdb 定时存储：

1、rdb 的参数

• dir 存储路径 /. 表示在哪里启动，文件在哪里生成
• rdbdfilename 存储文件的名字

2、风险：容易丢失数据；避免风险：使用aof 实时存储

3、如果数据没有那么重要，可以使用rdb。

2 RDB持久化

是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

2.1 RDB 是什么

RDB在指定的时间间隔内将内存中的数据集快照写入磁盘。

原理是redis 会单独创建（fork）一个与当前进程一模一样的子进程来进行持久化，这个子进程的所有数据（变量，环境变量，程序计数器等）都和原进程一模一样，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，是一个全量的过程。

整个过程，主进程不进行任何的io操作，这就确保了极高的性能。

问题1：这个持久化文件在哪里？

rdb有两个参数：

• dir 存储路径 /. 表示在哪里启动，文件在哪里生成
• rdbdfilename 存储文件的名字

问题2：它什么时候fork子进程，或者什么时候触发rdb持久化机制？

1. shutdown时，如果没有开启aof，会触发。
2. 配置文件中默认的快照配置 :

• save 900 1 900秒内执行1次增删改 就会触发rdb
• save 300 10 300秒内执行10次增删改 就会触发rdb
• save 60 10000 60秒内执行10000次增删改 就会触发rdb
• 如果是集群的话，master就会把这些关掉（注释掉）

1. 执行命令 save 或者 bgsave ：

• save只保管，其他不管，全部阻塞；
• bgsave redis会在后台异步进行快照操作，同时可以响应客户端的请求。
  
  1.执行flushall命令，但是里面是空的，无意义。（清空16个数据库的数据）

2.2 手动触发

手动触发分别对应save和bgsave命令。

• ·save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
• ·bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

3 AOF持久化

3.1 aof 是什么

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不记录，以文本的方式记录，可以打开文件看到详细的操作记录。是以增量的方式进行持久化，即一点点的进行持久化，不是一下子把所有数据都记录下来。

原理是将redis的操作日志以追加的方式写入文件，读操作不记录下来。

如：set k1 1 写到文件，再运行这个文件，所有写操作都做一遍。

问题1： 这个持久化文件在哪里？

aof的参数：

• dir 存储路径 /. 表示在哪里启动，文件在哪里生成
• appendonly：默认no，如果设置为yes，就打开了实时存储
• appendfilename 存储文件的名字

问题2： 触发机制是什么？

根据配置文件配置项：

• no：表示等操作系统进行数据缓存同步到磁盘（快，持久化没保证）
• always：同步持久化，每次发生数据变更时，立即记录到磁盘（慢，安全）
• everysec：表示每秒同步一次（快，但是可能会丢失1s的数据）

3.2 appendfile 文件说明：

*2     说明下面有2组命令，*
$6     代表长度为6，$
SELECT
0      代表数据放入0库
*3
$3
set
$2
kk
$2
vv

3.3 aof 重写机制

1. 当AOF文件增长到一定大小的时候，redis能够调用bgrewriteaof对日志文件进行重写。当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。

auto-aof-rewrite-percentage 100

1. 当AOF文件增加到一定大小的时候，redis能够调用bgrewriteaof对日志文件进行重写。当AOF文件大小大于该配置项时自动开启重写。

auto-aof-rewrite-min-size 64mb

bgrewriteaof 是重写的命令

3.4 redis 4.0 后混合持久化机制

1. 4.0 版本的混合持久化默认关闭，通过 auto-use-rdb-preamble 配置参数控制。

• yes 表示开启，no 表示禁用。

1. 5.0 之后默认开启。
   
   混合持久化是通过 bgrewriteaof 完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后再将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的AOF文件。

简单说：新的AOF文件前半段是RDB格式的全量数据；后半段是AOF格式的增量数据。

优点：混合持久化结合了RDB持久化和AOF持久化的优点，由于绝大部分都是RDB格式，加载速度快，同时结合AOF。增量的数据以AOF方式保存了，数据更少丢失。

缺点：兼容性差，一旦开启了混合持久化，在4.0之前版本都不能识别该aof文件，同时由于前部分是RDB格式，阅读性比较差。

4 AOF和RDB的总结

1、redis提供了rdb持久化方案，为什么还要aof？

优化数据丢失问题，rdb会丢失最后一次快照后的数据，aof丢失不会超过2s的数据。

2、如果aof 和rdb同时存在，听谁的？

aof

3、rdb和aof的优劣势

1 RDB：

使用RDB好处：

1. redis 数据库只有这一个文件，方便备份，可以很容易将一个RDB文件移动到其他存储介质上。
2. RDB恢复大数据集的速度比AOF快。
3. RDB可以最大化redis的性能：父进程在保存RDB文件时唯一要做的就是 fork 一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘 I/O 操作。

使用RDB坏处：

1. 需要尽量避免在服务区故障时丢失数据，虽然redis 允许设置不同的save point 来控制保存RDB文件的频率，但是RDB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。你可能会至少五分钟才保存一次RDB文件，在这种情况下，一旦发生故障停机，就会丢失好几分钟的数据。
2. 每次保存RDB的时候，Redis都要fork() 出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大地时候，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且CPU时间非常紧张，那么这种停止时间甚至可能会长达整整一秒。虽然AOF重写也需要进行 fork() ，但是无论AOF重写的执行间隔有多长，数据的耐久性都不会有任何损失。

总结RDB：

rdb适合大规模数据恢复，对数据完整性和一致性不高，在一定间隔时间做一次备份，如果redis意外down机的话，就会丢失最后一次快照后的所有操作。

2 AOF：

使用AOF的好处：

1. 让redis变得非常耐久（nuch nore durable）
   
   2.AOF文件是一个只进行追加操作的日志文件（append only log），因此对AOF文件的写入不需要进行 seek，即使日志因为某些原因而包含未写入完整的命令（比如写入时磁盘已满，写入中途停机等），redis-check-aof 工具也可以轻易地修复这种问题。
   
   3.redis 可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写，重写后的新 AOF 文件包含了恢复当前数据集所需要的最小命令集合。重写操作绝对安全。
2. AOF 文件有序地保存了对数据库执行的所有的写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析也很轻松，导出AOF也很简单。

使用AOF的坏处：

1. 对于相同的数据集来说，AOF 文件的体积通常要大于RDB文件的体积
2. 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。
3. 在处理巨大的写入载入时，RDB可以提供更有保证的最大延迟时间。

官方建议：两种方式同时开启，优先使用aof。

4、性能建议（只针对单机版redis持久化做性能建议）：

1. 因为RDB文件只用作后备用途，只要15min备份一次就够了，只保留 save 900 1 这条规则。
2. 如果Enable AOF，好处就是在最恶劣情况下也只会丢失不超过2s的数据，启动脚本较简单，只load自己的aof文件就可以了。
3. 代价一是带来了持续的IO，二是AOF rewrite 的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎不可避免。
4. 只要硬盘许可，应该尽量减少AOF rewrite 频率，AOF 重写基础可以设到5G以上。