本文共 3267 字，大约阅读时间需要 10 分钟。
文章目录
一、什么是持久化
将数据从掉电易失的内存存放到能够永久存储的设备上
二、Redis持久化方式
- 1.RDB（Redis DB）：类似于hdfs中的fsimage
- 2.AOF（AppendOnlyFile）：类似于hdfs中的edit logs，默认关闭
三、RDB
在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中
1.RDB的2种执行方式
a. 阻塞方式：
客户端中执行save命令，服务器需要停服，然后生成名为dump.rdb的二进制文件（可以通过改名来保留历史版本），不适用于生产环境，但并不绝对，像银行、股票等会这么操作。
b. 非阻塞方式：
bgsave（异步命令，采用copy on write），生产环境使用，无需停服。
2.策略
-
自动：按照配置文件中的条件满足就执行BGSAVE
-
手动：客户端发起SAVE、BGSAVE命令
自动化执行的本质，就是BGSAVE。默认配置：
save 900 1 save 300 10 save 60 1000 #Redis要满足在60秒内至少有1000个键被改动，会自动保存一次 dbfilename dump.rdb dir /var/lib/redis/6379
RDB文件一经创建，时间计数器、次数计数器都会清零。因此，多个条件的效果不是叠加的。
3.save命令怎么做？
阻塞Redis服务，无法响应客户端请求。创建新的dump.rdb替代旧文件
4.bgsave命令怎么做？
非阻塞，Redis服务正常接收处理客户端请求（bgsave命令）。Redis会fork()一个新的子进程来创建RDB文件（不会开辟真实的内存占用，只需要拷贝父进程的数据的引用拷贝到子进程。只拷贝指针，而非拷贝所有数据。指针指向子进程中数据的值），子进程处理完后会向父进程发送一个信号，通知它处理完毕。父进程用新的dump.rdb替代旧文件
5.save 和 bgsave 命令对比
- SAVE不用创建新的进程，速度略快
- BGSAVE需要创建子进程，消耗额外的内存
- SAVE适合停机维护，服务低谷时段
- BGSAVE适合线上执行
四、AOF
Append only file，采用追加的方式保存，默认文件appendonly.aof，记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库
调整AOF持久化策略，可以在服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于RDB损失小得多 1.AOF写入机制
AOF方式不能保证绝对不丢失数据
目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失
2.写入磁盘的策略
appendfsync选项，这个选项的值可以是always、everysec或者no
- always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
- everysec（默认）：服务器每一秒就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
- no：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的
运行速度：always的速度慢，everysec和no都很快
3.AOF重写机制
- AOF文件过大
- 合并重复的操作，AOF会使用尽可能少的命令来记录（如set msg hello——>set msg hello world，重写的时候直接set msg hello world,为了缩短时间）
4.重写过程
Tip：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复
5.AOF重写触发
- 手动：客户端向服务器发送BGREWRITEAOF命令
- 自动：配置文件中的选项，自动执行BGREWRITEAOF命令
-
①auto-aof-rewrite-min-size ，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写死循环
-
②auto-aof-rewrite-percentage ，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写
-
6.AOF重写配置项举例
auto-aof-rewrite-percentage 100 #只有当AOF文件的增量大于起始size的100%时（就是文件大小翻了一倍），启动重写auto-aof-rewrite-min-size 64mb #当AOF文件大于64MB时候，可以考虑重写AOF文件appendonly no / yes #默认关闭，请开启
auto-aof-rewrite-percentage这个参数就是为了避免重写陷入无限死循环。当满了64MB后出发重写，精简。假设精简后为32MB，替换原来的文件。然后这个32MB的文件待会就又会满了64MB，又要交给子进程精简了，此时此刻，64MB的文件中已经有32MB是已经精简过的了，只会精简剩下的32MB。如此往复，最终64MB肯定会在某一刻是完全精简版的，无非再精简了，于是，就陷入了死循环。此时该考虑的就是扩容，也就是调整百分比。
总结
反观两种持久化方式，对比他们的优缺点：
1.RDB
优点：
- 完全备份，不同时间的数据集备份可以做到多版本恢复
- 紧凑的单一文件，方便网络传输，适合灾难恢复
- 恢复大数据集速度较AOF快
缺点：
- 会丢失最近写入、修改的而未能持久化的数据
- fork过程非常耗时，会造成毫秒级不能响应客户端请求
2.AOF
优点：
- 写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据 *重写机制，优化AOF文件
- 如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态
缺点：
- 相同数据集，AOF文件体积较RDB大了很多
- 恢复数据库速度比RDB慢（文本，命令重演）
发表评论
最新留言
关于作者
