Redis持久化

一、 文档介绍

     redis作为一个内存数据库，读写快，效率高，但是也会有宕机丢失数据的风险，于是就需要持久化操

     Q&A：      

     数据量大于内存大小时应该怎么做？

     增加内存or采用内存淘汰策略orRedis集群

     持久化会辅助扩大Redis的存储空间么？

     不会，持久化的主要作用是数据备份，保证数据不会因进程退出而丢失

     （在dump的基础上开始准备Restore的实现，dump操作的第一步就是将aof文件内的记录同步到redis内，故了解一下aof文件）

二、RDB与AOF持久化的原理

2.1 RDB

RDB可以认为是Snapshot文件，当恢复时，通过加载RDB文件。把数据从磁盘加载读取到Redis中。

RDB产生：（考虑快照时的操作）

• SAVE方式：阻塞请求
• BGSAVE：fork一个子进程，子进程将快照写到一个临时的RDB文件，写完之后替换旧的RDB文件

RDB的加载：

Redis持久化可以禁用，此时数据仅存在于服务器的运行时间内

Redis持久化也可以共存，当同时存在的时候，Redis重启是会先加载AOF文件

2.2 AOF

AOF可以认为是日志文件，Append only File，每次对数据的变更或者操作都会先记录打AOF内，当服务启动的时候就会先读取这些文件，重新执行一遍来恢复原始数据。

AOF提供三种同步（写aof文件与操作数据的同步）的方式：

• always：每次操作记录都同步到磁盘上，最低效，最安全
• everysec：每秒执行一次将操作记录同步到磁盘。默认
• no：不自动执行同步，让操作系统将缓存数据写到硬盘上，不可靠，最快

AOF文件的格式与解析：

• *，表示命令的参数个数，例如上面的set a 1 是三个 因此为*3
• ¥，表示参数的字节数，例如a这个参数是一个字节，因此为$1
• 无符号，表示是参数数据

AOF优化：（重写）

当对一个现在为0的值执行100遍“a++”操作的话，如果每一次都记录一个操作再同步，非常浪费资源与时间，并且文件也会变大，重写即将这一百条数据写成set a 100，减少文件大小，并且提高载入速率

三、RDB与AOF的优缺点

3.1 RDB

优点：

• RDB是某一个时间点的备份，是一个紧凑的单文件，多用于数据备份。可以按每小时或每日来备份，方便从不同的版本恢复
• 单文件方便远程传输便于故障恢复
• RDB可以Fork子进程进行持久化，使得Redis可以更好的处理用户的请求
• 在数据量大的情况下，RDB相比较于AOF加载的更快

缺点：

• 如果RDB保存不及时会导致数据丢失
• RDB经常需要Fork子进程去执行，fork操作十分耗费CPU，并且是全量的，AOF的Fork是增量的，并且AOF是可控的

3.2 AOF

优点：

• AOF可以设置 完全不同步、每秒同步、每次操作同，默认是每秒同步。因为AOF是操作指令的追加，所以可以频繁的大量的同步。
• AOF文件是一个值追加日志的文件，即使服务宕机为写入完整的命令，也可以通过redis-check-aof工具修复这些问题。
• 如果AOF文件过大，Redis会在后台自动地重写AOF文件。重写后会使AOF文件压缩到最小所需的指令集。
• AOF文件是有序保存数据库的所有写入操作，易读，易分析。即使如果不小心误操作数据库，也很容易找出错误指令，恢复到某个数据节点。例如不小心FLUSHALL，可以非常容易恢复到执行命令之前。

缺点：

• 相同数据量下，AOF的文件通常体积会比RDB大。因为AOF是存指令的，而RDB是所有指令的结果快照。但AOF在日志重写后会压缩一些空间。
• 在大量写入和载入的时候，AOF的效率会比RDB低。因为大量写入，AOF会执行更多的保存命令，载入的时候也需要大量的重执行命令来得到最后的结果。RDB对此更有优势。

三、取舍

    一般来说，不考虑硬盘大小，最安全的做法是RDB与AOF同时使用，即使AOF损坏无法修复，还可以用RDB来恢复数据。

    如果Redis的数据在你的服务中并不是必要的数据，例如只是当简单的缓存，没有缓存也不会造成缓存雪崩。说明数据的安全可靠性并不是首要考虑范围内，那么单独只使用RDB就可以了。

    不推荐单独使用AOF，因为AOF对于数据的恢复载入来说，比RDB慢。

Redis持久化

原文：https://www.cnblogs.com/Flower-Z/p/10691441.html