本篇文章主要内容为Redis持久化的两种方式进行讲解和操作示例。
目录
Redis 持久化
Redis是内存数据库，它将自己的数据库状态储存在内存中，如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失。
RDB持久化
为了解决这个问题，redis提供了RDB持久化功能，这个功能可以将Redis在内存中的数据库状态保存在磁盘里面，避免数据意外丢失。
Redis持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。
RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态。
RDB持久化命令
有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE。
SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。如下图：
和SAVE命令直接阻塞服务器进程的做法不同，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求。如下图：
新生成的RDB文件，如下图：
载入RDB文件
RDB文件的载入工作是在服务器启动时自动执行的，
所以Redis没有专门用于载入RDB文件的命令；
只要Redis服务器在启动时检测到RDB文件存在，就会自动载入RDB文件。
如下图：
因为AOF文件的更新频率通常比RDB文件更新频率高，所以AOF开启时，优先使用AOF文件恢复服务器数据库状态。
自动间隔性保存
因为BGSAVE命令可以不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。
通过save选项设置多个保存条件，只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。
示例：
save 900 1
save 300 10
save 60 10000
命令说明如下：
服务器在900秒之内，对数据库进行了至少1次修改。
服务器在300秒之内，对数据库进行了至少10次修改。
服务器在60秒之内，对数据库进行了至少10000次修改。
只要满足以上三个条件中的任意一个，BGSAVE命令就会被执行。
对过期键的处理
生成RDB文件
在执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查，已过期的键不会保存到新创建的RDB文件中。
载入RDB文件
在启动Redis服务器时，如果服务器开启了RDB功能，那么服务器对RDB文件进行载入时，对过期键的处理，分两种情况进行处理：
如果服务器是主服务器，在载入RDB文件时，程序会对文件中保存的键进行检查，未过期的键会被载入到服务器中，已过期的键则会被忽略。
如果服务器是从服务器，在载入RDB文件时，文件中保存的所有键都会被加载到数据库中。不过在主从数据库进行数据同步时，从服务器的数据库就会被清空。
AOF持久化
除了RDB持久化功能外，Redis还提供了AOF（Append Only File）持久化功能。与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态。
开启方式
Redis.conf中的配置appendonly改为yes
示例如下：
appendonly yes创建AOF文件
修改配置后，重启就会创建AOF文件，如下图：
AOF持久化实现
AOF持久化功能的实现可以分为命令追加、文件写入和文件同步三个步骤。
命令追加
当AOF持久化功能处于打开的状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。如下图：
AOF文件的写入和同步
Redis的服务器进程就是一个事件循环，这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行需要定时运行的函数。
因为服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到aof_buf缓冲区里面，所以在服务器每次结束一个事件循环之前，它都会考虑是否将aof_buf缓冲区的内容写入到AOF文件里面。
appendfsync值产生不同的持久化行为
| appendfsync选项的值 | flushAppendOnlyFile函数的行为 |
| always | 将aof_buf缓冲区中的所有内容写入并同步到AOF文件 |
| everysec | 将aof_buf缓冲区中的所有内容写入到AOF文件，如果上次同步时间距离现在超过1秒钟，那么再次进行AOF文件同步，由一个线程专门负责 |
| no | 将aof_buf缓冲区中的所有内容写入到AOF文件，但并不对AOF文件进行同步，何时同步由操作系统来决定 |
AOF文件载入和数据还原
因为AOF文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读取并重新执行一遍AOF文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。
还原数据库状态详细步骤
1.创建一个不带网络连接的伪客户端连接Redis。
2.从AOF文件中分析并读取一条写命令
3.使用伪客户端执行被读出的写命令
4.一直执行步骤2和步骤3，直到AOF文件中的所有写命令都被处理完毕为止
当完成以上步骤之后，AOF文件所保存的数据库状态就会被完整的还原出来。
AOF重写
因为AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以服务器运行时间，AOF文件中内容会越来越多，文件体积也会越来越大；可能会对服务器造成影响，并且使用AOF文件来进行数据还原所需的时间就越多。
为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写（rewrite）功能。通过该功能，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件保存的数据库状态相同，只是新的AOF文件中不保存冗余的写命令，所以新的AOF文件的体积会比原来小得多。
原理如下图：
AOF重写命令
通过BGWRITEAOF命令实现。如下图：
AOF重写不包含中间的冗余命令，只包含最后列表值的命令，如下图：
对过期键的处理
AOF文件写入
当过期键被惰性删除或者定期删除之后，程序会向AOF文件追加一条DEL命令，来显式地记录该键已被删除。
AOF重写
在执行AOF重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的AOF文件中。
总结
本篇文章主要内容为Redis持久化的两种方式进行讲解和操作示例。
扫一扫
761
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
