<返回更多

彻底理解Redis持久化

2020-03-03    
加入收藏

大家都知道redis一个内存数据库,它支持2种持久化方式: RDB(Snapshot 内存快照) , AOF(Append only file) 。持久化功能将内存中的数据同步到磁盘来避免Redis发生异常导致数据丢失的情况。当Redis实例重启时,即可利用之前持久化的文件实现数据恢复。

接下来,本文介绍两种持久化的运行机制和优缺点。

一 RDB

RDB是默认的持久化方式,按照一定的策略周期性的将内存中的数据生成快照保存到磁盘。

每次快照持久化都是将内存数据完整写入到磁盘一次,并不 是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。

1.1 快照持久化过程

彻底理解Redis持久化

 

1.2 触发机制

1. save 命令

当客户端向Redis server发送save命令请求进行持久化时,由于Redis是用一个主线程来处理所有,save命令会阻塞Redis server处理其他客户端的请求,直到数据同步完成。

2. bgsave命令

与save命令不同,bgsave是异步执行的,当执行bgsave命令之后,Redis主进程会fork 一个子进程将数据保存到rdb文件中,同步完数据之后,对原有文件进行替换,然后通知主进程表示同步完成。

3. 自动触发

除了手动触发RDB持久化,Redis内部还存在自动触发机制,

在配置中集中配置 save m n 的方式,表示 m秒内数据集存在n次修改时,系统自动触发bgsave 操作。

从节点执行全量复制操作,主节点自动执行bgsave 生成RDB文件并发送给从节点

默认情况下执行 shutdown 命令时,如果没有开启AOF持久化功能,系统会自动执行bgsave命令。执行debug reload 命令重新加载Redis时,也会自动触发save操作。

1.3 相关参数

1.4 RDB的优缺点

优点

RDB文件小,非常适合定时备份,用于灾难恢复。

因为RDB文件中直接存储的是内存数据,而AOF文件中存储的是一条条命令,需要应用命令。Redis加载RDB文件的速度比AOF快很多。

缺点

RDB持久化方式不能做到实时/秒级持久化。实时持久化要全量刷内存到磁盘,成本太高。
每秒fork子进程也会阻塞主进程,影响性能。RDB文件是二进制文件,随着Redis不断迭代有多个rdb文件的版本,
不支持跨版本兼容。老的Redis无法识别新的RDB文件格式。

二 AOF

AOF(Append-only file)针对RDB的缺点做了优化,在使用AOF持久化方式时,Redis会将每一个收到的 写操作命令 都通过Write函数追加到文件最后,类似于MySQL的binlog。当Redis重启时会通过重新执行文件中保存的 写命令 来在内存中重建整个数据库的内容。

2.1 AOF持久化过程

彻底理解Redis持久化

 

1. 客户端发出 bgrewriteaof命令。

2. redis主进程fork子进程。

3. 父进程继续处理client请求,除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存到 AOF重写缓冲区 。这样就能保证如果子进程重写失败的话并不会出问题。

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

5. 当子进程把内存快照写入临时文件中后,子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。

6. 现在父进程可以使用临时文件替换老的aof文件,并重命名,后面收到的写命令也开始往新的aof文件中追加。

2.2 相关参数

2.3 日志重写

AOF机制将客户端的每一个写操作都追加到aof文件末尾,比如将一个key多次执行incr,set命令,会写入多次命令到aof文件,aof文件会越来越大,部分核心业务每天的写入量有几十G的大小。

恢复Redis实例时,加载非常大的aof文件耗时会很长。为了解决这个问题,Redis 支持aof文件重写--把Redis进程内的数据转化为写命令同步到新AOF文件中的过程。通过重写,可以生成一个最小的命令集合。比如上面的几个命令可以合并为

写入数据的规则

1. 进程内过期的数据不用在写入

2. 旧AOF文件含有的无效命令 del k1, set a 1, set a 2。重写使用进程内的数据直接生成,aof文件就保留最新的命令集合。

3. 多条命令可以合并为一个命令,为了防止单个命令过大造成客户端缓冲区溢出,对于list,set,hash,zset 等类型的操作,以64个元素为界拆分为多条。

触发机制

彻底理解Redis持久化

 

1. 手动触发 执行bgrewriteaof命令。

2. 根据配置自动触发

auto-aof-rewrite-min-size 表示运行AOF重写是文件最小的大小。默认64M,小于64M就会不自动重写了。

auto-aof-rewrite-percentage 表示( aof_current_size - aof_base_size ) / aof_base_size 的比值。

aof文件重写之后当前文件大小增长多少就触发重写

自动触发时机 :

aof_current_size > auto-aof-rewrite-min-size

 

&&

 

( aof_current_size - aof_base_size ) / aof_base_size >= auto-aof-rewrite-percent

 

age

三 RDB VS AOF 对比

具体使用哪种持久化方式 ,下面是来自官方的建议:

通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。

生产上的实例大多不会是单点,而是主从,也有利用slave作为持久化方式,同时满足HA的需求。读者朋友可以分享一下各自遇到的和 redis 持久化相关的问题。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍最近更新
更多资讯 >>>