redis的高可用(持久化)

redis的高可用(持久化)

redis的高可用

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

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

持久化:是最简单的高可用方法,主要作用是数据备份,也就是把redis缓存在内存的数据保存到本地的硬盘当中(冷备份)

redis持久化的两种方式:

1、RDB持久化:redis在内存中的数据定时保存到磁盘(自动执行,手动执行)

2、AOF持久化:redis的操作日志,以追加的方式写入一个AOF的文件,类似于mysql的binlog

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

rdb的触发机制:

手动机制:save bgsave都可以生成RDB文件

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

bgsave:主进程会通过fork机制创建一个子进程,子进程的创建过程中,主进程会阻塞,子进程创建完毕,主进程解除阻塞。

子进程来创建rdb文件,创建完成之后,通知主进程更新通知信息

bgsave的执行流程:

bgsave就是主从复制的机制

save 900 1

900秒  当时间到900秒时,redis是数据至少发生了1次变化,就执行bgsave

save 300 10

300秒  当时间到300秒时,redis是数据至少发生了10次变化,就执行bgsave

save 60 10000

60秒   当时间到60秒时,redis是数据至少发生了10000次变化,就执行bgsave

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

/etc/redis/6379.conf文件242行:rdbcompression yes(no):开启rdb的文件压缩功能,在高并发场景建议关闭

除了配置文件中的save m n之外

主从复制,从节点执行全量复制操作,主节点会执行bgsave,把rdb文件传送给从节点

关闭主进程,shutdown之后,会自动执行rdb的持久化

启动时加载:

rdb文件被损坏,日志中会打印错误,redis会拒绝 启动

redis-check-rdb 修复rdb的持久化文件

AOF持久化:

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

AOF的实时性更好,也是主流的持久化方案

/etc/redis/6379.conf文件700行:appendonly yes

面试题:

如果出现被截断的情况该怎么办?

/etc/redis/6379.conf文件796行:aof-load-truncated yes:用于判断AOF文件,如果被截断时的行为

yes:发现被截断(写入过程中出现异常,导致文件未能完全写入)redis会尽可能的恢复文件中的数据,redis会继续运行

no:发现AOF文件被截断,redis将拒绝启动

数据的完整性要求高,就是no。注重数据服务器的可用性,就是yes

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

AOF的重写功能:

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

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

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

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

/etc/redis/6379.conf文件729行:

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

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

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

重写的触发条件是什么?

1、手动触发

redis-cli bgrewriteaof

2、自动触发

/etc/redis/6379.conf文件729行:

auto-aof-rewrite-percentage 100:文件的大小超过基准的百分比,默认值就是100,文件的超过两倍时,执行bgrewriteaof。设置为0,禁用自动触发

100M 200M 300M 400M

auto-aof-rewrite-min-size 64mb:文件大于基准值,才会进行重写,这个值是AOF文件执行重写的最小值,避免开始启动redis后,文件太小,然后频繁的进行重写

AOF重写为什么能压缩文件?

  1. 重写的过程中,过期的数据不回写入文件
  2. 无效的命令不在写入文件,数据被重复设值set test=1 set test2 删除的数据也不会写入 set test 1 del test
  3. 多条命令合并成一个。sadd test1 v1 sadd1 test1 v2 sadd test1 v3 sadd test1 v1 v2 v3

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

RDB和AOF之间的优缺点:

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

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

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

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

总结:

redis的持久化也算是高可用的一种,通过备份文件来恢复数据,冷备份

rdb:save线上禁用。bgsave

aof:实时持久化  写入的操作的命令,除了查set del会记录  get selec不计入。实时记录,恢复方式类似于MYSQL的bin-log

重写:推荐但是不必须,重写也是主进程创建一个子进程,在过程中产生的数据以及同步策略都是写入到AOF文件当中

你可能感兴趣的:(redis,数据库)