redis基础三(持久化）

redi持久化：RDB和AOF

   就是把redis里的数据保存到磁盘空间上，再次启动redis时会加载磁盘里的数据。因为内存里的数据在断电或服务停时，数据自动消息，为了防止这种问题，需要把数据保存到磁盘上，再次启动服务时从磁盘加载数据到内存中。

一、RDB(redis database)

1.1 备份策略

   在指定的时间间隔内将内存中的数据集快照写入到磁盘。也就是的Snapshot快照，它恢复时是将快照文件直接读到内存里。

       Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何IO操作，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Rdb保存的文件默认是dump.rdb文件；

1.2 手动备份

save命令：其他进程全部停止，直接执行save操作，把数据存放到默认的dump.rdb文件下；

bgsave命令：前台进程依然进程，后台专门启动一个进程进行数据保存到磁盘空间上的dump.rdb文件；(bgsave即 back ground save)

flushall/flushdb命令，也会产生dump.rdb文件，但里面是空的，无意义

shutdown命令:执行shutdown也会产生dum.rdb文件

1.3 redis.config配置文件

看下redis.conf文件是怎么设置的：

 

1：是被注释掉的，如果不想做快照保存，把“1”处的注释去掉，“2”出加上注释即可；

2：save 900 1 表示的意思就是900秒内修改过一次key(新增key或修改原key对应的value值都算，仅查询不算)就触发一次快照，把redis内存的数据同步保存到dump.rdb文件中；

save 300 10  表示300秒内修改过10次触发一次快照；

save 60 10000 表示60秒内修改过10000次触发一次快照；

整个“2”处这样写表示三个逻辑一个满足就触发一次快照。

3：stop-writes-on-bgsave-error 设置为yes ，意思就是在进行磁盘快照发生异常的情况下，redis主进程不在接收写操作；

4：rdbcompression yes 把数据存放到dump.rdb文件中，对value值进行LZF算法压缩；

5：rdbchecksum yes   对rdb数据进行校验，耗费CPU资源，默认为yes

6：dbfilename dump.rdb  这就是默认的rdb数据存放的文件名；

7: rdb文件前缀目录，这里是相对目录，和redis.conf是同一个目录；

 

1.4 恢复操作

1、将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

2、重新启动redis后会从指定目录+文件恢复数据

 

1.5 优缺点

优点：适用于大数据快速恢复；

对数据的完整性和一致性要求不高

缺点：在一定时间间隔做一次备份，如果redis意外down掉的话，就会丢失最后一次快照后的所有修改；

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

1.6 dump.rdb 文件修复

redis-check-dump  --fix   dump.rdb 检查aof文件，删掉不符合redis语法的内容。

 

 

2、AOF(append only File)

       以日志的形式记录每个写操作，将redis执行过的所有写指令记录下来(读操作不记录)；只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2.1  重写

       aof策略把数据持久化到磁盘，使用的是日志的形式记录所有修改操作，这样就导致数据量会越来越大，为避免这种情况，redis新增了重写机制，当aof文件大小超过设定的阀值时，redis会触发aof文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用bgrewriteaof手动触发redis的重写机制。

    

重写原理：

      Aof文件持续增长而超过设置的阀值(配置文件里可设置大小)时，会fork出一条新进程将文件重写(也是先写临时文件在rename)，遍历新进程中的内存数据，每条记录有一条set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

重写机制：

Redis会记录上次重写时的aof文件大小。默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

2.2 配置文件

1、“1”处说明默认是不开启 appendonly文件的，开启的话需要 把 no 改为yes；

注意：rdb和aof可以同时设置，这也是没有问题的，两个文件都有的话，redis会首先加载aof文件。

2、“2”处说明文件是以appendonly.aof文件命名的，一般不建议修改此处；

 

3、说明如何让redis把操作日志写入到appendonly.aof文件中，有三种策略

1)、appendfsync always ：同步持久化，每次发生数据变动被立即记录到磁盘，性能差但数据完整性好；

2)、appendfsync  everysec ：默认设置，异步操作，每秒数据同步一次到磁盘，如果一秒内redis宕机，有一秒种的数据丢失；(最佳实践：使用默认值)

3)、appendfsync no：不主动去写数据到aof磁盘上；

 

4、no-appendfsync-on-rewrite no 采用默认值就好，意思是重写的时候不采用追加方式；保证数据的安全性。

5触发重写的条件：

auto-aof-rewrite-percentage 100  比上次重写的文件大一倍

auto-aof-rewrite-min-size 64mb   当aof文件达到64M时(最佳实践：64M在生产环境太小，最少需要改为3G)

综合起来就是 首次当aof文件达到64M时触发redis的重写机制，第二次当aof文件达到128M时触发重写机制，依次类推。

 

也可以手动触发重写机制：bgrewriteaof

2.3 Appendonly.aof 文件修复

redis-check-aof  --fix   appendonly.aof 检查aof文件，删掉不符合redis语法的内容。

5.2.4 恢复操作

当redis的配置文件中开启aof时，默认redis会每秒把数据写入磁盘文件appendonly.aof文件中，包括shutdown这样的命名，若要恢复的话，重启redis即可。

2.4  优缺点

优点： 可以设置每秒同步(默认也是推荐设置)、不同步、一直同步三种模式，相对rdb数据丢失更少。

缺点：相同数据集的文件aof要远大于rdb文件，恢复也没rdb快；

          aof模式运行效率要慢于rdb，每秒同步策略效果较好。

 

 

 

总结： rdb or aof

rdb持久化方式能够在指定的实践间隔对数据进行快照存储；

aof持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，aof命令以redis协议追加保存每次写的操作到文末尾，redis还能对aof文件进行后台重写，使得aof文件的体积不至于过大。

只做缓存：如果只希望数据在服务器运行时存在，可以不适用任何持久化方式。

同时开启rdb和aof：这种情况下，当redis重启的时候会有限载入aof文件来恢复原始的数据，因为在通常情况下aof文件保存的数据集要比rdb文件保存的数据集更完整。Rdb的数据不是实时的，同时使用两者时服务器重启也只会找aof文件。那要不要只使用aof呢？建议不要这样做，因为rdb更适合用于数据的备份（aof文件不断变化不好备份），做快速重启，而且不会有aof可能潜在的bug，留着作为一个万一的手段。

性能建议：

       因为rdb文件只用作后背用途，建议只在Slave上持久化rdb文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则；

      如果开启aof，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本简单只load自己的aof文件就可以了，代价是带来了持续的IO，二是aof的rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的，只要硬盘许可，应该尽量减少aof rewrite的频率，aof重写的基础大小是默认的64M太小，可以设置3G以上，默认超过大小100%时重写可以改到适当的数值。

        如果不开启aof，紧靠Master-Slave Replication 实现高可用性也可以，能省掉一笔大的IO也减少了rewrite时带来的开销。代价是如果Master-Slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个Master-Slave中的rdb文件，载入交较新的那个。新浪微博就选择这种架构。