Redis的数据是全部存储在内存之中,但如果这时候Redis服务宕机,那存储在内存中的数据也会一并丢失,所以为了让redis的数据避免丢失或者是少丢失一点,就要利用策略来将redis的数据存入到磁盘之中,所以就诞生了redis的持久化。即Redis持久化的意义就是为了保证突然宕机,内存数据不会全部丢失。
redis做为缓存,数据的持久化是怎么做的呢?
Redis提供了两种数据持久化的方式 : 1.RDB 2. AOF
(如今有3种,在Redis4.0版本之后,RDB和AOF混合使用,诞生第三种)
一、RDB持久化:
RDB 全程就是Redis数据备份文件,也叫Redis数据快照。他的用处就是将内存中的数据记录到磁盘之中,当服务宕机,或者Redis实例故障重启之后,再从磁盘中读取快照文件,以用来恢复数据。
这是用到的两个命令行 1-主进程来执行RDB,但是会阻塞所有命令。2-开启子进程来执行RDB,避免主进程受到影响。建议使用bgsave。也叫主动备份。
同时Redis内部也有出发RDB的机制,可以在Redis.conf文件中找到。
900秒内有1个数据被修改 - 触发RDB
300秒内有10个数据被修改 - 触发RDB
60秒内有10000个数据被修改 - 触发RDB
以上都触发bgsave。
执行原理:
当bgsave开始的时候,会fork主进程来得到一个子进程,子进程共享主进程的内存数据。完成fork之后读取内存数据并写入RDB文件之中。
##数据都是存储在物理内存之中的,而操作系统给我们的主进程中分配了一个虚拟内存。在主进程中还有一个表,叫做页表。页表是用来记录虚拟地址和物理地址的映射关系的,页表在主进程中,也就成为了主进程虚拟内存和物理内存沟通的桥梁。主进程可以通过页表来读取物理内存之中的数据。
但是当主进程fork了一个子进程之后,在子进程读取数据并写入RDB的时候,主进程是可以接收用户的请求,并且对内存数据进行修改。如果主进程同时修改数据,子进程同时读取数据,会产生脏数据。为了避免这种脏数据的发生,在fork底层来使用了一种copy-on-write的技术。 也就是说 当主进程执行读操作的时候,访问共享数据,此时共享数据为read-only。但是当主线程执行写操作的时候,则会拷贝一份数据来进行写操作。
二、AOF持久化:
AOF全程被称为追加文件,Redis处理的每一个写命令都会被记录在AOF文件之中,可以看作是命令日志文件。
这边的命令中我们输入了set num 123这段命令。而同时,当redis接受这段命令的时候,会同时的将这段命令分别输入到AOF日志文件之中。
AOF是默认关闭的,需要修改redis.conf文件来开启AOF
AOF的命令记录频率也可以在文件中进行修改
这也分为三种记录的频率,也叫做刷盘策略。
1.Always 被称为 同步刷盘 优点: 可靠性高,几乎不丢数据 缺点: 性能影响大
2.everysec 被称为 每秒刷盘 优点: 性能适中 缺点: 最多丢失一秒的数据
3.no 被称为操作系统控制 优点: 性能最好 缺点: 可靠性较差,可能丢失大量数据
在上面三种策略中,我们一般使用第二种 everysec来进行记录。
因为AOF是记录命令,所以AOF文件会比RDB文件大很多,而且AOF会记录同一个key的多次写操作,但是只有最后一次写操作才有意义,这时候就可以通过bgrewriteaof命令,来让AOF文件执行重写功能,用最少的命令达到最好的效果。
重写前:
重写后:
当然在Redis中也可以通过配置文件的修改来进行一个阈值的配置,让阈值超过多少之后AOF自动触发重写功能。
以上就是RDB持久化和AOF持久化的介绍,以下我们来对他做一个对比。
以上可见,AOF和RDB都有自己的优点和缺点,所以在实际项目开发中,往往会结合两者来一起使用。
标签:AOF,缓存,redis,Redis,内存,RDB,进程,数据 From: https://blog.csdn.net/sjwsjw021221/article/details/139888328