Redis的高可用

在集群当中有一个非常重要的指标，提供正常服务的时间的百分比(365),99.9%后面的小数点越多说明越可靠。Redis 的高可用含义更加宽泛，正常服务是指标之一，数据容量的扩展，数据的安全性。

redis中高可用技术种类

1	持久化
2	主从复制
3	哨兵模式
4	cluster集群

持久化概念

是最简单的高可用方法，主要作用是数据实现备份，也就是把redis缓存在内存中的数据保存到本地的硬盘中(冷备份)

Redis持久化的两种方式

RDB持久化	redis在内存中的数据定时保存到磁盘，手动执行和自动执行
AOF持久化	redis的操作日志以追加的方式写入一个AOF的文件,类似于mysql的binlog(两种恢复方式：基于位置和基于时间)

RDB的持久化

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

Rdb的触发机制

	手动机制：save和bgsae都可以生成RDB文件
save	save创建RDB文件时,整个redis进程会被阻塞,期间redis将无法进行读写操作,直到RDB文件创建完成为止
bgsave	bgsave就是主从复制的机制,主进程通过fork机制创建一个子进程,子进程创建过程中,主进程会阻塞，子进程创建完毕后主进程解除阻塞,然后由子进程来创建RDB文件，子进程创建完成之后通知主进程更新通知

save工作流程

bgsave工作流程

自动触发机制	在自动触发RDB持久化时,redis会优先选择bgsave而不是save来进行持久化
配置文件	vim /etc/redis/6379.conf
主从复制	除了文件中的save m n(m表示秒,n表示变化的次数)之外,主从复制，从节点执行全量复制操作，直接点会执行bgsave把rdb文件传送给从节点
关闭主进程	shutdown之后，会自动执行rdb的持久化
	启动时加载：如果启动时发现rdb文件被损坏，日志中会打印错误，redis会拒绝启动 Redis-check-rdb 修复RDB的持久化文件

Vim /etc/redis/6379.conf 配置文件Save 900 1
#219行,900秒 当时间到900秒时，redis的数据至少发生了一次变化，就执行bgsave
Save 300 10
#220行,300秒 当时间到300秒时，redis的数据至少发生了10次变化，就执行bgsave
Save 60 10000
#221行,60秒  当时间到60秒时，redis的数据至少发生了10000次变化，就执行bgsave
#数据变动越多，执行时间要越短，数据变动不大，执行时间要长一点
#生产中120秒内发生了1000次变化就执行bgsaveRdbcompression yes 
#242行,开启RDB的文件压缩功能，在高并发场景建议关闭,工作中一般都是no,关闭掉dir /var/lib/redis/6379
#264行,持久化文件的位置,可以自定义

AOF持久化

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

Vim /etc/redis/6379.confappendonly yes
#700行,默认是no关闭的,把no改成yes开启AOF持久化的功能appendfilename "appendonly.aof" 
#704行,默认持久化的文件名,名字可以自定义.aof不能动面试题
aof-load-truncated yes
#796行,用于判断aof文件，如果被截断时的行为,设置为 yes 发现被截断(写入过程中出现异常，导致文件未能完全写入)redis会尽可能恢复文件中的数据,redis还会继续运行
#如果设置为 no 发现了文件被截断，redis将拒绝启动
#二者可根据需求来选择，如果追求数据完整性的要求高那就选择no，注重数据服务器的可用性选yes

Append 如何恢复文件

Vim /var/lib/redis/6379/appendnonly.aof rdb是redis的默认持久化文件，但是一旦开启AOF持久化，那么redis会以AOF的持久化文件作为最高优先级

AOF的重写功能

重写的目的与意义	随着时间增长,AOF文件当中的数据也会不断增加,AOF的文件也会越来越大,过大的AOF文件不仅仅会影响服务器的正常运行,也会导致数据恢复的时间过长.
什么是重写	文件重写是指定期的重写AOF文件,减少AOF文件的体积,AOF重写是把redis进程内的数据转化成写命令,同步到新的AOF文件当中(不会额外生成一个新的文件,只是在原有内容中进行压缩),同时不会对旧原有的AOF文件进行任何的读写操作。 声明：文件重写虽然是AOF持久化强烈推荐的,但不是必须的,没有重写并不影响redis启动时读取数据 在实际工作中会关闭自动的文件重写，而是通过定时任务来完成

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

Appendfsync  always
#729行,写入过程中，立即调用redis系统的fsync操作写入到AOF文件,如果每次写入都执行同步，硬盘的性能会有瓶颈，硬盘的寿命也会大大降低,不太推荐,默认注释Appendfsync everysec
#730行,命令写入也是调用write操作，write操作结束后，线程会返回，FSYNC同步文件操作由专门的线程，每秒调用一次，这是一个这种的策略，是性能和安全性的平衡，是redis的默认配置，也是推荐配置Appendfsync no
#731行,写入操作会调用系统的write写操作，但是它不对AOF文件进行同步，操作系统来同步，同步周期30秒,文件同步的时间不可控，这时缓冲区会堆积大量数据，数据的安全也无法保证,默认注释

重写触发条件是什么

手动触发	在客户端执行命令 redis-cli bgrewriteaof
自动触发	配置文件 vim /etc/redis/6379.conf Auto-aof-rewrite-percentage 100 Auto-aof-rewrite-min-size 64mb

手动触发工作流程

自动触发

Auto-aof-rewrite-percentage 100
#771行,文件大小超过基准的百分比，默认值为100，文件的大小超过2倍时如200时，会执行bgrewriteaof，设置为0，就是禁用自动触发，如果要使用定时任务那么要注释掉这一行Auto-aof-rewrite-min-size 64mb
#772行,表示只有文件大于基准值，才会执行重写，这个值是AOF文件执行重写的最小值，可以避免开始启动redis后，文件太小然后频繁的进行重写。

重写之后为什么能够压缩文件

1	在重写过程中如果有过期的数据是不会写入文件
2	无效的命令不再写入文件,无效命令是指数据被重复设置,删除的数据也不会写入
3	会把多条命令合并成一个,比如对同一个键值操作sadd test 1 sadd test 2  sadd test 3 会被合并成sadd test 1 2 3
重写的作用	重写之后AOF的文件当中的命令减少了,空间也少了,恢复速度也增加了 （重写不是必须,只是推荐使用）

RDB和AOF之间的优缺点

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

实验

[root@c1 ~]# systemctl stop firewalld
[root@c1 ~]# setenforce 0
[root@c1 ~]# vim /etc/redis/6379.conf
save 60 2
#221行,修改成60秒内有2次数据修改记录
[root@c1 ~]# redis-cli     #本地登录
127.0.0.1:6379> keys *
1) "t1"
127.0.0.1:6379> set t1 2
OK
127.0.0.1:6379> set t1 3
OK
[root@c1 ~]# /etc/init.d/redis_6379 stop
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
[root@c1 ~]# /etc/init.d/redis_6379 start
Starting Redis server...
[root@c1 6379]# cd /var/lib/redis/6379/
[root@c1 6379]# ls -l
总用量 4
-rw-r--r--. 1 root root 185 11月 21 15:38 dump.rdb
[root@c1 6379]# ll
总用量 4
-rw-r--r--. 1 root root 185 11月 21 15:38 dump.rdb#在插入了两次数据后,配置文件进行了更新。