Redis持久化意义在于故障恢复
Redis持久化方式：
AOF：只会生成一个AOF文件，内存大小是一定的，到一定时候，redis会用缓存淘汰算法LRU，自动将一部分数据从内存中给清除。当AOF文件达到一定大小的时候，会执行rewrite操作。恢复时会优先使用AOF进行恢复。使用append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，正常写入的时间是1秒一次，可以设置fsync为每次都写入，但是这样性能就会下降。redis默认是关闭的，使用appendonly来打开AOF，使用appendfsync来设置保存模式，always、everysec、no；默认everysec，一秒刷入一次。通过参数设置最小文件大小和达到比例，如果超过最小文件大小，并且超过比例，则会写入一个新的AOF日志
RDB快照：每隔一段时间生成一个全量的备份 ，备份文件只有一份，会覆盖之前的老文件。天生适合冷备，容易丢数据，不适合做第一优先恢复方案。如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒。
容灾演练，使用RDB恢复数据
如果同时开启了AOF和RDB但是AOF没有数据了，需要使用RDB恢复数据，需要先关闭AOF以及删除AOF备份文件，然后使用RDB备份文件恢复，在命令行热修改redis配置，打开AOF
1、停止redis
2、关闭AOF
3、拷贝RDB
4、重启redis
5、命令行热修改redis配置，打开AOF；redis-cli; config get appendonly; config set appendonly yes；
6、停止redis，修改redis配置文件，打开AOF，重启redis
redis压测
最简单的测试方法就是使用redis自带的，在redis/src下面有一个./redis-benchmark -h 192.168.1.123
redis高可用：
主备切换、故障转移
哨兵会检测master是否故障，故障时将slave切换为master
哨兵（Sentinal）相关：
哨兵的主要功能：
1、集群监控
2、消息通知
3、故障转移
4、配置中心
核心：
哨兵至少需要3（奇数）个实例，来保证自己的健壮性，选举的时候会用到；
问题：
异步复制：master数据还没有复制到slave，结果master就挂了，导致数据丢失
集群脑裂：
因为网络故障，导致master和哨兵、slave无法通讯，但是用户是可以正常访问的。哨兵把slave更新为master，两个master就是脑裂。此时用户的数据还在写入旧master
解决方案：
min-slaves-to-wtrite 1
min-slaves-max-lag 10
要求至少有1个slave，数据复制合同部的延迟不能超过10秒，如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再就收任何请求了
sdown和odown
sdown是主观宕机，odown是可观宕机
slave->master选举算法
slave priority越低，优先级就越高
offset越靠后，优先级越高
如果上面两个条件都一样，则选择run id小的那个
