redis高可用之持久化

一、redis持久化概述

1、redis高可用:

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

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

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

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

2、redis持久化的两种方式:

  1. RDB持久化:redis在内存中的数据定时保存到磁盘。(自动执行,手动执行)
  2. AOF持久化:redis的操作日志,以追加的方式写入一个AOF的文件,类似于MySQL的binlog

由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,

不过RDB持久化仍然有其用武之地。

二、RDB的持久化:

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

1、RDB的触发机制:

是冷备份:每次同步要关闭服务

1.1、手动机制:save、bgsave

savebgsave都可以生成RBD文件。

用save创建RDB文件时,redis服务的主进程将被阻塞,期间redis将无法再进行读写操作,直到RDB文件创建完成为止

生产中禁止用save保存,都用bgsave

文件位置:/var/lib/redis/6379

冷备份:要关闭服务

每一次重启自动读取文件

redis高可用之持久化_第1张图片

bgsave

fork子进程,子进程创建RBD文件

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

1.2、bgsave执行流程:

1、redis主进程判断是否执行save或bgsave、bgrewriteaof的子进程。如果在执行则bgsave命令直接返回。bgsave/bgwriteaof的子进程不能同时执行

原因:两个并发的子进程同时执行大量的磁盘写操作,可能引起严重的性能问题

2、主进程执行fork操作创建子进程,这个过程中主进程是阻塞的,redis不能执行来自客户端的任何命令

3、子进程创建完毕之后,主进程会解除阻塞。

4、由子进程来创建RDB文件。创建完成之后,通知主进程更新通知信息

redis高可用之持久化_第2张图片

1.3、恢复过程:

1、执行完数据之后:bgsave

2、cp /var/lib/redis/6379/dump.rdb /opt

3、删除原文件,将备份文件恢复。

1.4、自动触发机制:

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

vim /etc/redis/6379.conf

219行 默认的三个机制

save m n

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

save 900 1

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

save 300 10

300秒内,redis数据至少发生10次变化,就执行bgsave

save 60 10000

60秒内,redis数据至少发生10000次变化,就执行bgsave

工作中:

save 120 1000 bgsave

save 60 10000 bgsave

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

242行

rdbcompression yes

开启RDB到达文件压缩功能,在高并发场景建议关闭(改成no)

264行

dir /var/lib/redis/6379

保存持久化文件的位置,可自定义

除了配置文件中的save m n之外,还有哪些自动触发机制:

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

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

启动时加载:

启动时,如果RDB文件被损坏,日志中会打印错误,redis会拒绝启动

redis-check-rdb工具 会修复RDB的持久化文件

恢复过程:

1、执行完数据之后:bgsave

2、cp /var/lib/redis/6379/dump.rdb /opt

3、删除原文件,将备份文件恢复。

三、AOF持久化:

AOF持久化是将redis的每一次读、写、删除命令记录到一个单独的以.aof结尾的文件(查询操作不记录,查询操作是由主进程记录)

当redis重启时,再次执行AOF文件中的命令来恢复数据。

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

1、配置

vim /etc/redis/6379.conf

700行

appendonly on改成yes,开启AOF功能

704行 默认的文件名

名字可以自定义,但是后缀不能改,要.aof

796行

aof-load-truncated yes

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

截断:写入过程中出现异常,导致文件未能完全写入

yes:发现被截断,redis在启动时会尽可能的修复数据,redis会继续运行

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

数据的完整性的要求高,选no

注重数据服务器的可用性,选yes。一般要保证可用

vim /var/lib/redis/6379/aof文件

自己进去删

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

2、重写:

AOF的重写功能:

  1. 随着时间的增长,AOF文件中的户数也会不断增加。AOF的文件也会越来越大。过大的AOF文件不仅仅会影响服务器的正常运行,也会导致数据恢复的时间过长。
  2. 文件重写是指定期的重写AOF文件,目的是减小AOF文件的体积。AOF重写是把redis进程内的数据转化为写的命令,同步到新的AOF文件当中(不会额外的生成新的文件,只是在原内容中进行压缩)。不会对原有的AOF文件进行任何读、写操作

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

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

策略的三种方式

配置文件

729行

appendfsync always

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

appendfsync everysec

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

appendfsync no

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

重写的触发条件:

  1. 手动触发

命令:

redis-cli bgrewriteaof

手动触发的工作流程:

1、Redis父进程首先判断当前是否存在正在执行bgsave/bgrewriteaof的子进程,

如果存在则bgrewriteaof命令直接返回,如果存在 bgsave命令则等bgsave执行完成后再执行。

2、父进程执行fork操作创建子进程,这个过程中父进程是阻塞的。

3.1、父进程fork后,bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程,

并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区,并根据appendfsync策略同步到硬盘,保证原有AOF机制的正确。

3.2、由于fork操作使用写时复制技术,子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令,

因此Redis使用AOF重写缓冲区(aof_rewrite_buf)保存这部分数据,防止新AOF文件生成期间丢失这部分数据。

也就是说,bgrewriteaof执行期间,Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

4、子进程根据内存快照,按照命令合并规则写入到新的AOF文件。

5.1、子进程写完新的AOF文件后,向父进程发信号,父进程更新统计信息,具体可以通过info persistence查看。

5.2、父进程把AOF重写缓冲区的数据写入到新的AOF文件,这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。

5.3、使用新的AOF文件替换老文件,完成AOF重写。

redis高可用之持久化_第3张图片

  1. 自动触发

看配置文件

vim /etc/redis/6379.conf

771行 772行

自动触发rewrite机制

auto-aof-rewrite-percentage 100

文件的大小超过基准的百分比,默认值就是100(%),文件的大小超过两倍时,执行bgrewrite。设置为0,禁用自动触发

100M执行 下一次200M执行 下一次400M执行 下一次就是800M执行

若要设置crontab定时任务,这个配置要设0

auto-aof-rewrite-min-size 64mb

这个配置必须要存在

表示只有文件大于基准值,才会进行重写。这个值是AOF执行重写命令的最小值,避免开始启动redis后,文件太小频繁的进行创建

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

  1. 在重写的过程中,过期的数据不会写入文件
  2. 重写的过程中,无效的命令(数据被重复设置)不再写入文件,删除的数据也不会写入
  3. 多条命令合成一个。sadd test1 v2 sadd test 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(实时持续化)

写入的操作的命令,除了查(get、select)。set、del这种写入命令会记录。实际记录,不需要停机,恢复方式类似于MySQL的binlog

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

gbsave 配置文件 900

重复数据是否会被记录

你可能感兴趣的:(redis,redis,数据库,缓存,架构)