文章目录
- RDB简介
- 持久化触发条件
- RDB的优缺点
- AOF简介
- AOF的三种持久化规则
- AOF的重写机制
- AOF文件修复
- AOF的优缺点
RDB简介
RDB是Redis默认用来进行持久化的一种方式,根据配置文件中的save m n配置自动触发bgsave将当前内存中的数据集以快照的方式写入到磁盘中并生成一个.rdb文件,文件默认叫做dump.rdb。恢复数据时也是通过解析dump.rdb中的数据到内存中。
持久化触发条件
RDB持久化的触发分为手动触发和自动触发两种。
1)手动触发
save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求。(基本已废弃,效率太慢)
(ps:拿网络中的一副图给大家举例展示)
bgsave命令会创建一个子进程,由子进程来负责创建RDB文件,父进程(即Redis主进程)则继续处理请求。(rdb最主要的持久化方式)
bgsave持久化,redis会单独创建(fork)一个子进程来进行持久化操作,将数据写入到一个临时文件中,等持久化过程正常结束后,再用这个临时文件替换上次持久化好的.rdb文件。
整个过程,主进程不会进行任何IO操作,且只有fork的子线程时会阻塞服务器,同时也可以处理其他客户端发来的请求,这就确保了极高的性能。
(ps:拿网络中的一副图给大家举例展示)
另外在执行shutdown丶flushdball等敏感命令时也会触发bgsave,目的是防止还没触发自动持久化的阀值时,造成数据丢失的问题。
2)自动触发
自动触发最常见的情况是在配置文件中通过save m n的规则,指定当m秒内至少发生n次变化时,达到了自动触发的阀值,会触发bgsave。
其中save 900 1的含义是:900秒内redis数据发生了至少1次变化,则执行bgsave;save 300 10和save 60 10000同理。当三个save条件满足任意一个时,都会引起bgsave的调用。
RDB的优缺点
优点
1.效率高,每次持久化都是通过frok一个子线程来进行,且主线程不用进行IO操作。
2.数据恢复快,适合大规模恢复数据。
3.恢复数据比较简单,只用将dump.rdb放到redis的安装目录下即可。redis启动时自动解析指定目录下的dump.rdb文件,然后渲染到内存中。可在redis命令行通过CONFIG GET dir 命令获取安装目录
缺点:
1.持久化不是实时的,是根据自动持久化的阀值触发持久化,也就是说还没有打到阀值,触发自动持久化时服务器断电,就会导致最后一次还未进行持久化的数据丢失。
2.bgsave时占用内存,因为Redis 在持久化时会独立创建一个子进程,将当前时间节点下的数据写入到一个临时文件,如果不采用压缩算法(此时内存中的数据就是原来的两倍),最后才会将临时文件替换之前的备份文件,内存中临时的数据才会消失。(因此不要频繁进行持久化操作)
AOF简介
aof是redis持久化技术之一,它就是改写操作日志,通过记录每次对redis改写的操作,并追加到appendonly.aof文件中(ps:实际上就是一个历史操作记录文件,但不记录读操作),然后每次启动redis恢复数据时,就是将appendonly文件中的改写命令全部重新执行一遍。
AOF的三种持久化规则
aof默认不开启,如果要开启则将redis.conf中的appendonly 改为yes,然后重启redis即可。
appendfsync always #每次修改都会进行同步保存,消耗性能 appendfsync everysec #每秒执行一次同步保存,但可能丢失一秒的数据 appendfsync on #永不同步AOF的重写机制
AOF的工作原理是将写操作追加到文件中,文件的冗余内容会越来越多。所以Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。
触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。
重写的原理:Redis 会fork出一条新进程,读取内存中的数据,保证结果不变的前提下以更少的redis命令重新写到一个临时文件中,并不会读取旧文件也没有去改变旧文件(因为太大了)最后替换旧的aof文件。
举例:
如果服务器对键 list 执行了以下四条命令:
RPUSH list 1 2 3 4 // [1, 2, 3, 4] RPOP list // [1, 2, 3] LPOP list // [2, 3] LPUSH list 1 // [1, 2, 3]那么当前列表键 list 在数据库中的值就为 [1, 2, 3] 。
在没有重写之前我们的aof文件中就会将上面4条命令都记录下来,而触发重写时则会读取当前内存中list的值,然后用RPUSH list 1 2 3来代替前面的4条命令。通过直接读取redis中的值,优化语句便可以压缩aof文件的大小并提高恢复数据的效率。
AOF文件修复
如果aof有错误,那么在启动redis时,启动则失败。
此时我们可以通过redis自带的redis-check-aof --fix指定文件进行修复。
redis-check-aof --fix appendonly.aofAOF的优缺点
优点:
1.数据完整性高,如果公司内对缓存数据有非常高的数据完整性要求,则可使用aof。
缺点:
1.数据恢复慢,因为是重新执行一遍改写操作。
2.因为是实时性,所以效率比rdb慢。