redis持久化机制
提供两种持久化策略
RDB
RDB的持久化策略：按照规则将内存的数据同步到磁盘
snapshot：快照
reids在指定的情况下会触发快照
1.自己配置的快照规则
save
只要满足下面任意一个条件，都会执行快照
save 900 1 当在900秒内被更改的key的数量大于1的时候，就执行快照
save 300 10
save 60 10000
2.save或者bgsave
save：执行内存的数据同步到磁盘的操作，这个操作会阻塞客户端的请求
bgsave：在后台异步执行快照操作，这个操作不会阻塞客户端的请求
3.执行flushall的时候
清除内存的所有数据，只要快照的规则不为空，也就是第一个规则存在，那么redis
4.执行复制的时候
快照的实现原理
redis会使用fork函数复制一份当前进程的副本（子进程），fork进程负责把内存的数据同步到磁盘的临时文件，父进程继续处理客户端请求
redis的优缺点
1.可能会存在数据丢失的请求
2.可以最大化redis的性能（优点）
实践
修改redis.conf中的appendonly yes ;重启后执行对数据的变更命令，会在bin目录下生成对应的aof文件。
auto-aof-rewrite-percentage 100 表示当前aof 文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果执行没有重写过，以启动时aof文件大小为准。
auto-aof-rewrite-min-size 64mb 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
同步磁盘数据
redi每次更改数据的时候，aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存，再通过硬盘缓存区刷新保存到文件。
#appendfsync always 每次执行写入都会进行同步，这个是最安全但是效率比较低的方式
appendfsync everysec 每一秒执行
#appendfsync no 不主动进行同步操作，由操作系统去执行，这个是最快但不安全的方式
aof文件损坏以后如何修复
通过 redis-check-aof --fix
AOF
AOF的持久化策略：每次执行命令后，把命令本身记录下来
AOF会把redis执行的每一条命令追加到磁盘文件中
需要注意的是：即使已经在redis.conf文件中把appendonly 从no改为了yes,把服务器重启了的情况也没有appendonly.aof文件时，必须要执行
redis-cli config set appendonly yes
redis-cli config set save “”
这两个命令后才会在安装目录下出现appendonly.aof文件
两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话，那么redis重启时，会优先使用AOF文件来还原数据
对数据安全性要求较高用AOF，运行丢失用rdb。
集群
复制（master、slave）
配置过程
修改slave的redis.conf文件，增加 slaveof masterip masterport
slaveof 192.168.253.101 6379
实现原理
- slave连接到master上以后，会向master发送一个SYNC的命令
- master收到SYNC的时候，会在两件事
a)执行bgsave（rdb的快照文件）
b)master会把新收到的修改命令存入到缓冲区
哨兵机制
集群（redis3.0以后）
第三方提供的集群解决方案
缓存的击穿