redis持久化-快照和AOF

##Redis持久化机制有两种方式:
1.快照:是将当前时刻redis中数据的状态由内存保存到硬盘中。若服务器宕机或重启后，只需将*.rdb(快照文件)文件执行后即可恢复redis内存的数据
2.AOF :将所有redis写数据

的命令读写到日志文件中，若服务器宕机或重启后，只需将日志文件执行后即可恢复redis的数据
#快照的执行方式:
1.客户端执行BGSAVE、SAVE指令
2.通过服务器的配置文件自动执行
3.执行shutdown命令
#快照生成的位置:redis/bin下的dump.rdb文件
#快照的执行过程:
BGSAVE:
在客户端执行BGSAVE 指令时主进程会执行一个FORK的函数去生成一个子进程去执行快照。FORK是linux系统的一个生成子进程的函数。执行fork后若客户端此时没有写的操作。
子进程和父进程共享内存。直至客户端执行了写入数据的操作例如set name 张三。子进程与父进程的共享内存的状态终止，此时父进程占据内存的大部分，子进程之占用小部分去继续生成快照
特点:多线程，客户端执行读写命令不受影响
SAVE:
客户端执行SAVE指令后由主进程去执行快照的生成。这时由于redis是单线程状态，所以在redis快照未生成完前 客户端的所有操作都是阻塞状态

配置文件自动去执行快照的生成 :
由以下截图可看到配置文件中默认是开启快照的
save 900 1意思是如果15分钟内更新了一次key，则执行快照一次
save 300 10意思是如果5分钟内更新了10次key，则执行快照一次
save 60 10000意思是如果1分钟内更新了10000次key，则执行快照一次

还有一种情况也会执行redis的快照 在redis客户端中执行shutdown命令。该指令在执行后会默认执行save命令。
关于生成快照方式来持久化存储数据的弊端:
以上述的快照执行方式可能只适用于正常的业务场景下可以保证数据的可靠性。例如利用配置文件去自动生成快照 每次生成快照都是有时间间隔的。
如果在上一次生成块照和下一次生成快照的时间间隔中。服务器宕机或其他的系统异常导致redis服务端异常关闭，那么在这个时间间隔中写入的数据就会丢失
AOF方式去持久化数据的解决方案就应运而生了(不得不说redis的设计真的挺厉害)

AOF日志持久化:
开启AOF持久化操作：将redis.conf中的appendonly no 改为appendonly yes。重启redis后就可以看到bin目录下已有appendonly.aof文件了
日志追加策略:redis支持三种追加策略:always、everysec、no
always:这种是指每次客户端的写操作到会立即同步至aof文件中，官方说的是慎重使用。劣势:因为高并发情况下每次的读写操作都会写入到硬盘中。会导致磁盘读写放大的问题。转盘式硬盘处理不过来，
固态式硬盘即使处理的过来也会损耗硬盘的寿命。如果硬盘的读写频率跟不上的话，redis就会阻塞。量价大了的话就会redis宕机。优势:理论上可以说是不会丢失任何数据
读写频率:转盘式硬盘:每秒读写200个左右 固态式硬盘大概每秒几百万个
everysec:这种是指每秒同步一次客户端的写操作到aof文件中，大概可以理解为客户端三秒内执行了3000个写入的操作，redis就会分三秒去同步至aof文件1000/s。
官方推荐使用。据说效率与alaways相差无几。即使发生异常情况最多也就丢失一秒的数据
no:no并不是不同步，而是同步的频率交给linux系统去做(redis官方也是不推荐使用，既然不推荐为啥要开发这种模式-.-)。劣势:可能会因为同步的频率时间间隔太大导致系统宕机导致数据丢失
或者同步了但是因为大量一次性的数据去写入aof文件也会导致读写放大的问题 造成redis阻塞，然后宕机