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