redis的高可用

1.redis的高可用

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

redis的高可用含义更宽泛，正常服务是指标之一，数据容量的扩展，数据的安全性。

在redis中实现高可用技术：持久化，主从复制，哨兵模式，cluster集群

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

2.redis持久化的两种方式

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

2.AOF持久化：redis的操作日志，以追加的方式写入AOF的文件，类似于mysql的binlog

3.RDB的持久化

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

3.1 RDB的触发机制

手动机制：save bgsave都可以生产RDB文件。

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

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

3.2 手动机制save

终端

redis-cli -h 192.168.233.7 -p 6379

save

/etc/init.d/redis_6379 stop

cd /var/lib/redis/6379

ll

cp dump.rdb /opt/

/etc/init.d/redis_6379 start

flushall

exit

/etc/init.d/redis_6379 stop

cd /opt

cp dump.rdb /var/lib/redis/6379

3.2 手动机制bgsave

终端

bgsave

重开一个

tail -f /var/log/redis_6379.log

exit

/etc/init.d/redis_6379 stop

cd /vat/lib/redis/6379

ll

cp dump.rdb /opt/

/etc/init.d/redis_6379 start

flushall

exit

/etc/init.d/redis_6379 stop

cd /opt

cp dump.rdb /var/lib/redis/6379

4.AOF持久化

AOF持久化是将redis的每一次读 写 删除 命令记录到一个单纯的。aog为结尾的文件。查询操作由主进程记录，当reids重启时，再次执行AOF文件中的命令来恢复数据

4.1 持久化配置

vim /etc/redis/6379.conf

700行，开启AOF持久化功能

704 名称可以改，但是.aof不能动，否则系统无法识别

用于判断AOF文件，如果被截断时的行为

Yes：发现被截断（写入过程中出现异常，导致文件未能完全写入），Redis会尽可能的恢复文件中的数据，Redis会继续运行

No：发现AOF文件被截断，Redis将拒绝启动

数据完整性的要求高：no

注重数据服务器的可用性：yes

/etc/init.d/redis_6379 restart

vim /var/lib/redos/6379/appendonly.aof

删除不需要的步骤

4.2 AOF的重写功能

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

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

4.3 AOF同步文件策略

vim /etc/redis/6379.conf

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

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

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

4.4 重写的触发条件

1.手动触发

redis-cli bgrewriteaof

2.自动触发

vim .etc/redis/6379_conf

auto-aof-rewired-precentage 100

文件的大小查看基准的百分比，默认值就是100.文件的超过两倍时。执行bgrewriteadof.设置为0，禁用自动触发

auto-aof-rewite-min-size 64MB

文件大于基准面，才会进行重写，这个值是AFO文件执行重写的最小值。避免开始启动redis后，文件大小，然后频繁的进行重写。

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

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

2.无效的命令不在写入文件，数据被重复设置 set test=1 set test=2 。删除的数据不会写入set test 1 del test

3.多条命令合并一个。sadd test1 v1 sadd test1 v2 sadd test1 v3 sadd test1 v1 v2 v3

重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也增加了。（重写不是必须的）

5.RDB和AOF之间的优缺点

RDB的优点：文件体积小，网络传输速度很快，适合全量复制，恢复速度也比AOF要快。

缺点：做不到实时的持久化，数据如此重要，不能够容忍丢失的。另外RDB需要满足特定的格式，兼容性很差，老版本的RDB不支持新版本（redis的版本一定要一致）5.0.7

AOF的优点：秒级持久化，兼容性好。文本格式保存的命令。

缺点：文件大，恢复速度慢，AOF持久化需要频繁的向磁盘写数据，磁盘的IO压力也是很大的，对redis主进程的性能也会有一定影响。