redis的持久化机制

redis中提供了2个不同形式的持久化的方式

RDB和AOF

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

保存策略：
save 900 1 900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10 300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 1 0000 60 秒内如果至10000 个 key 的值变化，则保存

RDB的技术就是节省磁盘空间，恢复速度比较的快。
缺点就是redis在fork时候使用了写时拷贝技术，但是数据庞大的时候还是会消耗性能的
在备份周期在一定的间隔事件做一次备份，若redis意外的down掉，则可能会丢失最后一次的快照

• 什么时候会触发rdb机制的？
  shutdown时，如果没有开启aof，会触发
  配置文件中默认的快照配置
  执行命令save或者bgsave
  bgsave：会fork子进程，原理与rdb上面原理一样，系统默认触发rdb持久化都是调用的此命令
  save：是不会fork子进程的，它使用主进程进行持久化，所以会导致客户端命令发送到我们服务端得不到及时处理，所以他是阻塞的
  执行flushall命令 但是里面是空的，无意义

• AOF
  以日志的形式来记录每一个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只是追加文件但是不更改文件，redis启动之初会读取该文件的重构i数据，

AOF的重写操作
aof是以日志追加的方式将命令字符串协议保存在aof 文件中，随着我们使用redis的时间越长，最redis的操作越多，这个aof文件会越来越大，如果不做处理，总有会撑爆磁盘，所以就出现了重写，重写就是专门给aof文件廋身的，直接根据现在内存的数据，生成新的aof文件，然后去替换旧的aof文件，就可以把一下没用字符去掉，比如set k1 v1 ,然后我们del k1等等一些没用操作，这样我们的文件大小就会小很多

触发机制
当AOF文件增长到一定大小的时候Redis能够调用 bgrewriteaof对日志文件进行重写 。当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。
auto-aof-rewrite-percentage 100
当AOF文件增长到一定大小的时候Redis能够调用 bgrewriteaof对日志文件进行重写 。当AOF文件大小大于该配置项时自动开启重写

redis的主从复制

主从复制就是主机的数据更新后根据配置和策略，自动同步到备机机制，Master以写为主，Slave以读为主

读写分离，性能进行扩展
1.单机有什么问题：
单机故障
容量瓶颈
qps瓶颈
主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，mester已写为主，slaver已读为主