redis个人学习笔记 四：redis的持久化

       此文是我看尚硅谷教学视频后的个人的redis学习笔记，每一张截图都是我亲自敲后截图放在笔记中的，粘贴在博客上可能会有点点模糊，若有错误或不足，还望各位大神多多指正！

6 redis的持久化

6.1 总体介绍

       Redis是一个分布式的内存数据库。

6.1 总体介绍

6.2 RDB（Redis DataBase）

6.2.1 是什么

       在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
       Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
       整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

6.2.2 Fork

       fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）、数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

6.2.3 dump.rdb文件

       rdb 保存的是 dump.rdb文件

6.2.4 配置位置

6.2.4.1 Save

       Save：秒钟，写操作次数，RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。
       禁用:如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以.

6.2.4.2 stop-writes-on-bgsave-error

       如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制

6.2.4.3 rdbcompression

       对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。

6.2.4.4 rdbchecksum

       在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

6.2.4.5 dbfilename

6.2.4.6 dir

6.2.5 如何触发RDB快照

       就以上面的图片为例子，当我们把save 300 10 修改为120 10后，即在两分钟内，至少有十个以上的键被修改了就会生成快照，生成dump.db文件，一般情况下，生成的dump.db文件最好复制到另外一台机器上备份一次，假如备份在同一台机器上，当此机器坏了，备份就无效了。

6.2.5.1 配置文件中默认的快照配置

       冷拷贝后重新使用，可以cp dump.rdb dump_new.rdb

6.2.5.2 命令save或者是bgsave

       Save：save时只管保存，其它不管，全部阻塞，当修改了一个key后想要立刻备份生效，就可以输入save指令。
       BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。

6.2.5.3 执行flushall命令

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

6.2.6 如何恢复

       ①　将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
       ②　CONFIG GET dir获取目录

6.2.7 优势

       ①　适合大规模的数据恢复
       ②　对数据完整性和一致性要求不高

6.2.8 劣势

       ①　在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
       ②　fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

6.2.9 如何停止

       动态所有停止RDB保存规则的方法：redis-cli config set save “”

6.2.10 实例

       ①　先将快照配置修改，以便测试

       ②　刚开始的时候是没有dump.rdb文件存在的

       Redis里也是空的

       ③　此时存入六个数据，并且两分钟后，在目录中出现了dump.db文件


       ④　复制这个dump.db文件到另外一台机器（这里就用另外一个文件夹示范）

       ⑤　关机，并且删除掉原来的dump.db文件


       ⑥　再开机会发现什么也没有了

       ⑦　将备份的文件拷贝到目录中

       ⑧　当再次开启redis后，数据都回来了

6.2.11 小总结

       优点：
       ①　RDB是一个非常紧凑的文件。
       ②　RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要在做其他的IO操作，所以RDB持久化方式可以最大化redis的性能。
       ③　与AOF相比，在恢复大的数据集的时候，RDB方式会更快一点。
       缺点：
       ①　数据丢失风险大。
       ②　RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致redis在一些毫秒级不能响应客户端请求。

6.3 AOF（Append Only File）

6.3.1 是什么

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

6.3.2 appendonly.aof文件

       Aof保存的是appendonly.aof文件

6.3.3 配置位置

6.3.3.1 appendonly

6.3.3.2 appendfilename

6.3.3.3 appendfsync

       ①　always：同步持久化，每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
       ②　everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失
       ③　No

6.3.3.4 no-appendfsync-on-rewrite

       重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。

6.3.3.5 auto-aof-rewrite-min-size

       设置重写的基准值

6.3.4 AOF启动/修复/恢复

6.3.4.1 正常恢复

       启动：设置Yes，修改默认的appendonly no，改为yes
       将有数据的aof文件复制一份保存到对应目录(config get dir)
       恢复：重启redis然后重新加载

6.3.4.2 异常恢复

       启动：设置Yes，修改默认的appendonly no，改为yes
       备份被写坏的AOF文件
       修复：redis-check-aof –fix进行修复
       恢复：重启redis然后重新加载

6.3.5 rewrite

6.3.5.1 是什么

       AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

6.3.5.2 重写原理

       AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

6.3.5.3 触发机制

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

6.3.6 优势

       每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
       每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
       不同步：appendfsync no 从不同步

6.3.7 劣势

       相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
       aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

6.3.8 小总结

       Aop和rdb的比较


       aof文件是一个只进行追加的日志文件；
       Redis可以在aof文件体积编的过大时，自动的在后台对aof进行重写；
       Aof文件有序的保存了对数据库执行的所有写入的操作，这些写入操作以redis协议的格式保存，因此aof文件的内容非常容易被人读懂，对文件进行分析也很轻松；
       对于相同数据集来说，aop文件的体积通常要大于RDB文件的体积；
       根据所使用的fsync策略，aof的速度可能会慢于rdb；

6.4 实例

       在测试之前，先把aop打开，调整为yes状态
       ①　先将原有的dump.db删除掉

       ②　打开redis，进行存值

       ③　当采用命令flushall后再关闭redis，会生成dump.db文件，但是因为使用了flushall命令，所以这个dump.db文件时空的，但是这里为了测试，也将他删除掉


       看一看这个appendonly.aof

       ④　当重新进入reids后，原则上是会读取到appeonly.aof的数据，但是却是空，那是因为aof会严格遵守记录下每一条写入的操作，当我们上一次关闭的时候的最后一步写入的是FLUSHALL，当再次打开的时候，redis会读取aof的数据，然后读取到最后fluhall，然后数据又为空了；

       ⑤　所以如果要想读取到有数据，就要将aof文件中的flushall删除掉。
采用vim指令删除掉flushall指令。

       ⑥　此时数据就回来了。

       ⑦　当dump.db和aof同时存在时，找的是aof

       当因为突然停电等紧急情况导致aof文件错乱时，此时启动是无法启动的，此时rdb和aof文件时同时存在的，rdb文件是正常的，但aof是错乱的，所以说当两者同时存在时找的是aof文件。

6.5 总结

       官网建议，如果数据很多，又希望快速备份，即，对数据的敏感性不高的时候，就使用rdb。
       RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
       只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
       性能建议：因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构