- redis作为当今最火热的nosql数据库,无论在互联网领域还是在传统金融,电信等领域都是备受推崇!作为一名IT从业者,去理解掌握redis的背后的设计理念对于灵活使用redis还是非常有必要的。
- RDB与AOF可以同时运行,redis在启动时,如果发现开启aof,则会优先加载aof文件。
RDB持久化
- 原理:RDB持久化每次都是全量存储,保存某一个时刻的所有数据快照。保存RDB时,父进程fork出一个子进程,由子进程进行持久化,子进程将父进程当前时刻的数据生成新的rdb文件,替换旧RDB文件。然后通知父进程。
- 父进程fork完子进程后,继续响应客户端请求,但是父进程在创建fork过程中对于客户端是阻塞的。
- RDB持久化原理如下图所示:
-
触发持久化方式
手动触发:手动触发有save和bgSave两种方式。
- save:生产环境不建议使用,消耗资源比较严重,属于阻塞模
- bgSave:触发父进程fork出子进程方式,如上图所示。
自动触发:可以通过设置配置文件设置,进行自动触发持久化
上图表示:
save 900 1表示在900秒后,如果有1个key发生改变,则触发持久化
save 300 10 在300秒后,如果有10个key发生改变,则触发持久化
save 60 10000在60秒后,有10000个key发生改变,则触发持久化
RDB持久化优点
- 文件比较紧凑,体积较小,适合备份
- 数据恢复时速度比AOF方式要快
- 保存文件时,可以通过子进程进行生成RDB文件
RDB缺点
- RDB不能实时或秒级持久化数据,需要手动触发或者设置成一定条件 才可以。
- 数据量巨大时,RDB非常消耗资源,性能不高
- 服务器发生宕机时,容易丢失一定时间内的数据,对于数据要求比较高的业务场景时不适用
AOF持久化
相对于RDB的持久化,redis更建议使用aof方式持久化。先通过一张aof原理图去了解吧!
原理:aof采用文件追加的方式进行文本存储,不同于rdb的二进制存储方式。redisf服务端每次收到client请求的修改,写入命令先存入缓存中(aof_buf),直接操作磁盘性能会受到影响,最终都会将缓存中的命令和数据写入到aof文件中。aof追加文件的方式最大程度上保证了数据持久化,但是aof文件相比rdb文件要大很多。
AOF文件刷盘策略:
1. 在从aof_buf中往磁盘写入文件时,redis提供了三种aof文件刷盘策略默认采用每秒刷盘一次:
- always:每次有新增写入命令,都会调用fsync函数追加到aof文件中,性能最慢,数据最安全。
- no:调用write函数将缓存中的数据写入系统缓冲区即返回。由os每隔30秒将数据追加到aof文件中,性能最高,数据不安全。
- everysec:每秒刷盘一次,默认配置,兼顾了数据安全和性能。redis调用write函数将内存中的数据写入系统缓冲区后,即返回。由os每隔一秒调用fsync()函数将系统缓冲区的数据追加到磁盘中。这种方式,服务器宕机时,一般会丢失1秒左右系统缓冲区的数据。
- 下图就是redis中的aof配置:
AOF文件重写
**目的:**aof持久化是将所有的命令以追加的方式写入aof文件。这就造成了aof文件中存储了大量的无效命令。aof文件重写将aof文件中的无效命令,多余的命令进行合并(多次修改同一个key的值)去掉,使得aof文件存储的是数据的最终状态。这样aof文件会节省一部分磁盘空间。通过下图来了解一下aof重写的原理:
触发方式
重写可以手工调用bgrewriteaof命令或者自动触发该命令。
2. 流程:
- bgrewriteaof命令触发aof重写,父进程收到该触发命令时,会fork出子进程(父进程fork子进程时是阻塞的)。
- 子进程将redis内存中的数据重新写入新的aof文件中,重写过程只会保存数据的最终状态,无用的命令将会被抛弃。
- 父进程fork出子进程后,会继续响应client的请求,同时将新增的修改,写入命令写入aof_rewrite_buf中。即,后续的client请求写,修改命令既要写入原有的aof文件中,同时还追加到aof_rewrite_buf中。
- 子进程生成新的aof文件后通知父进程,父进程会将aof_write_buf中的内容追加到新的aof文件中。同时将新aof文件替换旧的aof文件。
- 子进程生成新的aof文件过程,先将数据写入到OS缓存中,然后根据持久化刷盘策略,调用OS函数fsync写入到aof文件中。
AOF持久化优点
- 持久化策略多,主要有always,no,fsync。
- 相对RDB,可以做到实时/秒级持久化,数据丢失最少。即使服务器宕机,也只会丢失极少数部分数据。
- redis在后台可以自动重写aof文件,同时redis可以继续将现有的修改,写入命令追加到aof文件,aof文件不断的重写,使得aof文件可以一直在压缩存储。
- aof文件保存了所有了修改,写入命令。
AOF持久化缺点
- aof文件通常比RDB文件要大很多,因为不仅需要保存数据同时还需要保存修改,写入命令。
- 海量数据恢复时,aof比RDB要慢。
- 容易发生redis阻塞。同步线程每秒将aof_buf内容刷新到aof文件中。如果超过2秒,redis主线程将会阻塞。