Redis数据持久化、数据备份、数据的故障恢复

1、redis持久化到缘由

前面章节已经讲过redis集群到三中方式，主从复制，哨兵，集群，每种方式都有自己到优缺点，可以根据自己到项目需求
选取不同到方式搭建集群方式。然后redis数据持久化，数据备份，数据到故障修复也是不容小觑到，在正式到应用中并不
是如何搭建redis环境，而是数据到备份和redis故障修复问题，总之一定会遇到各种奇葩的现象导致redis死掉，这时候放
在redis内存中的数据就会全部丢失，这些数据可能服务很多的系统或者服务，当然，我们可以重新启动redis，重启之后，
如果redis没有持久化，redis中的数据就会全部丢失 

2、redis持久化到两大机制（RDB和AOF）

RDB：是对redis数据周期性持久化生成到一个快照文件dump.rdb文件
RDB举例说明：redis.conf 中配置到 save 60 1000 ，当60秒内有1000条数据到写入，redis就会进行RDB持久化生成一
dump.rdb文件覆盖之前到旧文件

AOF: 是将每条命令写入日志，以appendonly的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF的写
入指令来重新构建整个数据集
AOF举例说明：redis.conf中开启AOF持久化 appendonle yes时 redis中每写入一条指令，就会把这条指令更新到磁盘
中的文件中。然而在现代操作系统中，写文件不是直接写磁盘，会先写进os cache，然后在一定时间内再从os cache刷
入disk file，对于AOF来说每隔一秒（可配置）调用一次操作系统fsync操作强制将os cache中的数据刷入磁盘文件中。
但是redis内存中的数据也不是无限增长的，它是定期的根据LRU算法清理一些不常用的数据，这样才能保证AOF不会无限
增长，但是如果LRU的清理速度比不上AOF的膨胀速度的时候，这时候当AOF大到一定程度就会进行AOF rewrite操作。
AOF rewrite操作就会基于当时redis内存中的数据来重新构造一个更小的AOF文件，然后将旧的AOF文件删除。 简单的说， 假设redis限定了只能存放10G数据，这时候不断的在redis中写入数据，当达到了10G的数据量的时候，这时候根据LRU清理
了一些不常用的数据，清理了5G，这时候又写了5G，这时候AOF文件记录了15G的数据相关的写入指令，假如这个时候AOF已
经膨胀了，这个时候redis进行AOF rewrite操作，重新生成了一个新的10G的数据指令的AOF文件，这个时候将继续写入新
的AOF文件，将老的AOF文件删除

表示是否开启AOF持久化： 

appendonly yes(默认no,关闭)

AOF持久化配置文件的名称： 

appendfilename “appendonly.aof”

AOF持久化策略(默认每秒)： 

appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)
　　appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)
　　appendfsync no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）

AOF的Rewrite(重写) ： 

定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制
当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
　　auto-aof-rewrite-percentage 100 （一倍）
　　auto-aof-rewrite-min-size 64mb
　　　　
AOF配置文件损坏修复方法：
　　进入redis安装路径 执行 redis-check-aof –fix AOF配置文件名称

3、RDB和AOF优缺点

RDB优点
1：RDB会生成dump.rdb文件，该文件是某一个时间段的一个快照文件，可以定期拷贝到远程安全到存储设备上。
2：RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，
让子进程执行磁盘IO操作来进行RDB持久化即可，RDB都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘中
3：相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速

RDB缺点	
1：如果想要在redis故障时尽可能少的丢失数据，那么RDB没有AOF好。RDB数据快照文件每隔一段时间达到触发才会生成一次，
这个时候就得接受一旦redis进程宕机，那么会丢失最近数据，这也是rdb最大的缺点，就是不适合做第一优先的恢复方案，
如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。

2：RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，
或者甚至数秒，所以一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的

AOF优点
1：AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据,每隔1秒，
就执行一次fsync操作，保证os cache中的数据写入磁盘中，redis进程挂了，最多丢掉1秒钟的数据。
2：AOF日志文件以append-only模式写入文件到尾部
3：AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的内容进行压缩，
创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，
再交换新老日志文件即可。	4：.AOF日志文件的命令通过可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空
了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放
回去，就可以通过恢复机制，自动恢复所有数据

AOF缺点

1：对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
　　2：AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很
     高的，如果你要保证一条数据都不丢，也是可以的，AOF的fsync设置成没写入一条数据，fsync一次，那就完蛋了，redis的QPS大降。
　　3：以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基
	于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免
	rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样
	健壮性会好很多。
　　4：唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，
	做冷备不太合适