redis的高可用（持久化）
redis的高可用（持久化）
redis的高可用
在集群当中有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%
redis的高可用含义更加宽泛，正常服务是指标之一，数据容量的扩展，数据的安全性。在redis中实现高可用的技术：持久化，主从复制，哨兵模式，cluster集群
持久化：是最简单的高可用方法，主要作用是数据备份，也就是把redis缓存在内存的数据保存到本地的硬盘当中（冷备份）
redis持久化的两种方式：
1、RDB持久化：redis在内存中的数据定时保存到磁盘（自动执行，手动执行）
2、AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于mysql的binlog
RDB的持久化：只在指定的时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化），用二进制压缩存储，保存的文件名的后缀.rdb，只要redis启动时，可以直接读取快照文件，实现数据恢复
rdb的触发机制：
手动机制：save bgsave都可以生成RDB文件
save创建RDB文件时，整个redis进程会被阻塞，期间redis将无法进行读写操作，直到rdb文件创建完成为止
bgsave：主进程会通过fork机制创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕，主进程解除阻塞。
子进程来创建rdb文件，创建完成之后，通知主进程更新通知信息
bgsave的执行流程：
bgsave就是主从复制的机制
save 900 1
900秒 当时间到900秒时，redis是数据至少发生了1次变化，就执行bgsave
save 300 10
300秒 当时间到300秒时，redis是数据至少发生了10次变化，就执行bgsave
save 60 10000
60秒 当时间到60秒时，redis是数据至少发生了10000次变化，就执行bgsave
数据变动越多，执行的时间越短，数据变动不大，时间间隔要长一点
/etc/redis/6379.conf文件242行：rdbcompression yes（no）：开启rdb的文件压缩功能，在高并发场景建议关闭
除了配置文件中的save m n之外
主从复制，从节点执行全量复制操作，主节点会执行bgsave，把rdb文件传送给从节点
关闭主进程，shutdown之后，会自动执行rdb的持久化
启动时加载：
rdb文件被损坏，日志中会打印错误，redis会拒绝 启动
redis-check-rdb 修复rdb的持久化文件
AOF持久化：
aof持久化是将redis的每一次读 写 删除命令记录到一个单独的.aof为结尾的文件。查询操作由主进程记录。当redis重启时，再次执行AOF文件中的命令来恢复数据
AOF的实时性更好，也是主流的持久化方案
/etc/redis/6379.conf文件700行：appendonly yes
面试题：
如果出现被截断的情况该怎么办？
/etc/redis/6379.conf文件796行：aof-load-truncated yes：用于判断AOF文件，如果被截断时的行为
yes：发现被截断（写入过程中出现异常，导致文件未能完全写入）redis会尽可能的恢复文件中的数据，redis会继续运行
no：发现AOF文件被截断，redis将拒绝启动
数据的完整性要求高，就是no。注重数据服务器的可用性，就是yes
rdb是redis的默认持久文件，但是一旦开启AOF持久化，那么redis会以AOF的持久化文件作为最高优先级
AOF的重写功能：
- 随着时间增长，AOF文件当中的数据也会不断的增加。AOF的文件也会越来越大，过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复的时间过长。
文件重写是指定期的重写AOF文件，减小AOF文件的体积，AOF重写是把redis进程内的数据，转化为写命令，同步到新的AOF文件当中（不会额外的生成一个新的文件，只是在原有的内容中进行压缩），不会对原有的AOF文件进行任何读，写的操作
*文件重写虽然是AOF持久化强烈推荐的，但不是必须的，没有重写，并不影响redis启动时读取数据，在实际中，会关闭自动的文件重写。通过定时任务来完成
AOF同步文件策略的三种方式：
/etc/redis/6379.conf文件729行：
# appendfsync always：写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，这次写入都执行同步，硬盘的性能有瓶颈，硬盘的寿命也会大大降低
appendfsync everysec：命令写入，调用write操作，write操作结束后，线程会返回，FSYNC同步文件操作由专门的线程，每秒调用一次。这是一个折中的策略，是性能和安全性的平衡，是redis的默认配置，也是推荐配置
# appendfsync no：写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区会堆积大量数据，数据的安全也无法保证
重写的触发条件是什么？
1、手动触发
redis-cli bgrewriteaof
2、自动触发
/etc/redis/6379.conf文件729行：
auto-aof-rewrite-percentage 100：文件的大小超过基准的百分比，默认值就是100，文件的超过两倍时，执行bgrewriteaof。设置为0，禁用自动触发
100M 200M 300M 400M
auto-aof-rewrite-min-size 64mb：文件大于基准值，才会进行重写，这个值是AOF文件执行重写的最小值，避免开始启动redis后，文件太小，然后频繁的进行重写
AOF重写为什么能压缩文件？
- 重写的过程中，过期的数据不回写入文件
- 无效的命令不在写入文件，数据被重复设值set test=1 set test2 删除的数据也不会写入 set test 1 del test
- 多条命令合并成一个。sadd test1 v1 sadd1 test1 v2 sadd test1 v3 sadd test1 v1 v2 v3
重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也增加了（重写不是必须的）
RDB和AOF之间的优缺点：
RDB的优点：文件体积小，网络传输速度快，适合全量复制，恢复速度也比AOF要快
缺点：做不到实时的持久化，数据如此重要，不能够容忍丢失的。另外RDB需要满足特定的格式，兼容性很差。老版本的RDB不支持新版本（redis的版本不一定要一致）5.0.7
AOF的优点：秒级持久化，兼容性好。文本格式保存的命令
缺点：文件大，恢复速度慢，AOF持久化需要频繁的向磁盘写数据，磁盘的IO压力也很大。对redis主进程的性能也会有一定的影响
总结：
redis的持久化也算是高可用的一种，通过备份文件来恢复数据，冷备份
rdb：save线上禁用。bgsave
aof：实时持久化 写入的操作的命令，除了查set del会记录 get selec不计入。实时记录，恢复方式类似于MYSQL的bin-log
重写：推荐但是不必须，重写也是主进程创建一个子进程，在过程中产生的数据以及同步策略都是写入到AOF文件当中