Redis数据之数据持久化

Redis数据持久化

一 、持久化的方法

Redis提供了两种不同的持久化方法将数据存储到硬盘

• 快照（snapshotting）,他可以将存在于某一时刻的所有数据都写入硬盘里面
• 只追加文件（append-only-file,AOF），它会在执行写命令时，将被执行的写命令复制到硬盘里面
  这两种方法既可以同时使用，又可以单独使用，也可以两种都不使用

二、配置

这些配置项告诉我们
第一组用于配置快照：多久执行一次自动快照操作，如何命名硬盘上的快照文件，是否对快照文件进行压缩，在创建快照失败后是否仍然继续执行写命令
第二组用于配置AOF子系统：是否使用AOF持久化、多久才将写入得内容同步到硬盘、在对AOF进行压缩的时候是否执行同步操作，以及多久执行一次AOF压缩。

三、快照持久化

• Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本
• 创建快照之后，用户可对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本
• 还可以将快照留在原地以便重启服务器时使用

---

快照会根据配置项的配置，快照被写入到dbfilename选项制定的文件夹里，并存储在目录dir制定的路径上面
快照在创建完毕之前，Redis、系统、或者硬件三者中的任意一个崩溃，那么Redis将丢失最近一次创建快照之后写入得所有数据

---

创建快照的方式

• 使用bgsave命令来创建一个快照（window不支持），这种方式，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，父进程则继续处理命令请求
• 使用save命令来创建一个快照，与bgsave不同的是，Redis在接收到save命令之后，不再处理其他任何命令，直到快照创建完毕。save命令一般只会在没有足够的内存去执行bgsave命令的情况下使用
• 配置项设置为save 60 1000 ，从Redis最近一次创建快照之后开始算起，“当60秒内有1000次写入”这个条件被满足时，Redis就会自动触发bgsave命令，save可以设置多个，满足任意一个就会触发bgsave命令
• Redis通过shutdown命令接收到关闭服务器的请求时，或者介绍到标准的TERM信号时，会执行一个save命令，阻塞所有客户端，不再执行客户端发送来的任何命令，并在save命令执行完毕之后关闭服务器。
• 当一个Redis服务器连接另一个Redis服务器时，并向对方发送SYNC命令来开始第一次复制操作的时候，如果主服务器目前没有在执行bgsave操作，或者主服务器并非刚执行完bgsave操作，那么主服务器就会执行bgsave命令。
  注意：快照持久化的方法来保存数据时，如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据。
  数据量大时bgsave生成快照会比较慢

四、AOF持久化

AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。Redis只要从头到尾重新执行一次AOF文件包含的所有命令，就可以恢复AOF所记录的数据集。
appendfsync选项及同步频率

always选项，每个Redis命令都会被写入硬盘，从而将发生系统崩溃时出现的数据丢失减到最少。不过缺点是，这种同步策略需要对硬盘进行大量写入，所有Redis处理命令的速度会受到硬盘性能的限制：转盘式硬盘在这种同步频率下美妙只能处理大约200写个命令，二ssd（有风险有可能会造成写入放大问题）硬盘大概也只能处理几万个写命令。
为了兼顾数据安全和写入性能，用户可以考虑使用appendfsync everysec选项，让Redis以美妙一次的频率对AOF文件进行同步。Redis每秒同步一次AOF文件时的性能和不用用任何持久化特性时的性能相差无几，而通过每秒同步一次AOF文件，Redis可以保证，即使出现系统崩溃，用户也最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅地放慢自己的速度以使用硬盘的最大写入。

如果用户使用appendfsync no 选项 那么Redis’将不对AOF文件执行任何显示同步操作，而是由操作系统来决定应该在何时对AOF文件进行同步，这个选项一般不会对Redis的性能带来影响，但是系统崩溃将导致Redis服务器丢失不定数量的数据；另外如果用户的硬盘处理写入操作的速度不够快的话，那么当缓冲区被等待写入硬盘的数量填满时，Redis的写入操作将被阻塞，并导致Redis处理命令的请求的速度变慢。因为这个原因，不推荐使用no选项

重写/压缩AOF文件
AOF文件随着数据量的增大体积可能变得非常大，可以使用以下方式处理这个问题

• 使用bgrewriteaof命令，这个命令会通过移除AOF文件中的冗余命令来重写AOF文件，使AOF文件的体积变得尽可能的小；工作原理与bgsave相似，Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写。因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程二导致的性能问题和内存张勇问题，在AOF持久化中也同样存在，更糟糕的是，如果不加以控制的话，AOF文件的体积可能比快照文件的体积大好几倍，在进行AOF重写并删除旧AOF文件的时候，删除一个体积达到数十GB的旧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命令。如果触发过于频繁，可以将值设置为100以上。