缓存之Redis学习（四）

一、redis持久化机制
1、RDB ------redis DataBase
按照规则定时将内存的数据同步到磁盘
snapshot（快照）
redis在以下情况会触发快照：
（1）自己配置的快照规则
在redis.conf 里：搜索snapshot就可以

当在900秒内被更改的key的数量大于1的时候，就执行快照。
（2） save或者bgsave
save：执行内存的数据同步到磁盘的操作，这个操作会阻塞客户端的请求。
bgsave（background save）：在后台异步执行快照操作，这个操作不会阻塞客户端的请求
（3）执行flushall（删除所有库里的数据）的时候
（4）执行复制的时候（redis集群）
2、快照的实现原理：
（1）redis使用fork函数复制一份当前进程的副本（子进程）
（2）父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件
（3）当子进程写入完所有数据后悔用该临时文件替换旧的RDB文件（快照文件），至此，一次快照操作完成
注意：redis在进行快照的过程中不会修改RDB文件，只是快照结束后将旧的快照文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实现redis数据库的备份，RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。
总结：
1、使用RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将这种可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，虚妄将损失降到最小，则可以结合AOF方式进行持久化。
2、RDB可以最大化redis的性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘I0操作。但是同时这个歌也算一个缺点，如果数据集比较大的时候，fork可能比较耗时，造成服务器在一段时间内停止处理客户端的请求。
AOF ----------- append-only file
AOF可以将redis执行的每一条写命令追加到硬盘文件中，但是这一过程显然会降低redis的性能，但是大部分情况下这个影响是能够接受的，另外可以使用较快的SSD硬盘。
修改redis.conf中的 appendonly yes；重启后执行对数据的变更命令，会在bin目录下生成对应的.aof文件，aof文件中会记录所有的更改操作命令

还有两个参数可以对aof文件优化：

auto-aof-rewrite-percentage 100 ：
表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。
如果之前没有重写过，以启动时aof文件大小为准。
auto-aof-rewrite-min-size 64mb：
限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化。
默认情况下redis是没有开启AOF方式的持久化，可以通过appendonly参数启用。
开启AOF持久化后每执行一条会更改reids中的数据的命令后，redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。可以在redis.conf中修改。
AOF重写的原理：
redis可以在AOF文件体积变得过大时，自动在后台对AOF进行重写：重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的。因为redis在创建新AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，先用的AOF文件也不会丢失，而一旦新AOF文件创建完成，redis就会从旧的AOF切换到新AOF文件，并开始对新AOF文件进行追加操作，AOF文件有序的保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容费用容易被人读懂，对文件进行分析也很轻松。
同步磁盘数据：
redis每次更改数据的时候，AOF机制都会将命令记录到AOF文件中，但是实际上由于操作系统的缓存机制，数据并没有实时的写入到硬盘，而是进入了硬盘缓存。再通过硬盘缓存机制去刷新到保存到文件

#appendfsync always 每次执行写入都会进行同步 ， 这个是最安全但是是效率比较低的方式
appendfsync everysec 每一秒执行
appendfsync no 不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式
AOF文件损坏以后如何修复：
服务器可能在程序正在对AOF文件进行写入时停机，可能会造成AOF文件出错（corrupt），那么redis在重启时会拒绝载入这个AOF文件，从而确保数据的一致性不会被破坏。
1、为先用的AOF文件创建一个备份。
2、使用redis附带的redis-check-aof程序，对原来的AOF文件进行修复。
redis-check-aof–fix（aof文件不符合语法的会被丢弃掉）
重启redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。
总结：
RDB和AOF持久化机制如何选择：
如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。
如果可以承受数分钟以内的数据丢失，那么可以只使用RDB持久化。有很多用户都只是用AOF持久化，但是并不推荐这种方式：因为定时生成RDB快照文件非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度快。
如果同时使用两种持久化策略的话，那么redis重启时，会优先使用AOF文件来还远数据。