Redis的高可用

Redis的高可用：

在集群当中有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%

Redis的高可用含义更加宽泛，正常服务是指标之一，数据容量的扩展，数据的安全，在Reid中实现高可用技术：持久化，主从复制，哨兵模式，cluster集群

持久化：持久化是最简单的高可用方法，主要作用是数据实现备份，也就是把Redis缓存在内存中的数据保存到本地的硬盘当中（冷备份）

Redis持久化的两中方式：

1.RDB持久化：Redis在内存中的数据定时保存到磁盘。（自动执行，手动执行也可以）

1. 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重写为什么能够压缩文件：

1. 重写的过程中，过期的数据不会写入文件
2. 无效的命令不再写入文件，也就是数据被重复设置（例：set test=1 set test 2），删除的数据据也不会写入 (例：set test 1 del test)
3. 多条命令合并成一个，例如：sadd test1 v1 sadd test1 v2 sadd test v3 会合并成set test2 v1 v2 v3
4. 重写之后，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秒，文件同步的时间不可控，缓冲区的数据太多，数据的安全也无法保证

重写的触发条件是什么？

1. 手动触发

redis-cli bgrewriteaof

手动触发的工作流程：

重写的核心：创建子进程，主进程会阻塞，新的AOF文件由三部分组成

结合定时任务

1. 自动触发

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文件当中