redis系列二完全搞懂redis的持久化

redis本身就是缓存，数据再*仓库也有存储为什么还要持久化呢？
    意外情况redis服务器不可用,如果数据都丢失了，就必须从数据库同步过来
    如果数据量很大的情况，这种操作是非常耗时的，如果请求全部都打到数据库
    数据库也是承受不了的。所以数据的持久化是很有必要的。
    
持久化方案：
    RDB；每个一定时间生成redis的完整数据内存快照。快照的时候会有IO操作，redis一边响应客户端的请求一边持久化数据，
    Redis是利用多进程COW  copy on write 机制
    
    AOF:每次写请求的日志都记录再AOF日志中，但是redis的内存是有一定限制的，不会无限的增加数据，当数据存储的量到达一定值
    以后，会根据LRU算法删除掉一部分数据，然后再存入新的数据，这样的化AOF日志文件记录的内容就会不断的增加。redis通过rewrite机制
    来确保AOF日志的内容不会无限的增加。
    
    rewrite:当AOF的日志到达一定值以后，出发rewrite,重新构建一个aof日志文件，将当前缓存中的所有数据记录再新建的的AOF  日志中，然后
    删除掉原有的AOF日志。
优缺点比较：
RDB优点：数据恢复的快，内存快照直接加载到内存就可以了
    缺点：默认是每5分钟一次快照，会有数据丢失的问题。再做RDB的时候会影响
    redis处理请求的吞吐量。对客户不友好。
AOF优点：数据写道linux oscache每1s会fysn到磁盘，最多会有1s的数据丢失。
    缺点：数据再回复的时候是一条一条语句执行的，比较耗时。
    
    
RDB配置
redis.conf文件，也就是/etc/redis/6379.conf，去配置持久化
下面是默认的配置
    
# Save the DB on disk:

save 900 1
save 300 10
save 60 10000

解释 save 时间 次数。save 60 10000 每隔60s如果有超过10000个key发生变化，就保存快照。每隔300s有10个key发生变化就生成快照，每隔900s有1个key发生变化就生成快照。
可以配置多个我们可以自行添加配置。

生成快照的位置在 /var/redis/6379/dump.rdb 数据恢复的时候也是基于这个位置的这个文件

AOF的配置:默认是关闭的 要打开 no->yes

appendonly yes

写日志的策略有三中默认是第二个
# appendfsync always  每条写日志i都会立即fsync到磁盘上 生产环境一般不会这么用，这样redis的性能会很低。qps在几千
appendfsync everysec   每隔1s把缓存中的日志fsyn到磁盘中，推荐使用这种  qps 可以上万
# appendfsync no     只把数据写入到缓存，oscache中，oscache自己有自己的策略刷新到磁盘。redis不过问

日志文件的位置 /var/redis/6379/appendonly.aof

rewrite机制
redis2.0之后的版本是自动rewrite的，我们可以配置他的参数，默认的比较重要的两个参数
auto-aof-rewrite-percentage 100 #日志文件的大小是上一次出发rewirte时的一倍
auto-aof-rewrite-min-size 64mb #数据必须大于64mb才肯出发rewirte
这个推荐使用默认的参数

在redis内部生成快照的时候不会执行rewirte 在rewirte的时候也不会同时执行rdb,他们时串行的，同时执行的化会严重影响redis的性能。

数据恢复
    1.在有rdb的dump和aof的appendonly的同时，rdb里也有部分数据，aof里也有部分数据，这个时候其实会发现，rdb的数据不会恢复到内存中
    2.数据的恢复完全依赖磁盘上的文件，只要磁盘文件中没有的数据就是丢失了。

大厂的redis持久化方案