共计 4535 个字符，预计需要花费 12 分钟才能阅读完成。
这篇文章主要介绍“怎么使用快照和 AOF 将 Redis 数据持久化到硬盘中”，在日常操作中，相信很多人在怎么使用快照和 AOF 将 Redis 数据持久化到硬盘中问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么使用快照和 AOF 将 Redis 数据持久化到硬盘中”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
前言
我们知道 Redis 是一款内存服务器，就算我们对自己的服务器足够的信任，不会出现任何软件或者硬件的故障，但也会有可能出现突然断电等情况，造成 Redis 服务器中的数据失效。因此，我们需要向传统的关系型数据库一样对数据进行备份，将 Redis 在内存中的数据持久化到硬盘等非易失性介质中，来保证数据的可靠性。
将 Redis 内存服务器中的数据持久化到硬盘等介质中的一个好处就是，使得我们的服务器在重启之后还可以重用以前的数据，或者是为了防止系统出现故障而将数据备份到一个远程的位置。
还有一些场景，例如：
对于一些需要进行大量计算而得到的数据，放置在 Redis 服务器，我们就有必要对其进行数据的持久化，如果需要对数据进行恢复的时候，我们就不需进行重新的计算，只需要简单的将这台机器上的数据复制到另一台需要恢复的 Redis 服务器就可以了。Redis 给我们提供了两种不同方式的持久化方法：快照（Snapshotting）和 只追加文件（append-only-file）。
（1）名词简介
快照（RDB）：就是我们俗称的备份，他可以在定期内对数据进行备份，将 Redis 服务器中的数据持久化到硬盘中；
只追加文件（AOF）：他会在执行写命令的时候，将执行的写命令复制到硬盘里面，后期恢复的时候，只需要重新执行一下这个写命令就可以了。类似于我们的 MySQL 数据库在进行主从复制的时候，使用的是 binlog 二进制文件，同样的是执行一遍写命令；
（2）快照持久化通用的配置：
save 60 1000 #60 秒时间内有 1000 次写入操作的时候执行快照的创建 stop-writes-on-bgsave-error no #创建快照失败的时候是否仍然继续执行写命令 rdbcompression yes #是否对快照文件进行压缩 dbfilename dump.rdb #如何命名硬盘上的快照文件 dir ./ # 快照所保存的位置 （3）AOP 持久化配置：
appendonly no #是否使用 AOF 持久化 appendfsync everysec #多久执行一次将写入内容同步到硬盘上 no-appendfsync-on-rewrite no #对 AOF 进行压缩的时候能否执行同步操作 auto-aof-rewrite-percentage 100 #多久执行一次 AOF 压缩 auto-aof-rewrite-min-size 64mb # 多久执行一次 AOF 压缩 dir ./ #AOF 所保存的位置 需要注意的是：这两种持久化的方式既可以单独的使用，也可以同时使用，具体选择哪种方式需要根据具体的情况进行选择。
快照持久化
快照就是我们所说的备份。用户可以将 Redis 内存中的数据在某一个时间点进行备份，在创建快照之后，用户可以对快照进行备份。通常情况下，为了防止单台服务器出现故障造成所有数据的丢失，我们还可以将快照复制到其他服务器，创建具有相同数据的数据副本，这样的话，数据恢复的时候或者服务器重启的时候就可以使用这些快照信息进行数据的恢复，也可以防止单台服务器出现故障的时候造成数据的丢失。
但是，没我们还需要注意的是，创建快照的方式，并不能完全保证我们的数据不丢失，这个大家可以很好的理解，因为快照的创建时定时的，并不是每一次更新操作都会创建一个快照的。系统发生崩溃的时候，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化的方式只适合于数据不经常修改或者丢失部分数据影响不大的场景。
一、创建快照的方式：
（1）客户端通过向 Redis 发送 BGSAVE 命令来创建快照。
使用 BGSAVE 的时候，Redis 会调用 fork 来创建一个子进程，然后子进程负责将快照写到硬盘中，而父进程则继续处理命令请求。
使用场景：
如果用户使用了 save 设置，例如：save 60 1000 , 那么从 Redis 最近一次创建快照之后开始计算，当“60 秒之内有 1000 次写入操作”这个条件满足的时候，Redis 就会自动触发 BGSAVE 命令。
如果用户使用了多个 save 设置，那么当任意一个 save 配置满足条件的时候，Redis 都会触发一次 BGSAVE 命令。
（2）客户端通过向 Redis 发送 SAVE 命令来创建快照。
接收到 SAVE 命令的 Redis 服务器在快照创建完毕之前将不再响应任何其他命令的请求。SAVE 命令并不常用，我们通常只在没有足够的内存去执行 BGSAVE 命令的时候才会使用 SAVE 命令，或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令；
使用场景：
当 Redis 通过 SHUTDOWN 命令接收到关闭服务器的请求时，或者接收到标准的 TERM 信号时，会执行一次 SAVE 命令，阻塞所有的客户端，不再执行客户端发送的任何命令，并且在执行完 SAVE 命令之后关闭服务器。
二、使用快照持久化注意事项：
我们在使用快照的方式来保存数据的时候，如果 Redis 服务器中的数据量比较小的话，例如只有几个 GB 的时候。Redis 会创建子进程并将数据保存到硬盘里边，生成快照所需的时间比读取数据所需要的时间还要短。
但是，随着数据的增大，Redis 占用的内存越来越大的时候，BGSAVE 在创建子进程的时候消耗的时间也会越来越多，如果 Redis 服务器所剩下的内存不多的时候，这行 BGSAVE 命令会使得系统长时间地停顿，还有可能导致服务器无法使用。
各虚拟机类别，创建子线程所耗时间：
因此，为了防止 Redis 因为创建子进程的时候出现停顿，我们可以考虑关闭自动保存，转而通过手动的方式发送 BGSAVE 或者 SAVE 来进行持久化，
手动的方式发送 BGSAVE 也会出现停顿的现象，但是我们可以控制发送该命令的时间来控制出现停顿的时候不影响具体的业务请求。
另外，值得注意的是，在使用 SAVE 命令的时候，虽然会一直阻塞 Redis 直到快照生成完毕，但是其不需要创建子进程，所以不会向 BGSAVE 一样，因为创建子进程而导致 Redis 停顿。也正因为如此，SAVE 创建快照的速度要比 BGSAVE 创建快照的速度更快一些。
创建快照的时候，我们可以在业务请求，比较少的时候，比如凌晨三、四点，通过手写脚本的方式，定时执行。
AOF 持久化
AOF 持久化会将被执行的写命令写到 AOF 文件的末尾，以此来记录数据发生的变化。这样，我们在恢复数据的时候，只需要从头到尾的执行一下 AOF 文件即可恢复数据。
一、打开 AOF 持久化选项
我们可以通过使用如下命令打开 AOF：
appendonly yes我们，通过如下命令来配置 AOF 文件的同步频率：
appendfsync everysec/always/no二、appendfsync 同步频率的区别
appendfsync 同步频率的区别如下图：
（1）always 的方式固然可以对没一条数据进行很好的保存，但是这种同步策略需要对硬盘进行大量的写操作，所以 Redis 处理命令的速度会受到硬盘性能的限制。
普通的硬盘每秒钟只能处理大约 200 个写命令，使用固态硬盘 SSD 每秒可以处理几万个写命令，但是每次只写一个命令，这种只能怪不断地写入很少量的数据的做法有可能引发严重的写入放大问题，这种情况下降严重影响固态硬盘的使用寿命。
（2）everysec 的方式，Redis 以每秒一次的频率大队 AOF 文件进行同步。这样的话既可以兼顾数据安全也可以兼顾写入性能。
Redis 以每秒同步一次 AOF 文件的性能和不使用任何持久化特性时的性能相差无几，使用每秒更新一次 的方式，可以保证，即使出现故障，丢失的数据也在一秒之内产生的数据。
（3）no 的方式，Redis 将不对 AOF 文件执行任何显示的同步操作，而是由操作系统来决定应该何时对 AOF 文件进行同步。
这个命令一般不会对 Redis 的性能造成多大的影响，但是当系统出现故障的时候使用这种选项的 Redis 服务器丢失不定数量的数据。
另外，当用户的硬盘处理写入操作的速度不够快的话，那么缓冲区被等待写入硬盘的数据填满时，Redis 的写入操作将被阻塞，并导致 Redis 处理命令请求的速度变慢，因为这个原因，一般不推荐使用这个选项。
三、重写 / 压缩 AOF 文件
随着数据量的增大，AOF 的文件可能会很大，这样在每次进行数据恢复的时候就会进行很长的时间，为了解决日益增大的 AOF 文件，用户可以向 Redis 发送 BGREWRITEAOF 命令，这个命令会通过移除 AOF 文件中的冗余命令来重写 AOF 文件，是 AOF 文件的体检变得尽可能的小。
BGREWRITEAOF 的工作原理和 BGSAVE 的原理很像：Redis 会创建一个子进程，然后由子进程负责对 AOF 文件的重写操作。
因为 AOF 文件重写的时候汇创建子进程，所以快照持久化因为创建子进程而导致的性能和内存占用问题同样会出现在 AOF 文件重写的 时候。
四、触发重写 / 压缩 AOF 文件条件设定
AOF 通过设置 auto-aof-rewrite-percentage 和
auto-aof-rewrite-min-size 选项来自动执行 BGREWRITEAOF。
其具体含义，通过实例可以看出，如下配置：
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb表示当前 AOF 的文件体积大于 64MB，并且 AOF 文件的体积比上一次重写之后的体积变大了至少一倍（100%）的时候，Redis 将执行重写 BGREWRITEAOF 命令。
如果 AOF 重写执行的过于频繁的话，可以将 auto-aof-rewrite-percentage 选项的值设置为 100 以上，这种最偶发就可以让 Redis 在 AOF 文件的体积变得更大之后才执行重写操作，不过，这也使得在进行数据恢复的时候执行的时间变得更加长一些。
验证快照文件和 AOF 文件
无论使用哪种方式进行持久化，我们在进行恢复数据的时候，Redis 提供了两个命令行程序：
redis-check-aofredis-check-dump他们可以再系统发生故障的时候，检查快照和 AOF 文件的状态，并对有需要的情况对文件进行修复。
如果用户在运行 redis-check-aof 命令的时候，指定了 –fix 参数，那么程序将对 AOF 文件进行修复。
程序修复 AOF 文件的方法很简单：他会扫描给定的 AOF 文件，寻找不正确或者不完整的命令，当发现第一个出现错误命令的时候，程序会删除出错命令以及出错命令之后的所有命令，只保留那些位于出错命令之前的正确命令。大部分情况，被删除的都是 AOF 文件末尾的不完整的写命令。
到此，关于“怎么使用快照和 AOF 将 Redis 数据持久化到硬盘中”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
