redis持久化

持久化选项

redis提供了两种不同的持久化方式来将数据存储到硬盘里面。一种方法叫快照（snapshotting，也可以叫RDB），它可以将存在于某一时刻的所有数据都写入硬盘里。另一种方式叫只追加文件（append-only file，也叫AOF），他会在执行写命令时，将被执行的写命令复制到硬盘中。这两种持久化方法可以同时使用，也可以单独使用，甚至也可以不使用。

RDB（快照）持久化选项：

//默认900秒（15分钟）后，如果至少有一个按键发生变化
save 900 1
save 300 10
save 60 10000
//当持久化出错时，是否停止写入操作。yes停止，no不停止。
stop-writes-on-bgsave-error yes
//是否开启LZF压缩 开启可以减小RDB持久化文件大小，不开启的话说是会显示CPU的部分信息，且如果有可压缩的值或键，那么数据集可能会更大
rdbcompression yes
//是否校验RDB文件的完整性
rdbchecksum yes
//指定RDB文件的文件名
dbfilename dump.rdb

AOF持久化选项

//是否开启AOF  yes开启 no关闭
appendonly no
//aof文件名
appendfilename "appendonly.aof"
//Redis支持三种不同的刷写模式：
//每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
//appendfsync always 
//每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
appendfsync everysec 
//完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
//appendfsync no     

//在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
//设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no
no-appendfsync-on-rewrite no
//当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。指定百分比为0，将禁用aof自动重写功能
auto-aof-rewrite-percentage 100
//当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb
//若设置为yes时在redis加载aof文件出错后会发送日志通知用户，
//反之则不做任何处理也不会启动redis，用户可以使用redis-check-aof --fix appendonly.aof指令完成数据修复。
aof-load-truncated yes

RDB持久化（快照持久化）

如果系统发生崩溃，用户将会丢失最近一次生成快照之后更改的所有数据。举例：

因此，快照持久化只适用于即使丢失一部分数据也不会造成任何问题的应用程序。

大数据

如果Redis的内存占用量达到数十个GB，并且剩余的空闲内存并不多，或者Redis运行在虚拟机上，那么执行BGSAVE可能会导致系统长时间地停顿，也可能引发系统大量地使用虚拟内存，从而导致Redis性能降低至无法使用的程度。

为了防止Redis因为创建子进程而出现停顿，我们可以考虑关闭自动保存，转而通过手动发送BGSAVE或者SAVE来进行持久化。手动发送BGSAVE一样会引起停顿，唯一不同的是用户可以通过手动发送BGSAVE命令来控制停顿出现的时间。另一方面，虽然SAVE会一直阻塞Redis直到快照生成完毕，但是因为它不需要创建子进程，所以就不会像BGSAVE一样因为创建子进程而导致Redis停顿；并且因为没有子进程在争抢资源，所以SAVE创建快照的速度会比BGSAVE创建快照的速度要来得更快一些。

AOF持久化

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

appendfsync选项及同步频率

• always 每个Redis写命令都要同步写入硬盘，这样会严重降低Redis的速度
• everysec 每秒执行一次同步，显式地将多个写命令同步到硬盘
• no 让操作系统来决定应该何时进行同步

如果使用always选项的话，数据丢失减到最少，但是这种同步策略会带来大量的对硬盘的写入操作，所以Redis处理命令的速度会受到硬盘性能的限制：转盘式硬盘在这种同步频率下每秒只能处理大约200个写命令，而固态硬盘每秒大概也只能处理几万个写命令。

虽然AOF持久化非常灵活的提供了多种不同的选项来满足不同的需求，但AOF也有缺陷，那就是AOF文件的体积太小。

重写/压缩AOF文件

随着Redis不断将写命令写入到AOF文件中，在导致文件增大的同时也会导致通过AOF还原数据的时间变长。为了解决AOF文件体积不断增大的问题，用户可以向Redis发送BGREWRITEAOF命令，这个命令会通过移除AOF文件中的冗余命令来重写AOF文件，使AOF文件变得尽可能地小。BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似： Redis创建一个子进程，通过子进程对AOF文件进行重写。（由于需要创建子进程，所以RDB中由于创建子进程导致的性能问题和内存占用问题同样存在。），更糟糕的是，如果不加以控制的话，AOF文件的体积可能会比快照文件的体积大好几倍，在进行AOF重写并删除旧的AOF文件时，删除一个体积达到数十GB大的旧AOF文件可能会导致操作系统挂起数秒。

跟快照持久化通过设置save选项来自动执行BGSAVE一样，AOF持久化也可以通过设置auto-aof-rewrite-percentage选项和auto-aof-rewrite-min-size选项来自动执行BGREWRITEAOF。举个例子，例如用户对Redis设置了配置选项

• auto-aof-rewrite-percentage 100
• auto-aof-rewrite-min-size 64mb
  并且启用了AOF持久化，那么当AOF文件体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）的时候，Redis将执行BGREWRITEAOF命令。如果AOF重写执行得过于频繁的话，用户可以考虑将auto-aof-rewrite-percentage选项的值设置到100以上，这样可以使Redis在AOF文件体积变得更大之后再执行重写操作，但也会使Redis在启动时还原数据集需要的时间更长。

---

大家好，我是小羊炒饭。感谢大家的关注，有任何问题可以提出，我们一起学习共同进步。公司的前辈告诉我，想涨工资人情>技术，我不懂人情，所以我想深耕技术，希望有一天能涨工资哈哈。