redis的高可用之持久化
1、redis的高可用考虑指标
（1）正常服务
（2）数据容量的扩展
（3）数据的安全性
2、redis实现高可用的四种方式
（1）持久化
（2）主从复制
（3）哨兵模式
（3）cluster集群
3、持久化的两种方式【重点】
（1）RDB持久化：redis在内存中的数据定时保存到磁盘中
自动机制
1）配置文件vim /etc/redis/6379.conf
①一定时间内redis数据发生变化，bgsave更新
save 120 1000（生产中常用）
save 60 10000（生产中常用）
数据变动越多，执行的时间越短；数据变动不多，执行的时间越长
②rdb文件的压缩功能
③持久化文件的位置
2）主从复制：若从节点执行的是全量复制操作，主节点会执行bgsave，将.rdb文件传送给从节点
3）关闭主进程shutdown后，会自动执行.rdb的持久化
手动机制
①save（工作中禁用）
②bgsave（redis主从复制的默认机制）
（2）AOF持久化：redis的操作日志以追加的方式写入AOF的文件
①自动机制
②重写功能
1）手动触发redis-cli bgrewriteaof
2）自动触发vim /etc/redis/6379.conf
【重点】.aof文件出现截断的情况下，该怎么做？（经验）
aof-load-truncated yes #判断.aof文件被截断时的行为
设置成yes，表示发现.aof文件被截断，redis在修复时尽可能的恢复.aof文件中的数据，且redis会继续运行
4、AOF备份和恢复【重点】
停止redis服务/etc/init.d/redis_6379 stop
在appendonly.aof文件中删除不需要的操作，即可恢复数据
重启redis服务/etc/init.d/redis_6379 restart
注：RDB是redis的默认持久化，但一旦开启AOF持久化，那么reids会以AOF的持久化文件作为最高优先级
5、AOF的重写功能【重点】
随着时间增长，AOF文件中的数据也会随之增加，AOF文件也随之变大，过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复时间过长
文件重写是指定期的重写AOF文件，减小AOF文件的体积，AOF重写是将redis进程的数据，转化为写命令，同步到新的AOF文件中（不会额外生成一个新的AOF文件，只是在原内容中进行压缩），不会对原有的AOF文件进行任何读写操作
注：文件重写虽是AOF持久化推荐的，但不是必须的【重点】
没有重写，不影响redis启动时读取数据，在实际工作中，会关闭文件重写功能，通过定时任务完成。具体重不重写，根据业务需求来看
AOF重写为什么能压缩文件？
①重写过程中，过期的数据不会写入文件
②重写过程中，无效的命令不再写入文件，数据被重复设置，例如set test 1，set test 2，删除的数据也不会写入set test 1 ，del test
③重写过程中，会将多条命令合并成一个。例如sadd test1 1 ，sadd test1 2 ，sadd test1 3 ，压缩成sadd test1 1 2 3。重写之后AOF文件中的命令减少了，占用空间减少了，恢复速度增加了
6、RDB和AOF的优缺点
（1）RDB持久化
优点：RDB文件体积小，备份数据时网络传输速度块，适合全量复制，恢复速度比AOF快
缺点：①无法实时持久化，数据非常重要，无法容忍丢失，所以AOF成为主流
②RDB需要满足特定的格式，兼容性差，新旧版本不兼容（reids版本必须一致，redis版本5.0.7）
（2）AOF持久化
优点：秒级持久化，兼容性好（.aof是文本格式保存的命令，命令是通用的）
缺点：.aof文件大，恢复速度慢，AOF持久化需频繁的向磁盘写入数据，磁盘的I/O压力大，对redis主进程的性能有一定影响