目录

前言

一.RDB

1.1手动执行

1.2自动执行

二.AOF 

2.1重写机制

三.混合持久化

Redis的学习专栏：http://t.csdnimg.cn/a8cvV

前言

        持久化，在之前，我们接触这个词汇是在mysql数据库当中的事务四大特性里。

持久性：指一旦事务提交，其结果就应该是永久性的，即使系统发生故障，已经提交的事务对数据库的修改也不应该丢失。数据库系统通常通过将事务的操作持久化到非易失性存储设备（如硬盘）来保证持久性。

但是持久性和持久化也是一样的。但是有没有思考过，Redis是一个 内存 数据库，效率巨快，但数据存储在内存当中，如何持久呢？ 

为了将数据持久化，Redis还在硬盘当中存储数据，硬盘数据和内存数据在理论上是一致的！

Redis实现持久化的两种方式：

1. RDB: 定期备份，替换。
2. 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文件不断增长导致文件变得很大，可能会导致以下几个问题：

1. 磁盘空间消耗过快：

   • AOF文件的增大会占用更多的磁盘空间，如果不及时处理，可能会导致磁盘空间不足的问题，影响服务器的正常运行。

2. 写入性能下降：

   • 随着AOF文件的增大，写入操作需要不断追加到文件末尾，这可能会导致写入性能逐渐下降。特别是在文件变得非常大时，每次写入需要扫描更多的数据，导致延迟增加。

3. AOF重写延迟：

   • 如果AOF文件过大，进行AOF重写操作可能会消耗大量时间和系统资源，可能导致重写操作的延迟，这会影响到服务器的性能和可用性。

4. 文件读取效率下降：

   • AOF文件过大时，Redis在启动时需要读取整个AOF文件并重新执行其中的命令，以恢复数据到内存中。文件越大，读取和恢复的时间也会变长，导致启动时间延长。

5. 备份和恢复困难：

   • 大型AOF文件可能增加了备份和恢复的复杂性和时间消耗。特别是在进行故障恢复或迁移Redis实例时，处理大型AOF文件会更加耗时和复杂。

解决以上方法，redis有重写机制

2.1重写机制

        重写机制分手动触发和自动触发

手动触发：调用bgrewriteaof命令

解析：Redis在后台开始执行AOF重写操作。创建子进程，子进程会生成一个新的AOF文件，其中包含重建数据集所需的最小命令集合，父进程会仍然不断接收客户端的数据，并且写入旧的aof文件里，直到这次请求的数据结束，通过信号 通知父进程，然后新的请求数据会放入aof_rewrite_buf缓冲区当中，然后写入新的aof文件里。

三.混合持久化

        顾名思义，混合持久化就是将AOF和ROB一起使用，不过通过一些特殊使用方式，AOF是首先的存在！

配置方法如下：

1. 编辑Redis配置文件：

   • 找到并编辑Redis的配置文件（通常是redis.conf）。

2. 启用 AOF 持久化：

   • 设置 appendonly yes，这样Redis会启用AOF持久化功能。

3. 配置 RDB 持久化：

   • 配置Redis定期将内存快照保存到磁盘的策略。可以通过设置 save 选项来定义触发RDB快照保存的条件

4. 保存配置文件并关闭Redis配置文件。

---

写入数据具体流程：  

1. 写入操作：

   • 当Redis接收到写入操作（例如SET、HSET等）时，首先将该操作追加到AOF缓冲区中，同时更新内存中的数据。

2. AOF持久化：

   • 根据AOF配置的条件（例如根据数据量或时间间隔），AOF缓冲区中的内容将定期或达到一定大小时，被写入到AOF文件中。

3. RDB快照：

   • 根据RDB配置的条件，Redis会定期（或在手动触发时）将当前内存中的数据生成一个RDB快照，并保存到磁盘上。

4. 故障恢复：

   • 当Redis因某种故障（例如服务器崩溃或断电）而重启时，根据启用的持久化方式进行恢复：
     • 如果使用AOF，Redis会通过重新执行AOF文件中的命令来恢复数据状态。
     • 如果使用RDB，Redis会加载最近保存的RDB快照来快速恢复数据。

5. 数据一致性保证：

   • 使用AOF和RDB的组合，可以在数据恢复时结合AOF的完整性和RDB的快速性，从而提供更可靠的数据保护和恢复机制。

疑问：

如果bgrewriteaof命令和bgsave()先后抵达Redis的服务器呢？

处理顺序：Redis的事件处理器会根据命令到达的顺序，将它们添加到处理队列中，然后依次处理。

同时抵达：Redis 的 bgsave() 和 bgrewriteaof 命令都会创建子进程来执行，而这些子进程的执行是并行执行。

额外学习--信号

        信号是linux的一种用于进程间通信的机制，用来通知进程发生了特定事件。例如上述的父子进程！！！