Redis应用学习（五）——Redis持久化的选择与取舍

1. 持久化的做用

    1. 持久化：Redis运行时全部的数据都保存在内存中，对数据的更新将会异步的存储到磁盘中，当Redis须要恢复数据时就加载磁盘中的数据

    2. 持久化的实现方式：

• 快照：简单来讲，就相似于用一个照相机将某个时间点的Redis中的数据“拍摄”下来保存在“照片”中，“照片”就是快照文件，将快照保存在磁盘中，即实现持久化，具体实现好比MySQL数据库中的MySQL  Dump功能和Redis  RDB功能
• 日志文件记录：将对数据的更新操做所有记录在一个日志文件中，当须要恢复数据时，只须要从新执行一遍日志中的操做便可，具体实现好比MySQL数据库中的MySQL  Binlog功能和Redis  AOF功能

2. Redis中的数据持久化方式——RDB

    1. RDB：以快照方式来实现Redis数据的持久化操做，Redis执行一条RDB指令，生成一个RDB文件（二进制）并保存到硬盘中，该文件中保存了生成该文件时Redis中存储的全部数据，当Redis须要恢复这些数据时（好比重启）就能够从新加载这个RDB文件来恢复数据。RDB文件还有另外一个用处，就是可使用该文件来实现数据复制。

    2. 生成RDB文件的触发条件：

• save（同步）：save，直接在客户端中执行该命令，Redis就会生成一个RDB文件，同步执行指的是该命令会与普通命令同样，在惟一的命令队列（单线程）里排队，直到该命令执行完成以后（RDB文件生成完毕以后），才会执行save命令以后的命令，也就是会发生同步阻塞，尽可能不用该命令来生成RDB文件，由于若是数据量过多，会引发长时间的阻塞；若是RDB文件存储的目标路径下有旧的RDB文件，那么就会将新的RDB替换旧的；save操做的时间复杂度为O(n)
• bgsave（异步）：bgsave，直接在客户端中执行该命令，Redis就会生成一个RDB文件，异步执行指的是该命令不会与普通命令同样占用Redis的单线程执行，而是利用linux中的fork()函数（该函数依然会阻塞Redis主进程，不过该过程基本都很是快速）开辟一个Redis子进程来执行生成RDB文件，生成完成以后再返回给主进程RDB文件生成成功，在子进程生成RDB文件时，Redis会继续处理命令队列后续的命令；若是RDB文件存储的目标路径下有旧的RDB文件，那么就会将新的RDB替换旧的；save操做的时间复杂度为O(n)
• 自动：自动即指不须要执行命令便可自动生成RDB文件，不过须要配置必定条件来触发，须要配置seconds和changes两个参数，表示在seconds秒内对Redis中的数据修改的changes条时就会生成RDB文件；该方式有必定的问题，就是有可能形成生成RDB文件频率太高，进而致使对硬盘有必定的压力，并且阻塞时间也会变多。

    3. 在redis.conf文件中对生成RDB文件的一些参数配置：

• 自动生成RDB文件的seconds和changes两个参数设置

• 配置生成的RDB文件的文件名，默认为dump.rdb

• 配置RDB文件的存储路径，默认为 ./ ，表示与redis.conf同级目录下

• 配置若是bgsave操做过程当中出现异常错误，则当即中止写入数据到RDB文件中，默认为yes，不建议改动
• 生成RDB文件是否采用压缩的格式，默认为yes，不建议改动

• 在加载RDB文件时是否对RDB文件进行校验，默认为yes，不建议改动

    4. 配置参数建议：

• 删除RDB自动生成配置参数，也就是把seconds和changes两个参数设置所有删除
• 把dbfilename的参数设置为dump-port.rdb，由于Redis是单线程，因此一台机器上每每会部署多个Redis以充分利用多核处理器，而每一个Redis运行时会占用不一样的端口，因此须要依据不一样端口来生成对应的RDB文件名，防止重复，好比dump-6379.rdb

    5. 必定会生成RDB文件的触发条件：

• 全量复制：在进行主从复制时，主节点会自动生成RDB文件
• debug reload：Redis中提供了一个debug级别的重启方式，该方式不会清空内存中的数据，可是会生成一个RDB文件
• shutdown：经过客户端shutdown命令关Redis时，会自动生成一个RDB文件

    6. RDB存在的问题：

• 耗时并且耗费性能：耗时是由于RDB文件生成时会将Redis中的全部数据所有存储的RDB文件中，并且若是是采用save命令执行的话，耗时会更久；若是使用bgsave生成RDB文件，又会由于fork()函数消耗更多的性能；其次，自己生成RDB文件就是一个IO操做，若是数据量过多，那么会形成很严重的性能消耗
• 不可控，会发生数据丢失

3. Redis中的数据持久化方式——AOF

    1. AOF原理：以日志文件记录分数来实现数据持久化，即每当一条数据修改命令被执行后，都会将该命令写入AOF文件中，当Redis须要回复数据时，只须要从AOF文件中一条条的将命令取出并执行。

    2. AOF三种配置参数：

• always：每执行一条数据修改命令，都会将该命令写入AOF文件中，不会丢失数据，可是性能不好，对于IO的开销很大
• everysec：每隔一秒将数据修改命令写入AOF文件中，每次写入AOF文件意味着会丢失至少一秒的数据，性能稍好，默认该AOF配置参数
• no：由操做系统决定何时将数据修改命令写入AOF文件，不可控

    3. AOF重写：若是对一个文件持续不停地写入数据，随着文件愈来愈大，那么IO速度也会愈来愈低，Redis提供了一个AOF重写的功能来下降AOF文件大小的增加速度；在记录的命令中，有不少是重复的、无用的、过时的命令，能够将这些命令进行一些优化和删减，好比对同一个key-value数据进行屡次set命令，那么只须要记录最后一次set命令便可，好比某个数据已通过期（expire），那么该数据的相关语句就能够删除；经过对AOF文件进行AOF重写就能够减小磁盘占用量，增长数据恢复速度

    4. AOF重写的实现方式：

• bgrewriteaof：是一条客户端执行命令，执行成功会返回给客户端ok，和bgsave相似，会经过fork开辟一个子进程来进行AOF重写，
• 使用配置文件：在Redis的配置文件redis.conf中能够经过auto-aof-rewrite-percentage（AOF文件增加率）和auto-aof-rewrite-min-size（AOF文件最大字节长度）两个配置参数来实现自动AOF重写；若是AOF文件的大小已经达到了auto-aof-rewrite-min-size，而且AOF文件大小的增加速度到达了auto-aof-rewrite-percentage，则会进行一次重写。好比下图中的配置参数auto-aof-rewrite-min-size 64mb表示AOF文件的大小要超过64mb，auto-aof-rewrite-percentage 100表示增加率要达到100%（若是上一次进行AOF重写时AOF文件的大小为100mb，那么下一次AOF文件的大小为200mb时就表示增加率为100%），这两个条件同时知足就会执行一次AOF重写

    5. AOF功能的相关配置参数：在Redis的配置文件redis.conf中，除了上面的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size

• 修改appendonly为yes；修改appendfilename为"appendonly-port.aof"
• port处写Redis运行所占用的端口号，该参数表示生成的AOF文件的名称
• 能够修改appendfsync，但建议使用默认everysec
• 修改dir，配置AOF文件的存储目录路径，该目录下也存储RDB文件

• 修改no-appendfsync-on-rewrite为yes，表示是否在进行AOF重写的同时，能够进行AOF普通的命令append操做，yes表示不能进行（这样会有更好的性能），具体取决因而否容许在AOF重写期间丢失Redis执行的一些数据修改命令

4. Redis中的数据持久化方式AOF与RDB的选择

    1. 比较RDB与AOF：

• 加载优先级：Redis会优先加载AOF文件来恢复数据，其次是RDB文件
• 文件体积：RDB文件较小，AOF文件较大，由于RDB文件采用二进制存储，并且采用压缩格式，因此体积较小
• 数据恢复速度：RDB较快，AOF较慢
• 安全性：AOF的存储策略不一样，不必定会丢失数据，好比always就不会丢失，但everysec就会丢失至少1秒的数据；RDB必定会丢失数据
• RDB的读写操做性能消耗较大，而AOF的读写性能消耗相对小一点

    2. 依据以上对比，根据实际应用环境来进行选择。