RDB持久化
RDB文件的生成和载入
生成RDB文件的命令：SAVE和BGSAVE
SAVE命令阻塞Redis进程，BGSAVE使用子线程来进行持久化
RDB文件的载入是服务器在启动过程中检测到RDB，自动载入的，此处有个前提：AOF持久化功能处于关闭状态，否则优先使用AOF文件来还原数据
自动间歇性保存
//服务器在900秒之内，对数据库至少进行了一次修改
save 900 1
//服务器在300秒之内，对数据库至少进行了10次修改
save 300 10
//服务器在60秒之内，对数据库进行了至少10000次修改
save 60 10000
AOF持久化
AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库的状态的。
持久化过程：
命令追加-->文件写入-->文件同步
- 命令追加，服务器执行一个写命令之后，会以协议格式追加到aof_buf缓冲区的末尾；
- 文件写入，将命令写入aof文件，但是未将文件刷入磁盘；
- 文件同步，即刷盘
Redis通过appendfasync参数来控制持久化行为：
- always，将aof_buf缓冲区中所有内容写入并同步到AOF文件，该方式下Redis性能最差，但是安全性最高，数据丢失控制在一个文件事件之内；
- everysec，将aof_buf缓冲区所有内容写入aof文件，每一秒进行一次aof文件同步，该方式Redis在性能和安全性方面做了折中选择；
- no，将aof——buf缓冲区所有内容写入aof文件，同步的时间交给操作系统自己决定，该方式Redis性能最好，但是异常宕机可能丢失大量数据。
AOF文件记录服务器的写命令，随着服务器在线时间的推移，AOF文件中内容会越来越多，甚至可能撑爆磁盘，所以我们需要进行AOF重写，新的AOF文件和旧的AOF文件保存着相同的Redis状态，但是不存在数据冗余，并且新AOF文件的生成不涉及到对旧AOF文件的读写。
Redis是如何进行无阻塞的AOF文件重写？
当后台调用BGREWRITEAOF指令时，Redis会进行无阻塞的进行AOF文件的重写，Redis会开启一个子进程，使用子进程可以使父进程，即服务器进程能够继续对外提供服务，同时避免使用锁的情况下，保证数据的安全性。但是存在一个问题，在AOF重写期间，服务器进程继续处理命令请求，新的命令可能对数据库的状态进行了修改，使得服务器当前状态和重写后的服务器状态不一致，为了解决这个问题，Redis设置了一个AOF重写缓冲区，当Redis执行写命令时，会同时将命令追加到AOF缓冲区和AOF重写缓冲区，那么子进程在执行AOF重写期间服务器需要执行三个工作：
- 执行客户端发送的命令；
- 将执行的写命令追加到AOF缓冲区；
- 将执行的命令追加到AOF重写缓冲区；
当子进程完成重写之后，会向父进程发送一个信号，父进程调用信号处理函数，执行以下操作：
- 将AOF重写缓冲区中的所有内容写入到新的AOF文件中，这是新的AOF文件状态与当前服务器状态一致；
- 对新的AOF文件进行改名，原子性的覆盖现有的AOF文件，完成新旧AOF文件的替换。
注：信号处理函数处理过程中需要阻塞Redis。
网友评论