Redis高可用

redis的高可用：
在集群当中有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%
redis的高可用含义更加宽泛，正常服务是指标之一，数据容量的扩展，数据的安全性。

在redis中实现高可用技术：

持久化，主从复制，哨兵模式， cluster集群。

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

redis持久化的两种方式：

1、RDB持久化：redis在内存中的数据定时保存到磁盘。（自动执行，手动执行）
2、AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于mysal的binlog

rdb的持久化：指在指定的时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化），用二进制压缩存储。保存的文件名的后缀.rdb。redis启动时，可以直接读取快照文件，实现数据恢复。

RDB的触发机制

手动触发

：save bgsave都可以生成RDB文件。

save创建RDB文件时，整个redis进程会被阻塞，期间redis将无法进行读写操作，直到RDB文件创建完成为止。

BGSAVE：主进程会通过fork机制创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕，主进程解除阻塞。子进程来创建RDB文件。创建完成之后，通知主进程更新通知信息。

• bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。

自动触发

在自动触发RDB持久化时，Redis 也会选择bgsave而不是save来进行持久化。

自动触发最常见的情况是在配置文件中通过 save m n 指定当m秒内发生n次变化时，会触发bgsave。

vim /etc/redis/6379.conf      #编辑配置文件
 ​
 ----219行--以下三个save条件满足任意一一个时，都会引起bgsave的调用
 save 900 1      #当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
 save 300 10     #当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
 save 60 10000   #当时间到60秒时，如果redis数据发生了至少10000次变化， 则执行bgsave
 ​
 ----242行--是否开启RDB文件压缩
 rdbcompression yes
 ​
 ----254行--指定RDB文件名
 dbfilename dump.rdb
 ​
 ----264行--指定RDB文件和AOF文件所在目录
 dir /var/lib/redis/6379  
 

sava 120 1000 bgsave
save 60 10000 bgsave

数据变动越多，执行的时间要越短。数据变动不大，时间间隔要长一点。

rdbcompression no
开启RDB的文件压缩功能，在高并发场景建议关闭。

其他自动触发机制

除了配置文件中的save m n之外
主从复制，从节点执行全量复制操作，直接执行bgsave,把rdb文件传送给从节点
关闭主进程，shutdown之后，会自动执行rdb的持久化。

启动时加载：

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。 服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。
Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。
redis-check-rdb修复RDB的持久化文件。

AOF持久化：

aof持久化是将redis的每一次读 写 删除命令记录到一个单独的.aof为结尾的文件。查询操作由主进程记录。当redis重启时，再次执行AOF文件中的命令来恢复数据。
AOF的实时性更好，也是主流的持久化方案。

aof-load-truncated yes
用于判断AOF文件，如果被截断时的行为.
yes：发现被截断（写入过程中出现异常，导致文件未能完全写入。），redis会尽可能的恢复文件中的数据，redis会继续运行
no:发现AOF文件被截断，redis将拒绝启动。
数据完整性的要求高，no
注重数据服务器的可用性 yes

rdb是redis的默认持久化文件，但是一旦开启AOF持久化，那么redis会以AOF的持久化文件作为最高优先级。

 AOF的开启配置

Redis服务器默认开启RDB，关闭AOF的， 要开启AOF，需要在/etc/redis/6379.conf配置文件中配置。

vim /etc/redis/6379.conf
 ----700行---修改，开启AOF
 appendonly yes
 ----704行---指定AOF文件名称
 appendfilename "appendonly.aof"
 ----796行---是否忽略最后一条可能存在问题的指令
 aof-load-truncated yes   
 #Redis恢复时，发现AOF文件的末尾被截断了，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能发生redis机器运行崩溃，AOF文件的末尾被截断了，这种情况下，yes会继续执行并恢复尽量多的数据，而no会直接恢复失败报错退出。
 ​
 ​
 /etc/init.d/redis_6379 restart    #重启redis
 ls /var/lib/redis/6379/      #查看是否生成了aof文件

AOF的重写功能：

1随着时间增长，AOF文件当中的数据也会不断增加。AOF的文件也会越来越大。过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复的时间过长。

文件重写是指定期的重写AOF文件，减小AOF文件的体积。AOF重写是把redis进程内的数据，转化为写命令，同步到新的AOF文件当中（不会额外的生成一个新的文件，只是在原内容中进行压缩）。不会对原有的AOF文件进行任何读，写的操作。

*文件重写虽然是AOF持久化强烈推荐的，但不是必须的。没有重写，并不影响redis启动时读取数据。在实际中，会关闭自动的文件重写。通过定时任务来完成。

AOF同步文件策略的三种方式：

1.appendfsync always:写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，这次写入都执行同步，硬盘的性能有瓶颈。硬盘的寿命也会大大降低。

2.appendfsync no:写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区会堆积大量数据，数据的安全也无法保证。

3.appendfsync everysec：命令写入，调用write操作，write操作结束后，线程会返回。FSYNC同步文件操作由专门的线程，每秒调用一次。这是一个折中的策略，是性能和安全性的平衡，是redis的默认配置。也是推荐配置。

重写的触发条件

1、手动触发

redis-cli bgrewriteaof

直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。

2、自动触发。

通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

vim /etc/redis/6379.conf
 ----771行----
  771 auto-aof-rewrite-percentage 100
  772 auto-aof-rewrite-min-size 64mb
 ​
 -----------------------以下是注释--------------------------------
 ● auto-aof-rewrite-percentage 100  
 #文件的大小超过基准百分之多少后触发bgrewriteaof。默认这个值设置为100，意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。
 #即当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作。
 #注意：例如上次文件达到100M进行重写，那么这次需要达到200M时才进行重写。文件需要越来越大，所以一般不使用自动重写。如果使用自动重写，需要定期手动重写干预一次，让文件要求恢复到100M。
 ​
 ● auto-aof-rewrite-min-size 64mb      #当文件大于64M时才会进行重写
 #当前aof文件大于多少字节后才触发。
 #当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF

AOF重写为什么能够压缩文件：

1、重写的过程中，过期的数据不会写入文件

2、无效的命令不再写入文件，数据被重复设值set test=1 set test 2,删除的数据也不会写入set test 1 del test

3、多条命令合并成一个。sadd test1 v1 sadd test1 v2 sdd test1 v3 sadd test1 v1 v2 v3
重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也增加了。（重写不是必须的。）

RDB和AOF之间的优缺点：

RDB
优点：文件体积小，网络传输速度很快，适合全量复制。恢复速度也比AOF要快。
缺点：做不到实时的持久化，数据如此重要，不能够容忍丢失的。另外RDB需要满足特定的格式，兼容性很差。老版本的RDB不支持新版本。 (redis的版本一定要一致) 5.0.7
AOF
优点：秒级持久化。兼容性好。文本格式保存的命令。
缺点：文件大，恢复速度慢。AOF持久化需要频繁的向磁盘写数据，磁盘的IO压力也很大。对redis主进程的性能也会有一定的影响。

redis的持久化也算是高可用的一种，通过备份文件来恢复数据，冷备份。
rdb：sava线上禁用。bgsave:
AOF：实时持久化 写入的操作的命令，除了查set del会记录 get select不计入。实时词录，恢复方式类似于MYSQL的bin-log重写：推荐但是不必须的。重写也是主进程创建一个子进程，在过程中产生的数据以及同步策略都是写入到AOF文件当中。