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主进程的性能有一定影响