Redis持久化机制

标签：red   end   方法   复制   也有   机制   访问   应该   崩溃   

一、持久化方式

redis提供了两种持久化方式将数据存储到硬盘中。

• 快照：将存在于某一时刻的所有数据写入硬盘中。
• 追加文件（AOF）：在执行写命令时，将被执行的命令复制到硬盘中。

二、快照持久化

redis通过创建快照获得某一时间点存储在内存中的所有数据的副本，如果redis、系统或硬件三者其中只一发生崩溃，redis会损失创建最后一次成功快照之后的所有数据。所以redis比较适合那些即使丢失一部分数据也不会造成问题的应用程序。

举例，在一个redis服务中，上一次创建快照的时间是12:00，并且创建成功，下一次创建快照的时间是13:00，13:05快照创建完毕，同时在13:00-13:05之间有10条写入操作。如果系统在13:00-13:05之间发生崩溃，那么redis将丢失12:00之后所有写入的数据，如果系统恰好在13:05快照创建成功后崩溃，那么redis将只丢失快照创建期间内写入的10条数据。
创建快照的方法：

• BGSAVE命令：redis会fork一个子进程，子进程复制将快照写入硬盘，redis会继续处理请求。
• SAVE命令：SAVE命令没有BGSAVE命令常用，因为接收到SAVE命令的redis服务在创建完快照之前不再处理任何请求。
• 如果用户设置了save配置选项，条件被满足时，redis会自动触发一次BGSAVE命令。如果设置了多个save配置，只要满足其中一个就会触发一次。（设置save规则时应考虑应用程序最多可以承受多长时间的数据丢失）

redis默认配置如下
save 900 1    //900秒之内，如果超过1个key被修改，则发起快照保存
save 300 10   //300秒内，如果超过10个key被修改，则发起快照保存；
save 60 10000 //1分钟之内，如果1万个key被修改，则发起快照保存；

• redis接收到SHUTDOWN关闭服务器请求时，会执行一个SAVE命令，阻塞所有客户端，不再响应客户端的任何命令，并在SAVE命令执行完毕后关闭服务器。

随着redis数据量的增大，使用BGSAVE命令创建快照，创建子进程所消耗的时间也越来越长，创建子进程时redis服务处于停顿状态。为了避免或减轻这种停顿带来的影响，我们可以关闭自动保存快照，手动执行BGSAVE或SAVE。手动执行BGSAVE也会引起停顿，但是我们可以控制停顿出现的时间，避开访问高峰期。手动执行SAVE命令虽然会引起redis请求阻塞，但是由于不用创建子进程，所以不会想BGSAVE那样因为创建子进程而停顿，并且由于没有子进程抢夺资源，SAVE命令创建快照的速度要更快一些。

三、AOF持久化

AOF持久化，就是将被执行的写命令追加到AOF文件末尾，所以redis只要完整执行一遍AOF文件包含的所有命令，就可以恢复AOF记录的数据集，可以通过appendonly yes 配置项设置AOF持久化。通过appendfsync设置AOF文件的同步频率。

向硬盘写入文件时，写入的文件会先存储到缓冲区，操作系统会在将来的某个时候将缓冲区的数据写入硬盘，数据只有在真正写入硬盘后，才算保存到了硬盘。用户也可以通过file。flush（）方法请求操作系统尽快将缓冲区的数据写入硬盘，但实际写入但时间仍然是由操作系统决定。

AOF持久化方式也有缺陷，就是AOF文件的大小。随着redis的运行，AOF文件的大小也会不断增长，在极端情况下，AOF文件的大小可能会超过数据集的大小。并且如果AOF文件过大，通过AOF文件还原数据集所消耗的时间就会非常长。用户可以通过BGREWRITEAOF命令压缩AOF文件，这个命令会通过移出AOF文件中冗余的命令来重写AOF文件，使文件的大小尽可能的小。

用户也可以设置配置项来自动执行BGREWRITEAOF命令。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
//表示当aof文件超过64MB，并且AOF文件的体积比上一次重写后文件的体积大了一倍（100%），就自动执行BGREWRITEAOF命令

四、总结

持久化的方式没有哪一种比另一种更好，需要结合业务场景去选择和配置。同时，除了持久化以外，用户还应该对持久化的文件进行备份处理，这样才会最大程度避免数据丢失。

Redis持久化机制

标签：red   end   方法   复制   也有   机制   访问   应该   崩溃   

原文地址：https://www.cnblogs.com/youtang/p/12774236.html