目录
前言
一.RDB
1.1手动执行
1.2自动执行
二.AOF
2.1重写机制
三.混合持久化
Redis的学习专栏:http://t.csdnimg.cn/a8cvV
前言
持久化,在之前,我们接触这个词汇是在mysql数据库当中的事务四大特性里。
持久性:指一旦事务提交,其结果就应该是永久性的,即使系统发生故障,已经提交的事务对数据库的修改也不应该丢失。数据库系统通常通过将事务的操作持久化到非易失性存储设备(如硬盘)来保证持久性。
但是持久性和持久化也是一样的。但是有没有思考过,Redis是一个 内存 数据库,效率巨快,但数据存储在内存当中,如何持久呢?
为了将数据持久化,Redis还在硬盘当中存储数据,硬盘数据和内存数据在理论上是一致的!
Redis实现持久化的两种方式:
- RDB: 定期备份,替换。
- AOF: 实时备份,追加模式。
一.RDB
Redis服务器的数据定期将快照的形式保存到磁盘上。RDB是Redis的一种备份机制,主要用于数据持久化和恢复。后续Redis如果重启,可以根据快照,将数据恢复!
RDB的执行方式:
1.1手动执行
通过Redis客户端,执行特定的命令,触发快照生成。
- save(),执行该方法,redis会开始阻塞redis的其他客户端的命令,全力以赴的进行快照生成操作dump.rdb文件生成数据,往!不建议该方法
- bgsave(),不会影响redis处理其他客户端请求,默默执行!
解析:服务器发出BGSAVE()命令,然后如果已经有此命令执行,则会返回,若无,将父进程中 fork出一个子进程来执行快照的生成工作,该子进程会复制父进程的所有内存段,包括代码段、数据段和堆栈段,然后拥有一个新的进程ID。
复制技术:写时复制(copy-on-write)技术,也就是指:子进程会和父进程共享进程的数据,直到需要修改时,才进行 物理内存 的复制!
父子进程的返回值:在fork()
函数调用返回后,父进程和子进程会分别从fork()
函数返回,父进程得到子进程的进程ID,而子进程得到0作为返回值。
快照(RDB文件):生成的文件存储在redis的工作目录下,redis配置文件中有生成的约定。dump.rdb文件。每次生成新的RDB文件就会替换旧的文件,可借助stat命令观察
RDB文件当中的数据压缩后以二进制格式存储的,这使得它在保存和加载时非常高效,尤其是在处理大型Redis数据库时。
1.2自动执行
在Redis的配置文件当中,本就设置,Redis重启自动、每间隔多久时间修改!redis配置文件中有生成的约定。dump.rdb文件。每次生成新的RDB文件就会替换旧的文件
注:重启是正常重启,而不是杀进程!
二.AOF
AOF(Append-Only File),即Redis中的追加写文件。它是Redis用于持久化数据的一种方式。由于默认是关闭的,所以在Redis.conf 配置文件需要进行修改开启,并且开启之后,RDB文件就失效了,启动不会再读取RDB文件了。
如上图,手动开启将No改为Yes。将文件存储在appendonly.aof当中。
疑问:这种情况,边将数据写入内存边写入硬盘当中,这种情况会不会影响处理数据的速度呢?
答:不会,AOF机制,并不是直接将数据写入硬盘,而是先写入一个内存的缓冲区,积累之后,再统一写入硬盘当中;并且硬盘读写数据,是顺序读写速度比较快!
问:假设在缓冲区当中,突然进程挂了,数据还在吗?
答:不在了,会丢失!
缓冲区的刷新策略:
刷新频率高,性能影响越大,可靠性越高;与之相反;默认:everysec
AOF文件不断增长导致文件变得很大,可能会导致以下几个问题:
-
磁盘空间消耗过快:
- AOF文件的增大会占用更多的磁盘空间,如果不及时处理,可能会导致磁盘空间不足的问题,影响服务器的正常运行。
-
写入性能下降:
- 随着AOF文件的增大,写入操作需要不断追加到文件末尾,这可能会导致写入性能逐渐下降。特别是在文件变得非常大时,每次写入需要扫描更多的数据,导致延迟增加。
-
AOF重写延迟:
- 如果AOF文件过大,进行AOF重写操作可能会消耗大量时间和系统资源,可能导致重写操作的延迟,这会影响到服务器的性能和可用性。
-
文件读取效率下降:
- AOF文件过大时,Redis在启动时需要读取整个AOF文件并重新执行其中的命令,以恢复数据到内存中。文件越大,读取和恢复的时间也会变长,导致启动时间延长。
-
备份和恢复困难:
- 大型AOF文件可能增加了备份和恢复的复杂性和时间消耗。特别是在进行故障恢复或迁移Redis实例时,处理大型AOF文件会更加耗时和复杂。
解决以上方法,redis有重写机制
2.1重写机制
重写机制分手动触发和自动触发
手动触发:调用bgrewriteaof命令
解析:Redis在后台开始执行AOF重写操作。创建子进程,子进程会生成一个新的AOF文件,其中包含重建数据集所需的最小命令集合,父进程会仍然不断接收客户端的数据,并且写入旧的aof文件里,直到这次请求的数据结束,通过信号 通知父进程,然后新的请求数据会放入aof_rewrite_buf缓冲区当中,然后写入新的aof文件里。
三.混合持久化
顾名思义,混合持久化就是将AOF和ROB一起使用,不过通过一些特殊使用方式,AOF是首先的存在!
配置方法如下:
-
编辑Redis配置文件:
- 找到并编辑Redis的配置文件(通常是redis.conf)。
-
启用 AOF 持久化:
- 设置
appendonly yes
,这样Redis会启用AOF持久化功能。
- 设置
-
配置 RDB 持久化:
-
配置Redis定期将内存快照保存到磁盘的策略。可以通过设置
save
选项来定义触发RDB快照保存的条件
-
-
保存配置文件并关闭Redis配置文件。
写入数据具体流程:
-
写入操作:
- 当Redis接收到写入操作(例如SET、HSET等)时,首先将该操作追加到AOF缓冲区中,同时更新内存中的数据。
-
AOF持久化:
- 根据AOF配置的条件(例如根据数据量或时间间隔),AOF缓冲区中的内容将定期或达到一定大小时,被写入到AOF文件中。
-
RDB快照:
- 根据RDB配置的条件,Redis会定期(或在手动触发时)将当前内存中的数据生成一个RDB快照,并保存到磁盘上。
-
故障恢复:
- 当Redis因某种故障(例如服务器崩溃或断电)而重启时,根据启用的持久化方式进行恢复:
- 如果使用AOF,Redis会通过重新执行AOF文件中的命令来恢复数据状态。
- 如果使用RDB,Redis会加载最近保存的RDB快照来快速恢复数据。
- 当Redis因某种故障(例如服务器崩溃或断电)而重启时,根据启用的持久化方式进行恢复:
-
数据一致性保证:
- 使用AOF和RDB的组合,可以在数据恢复时结合AOF的完整性和RDB的快速性,从而提供更可靠的数据保护和恢复机制。
疑问:
如果bgrewriteaof命令和bgsave()先后抵达Redis的服务器呢?
处理顺序:Redis的事件处理器会根据命令到达的顺序,将它们添加到处理队列中,然后依次处理。
同时抵达:Redis 的
bgsave()
和bgrewriteaof
命令都会创建子进程来执行,而这些子进程的执行是并行执行。
额外学习--信号
信号是linux的一种用于进程间通信的机制,用来通知进程发生了特定事件。例如上述的父子进程!!!