2018-1-17 by Atlasredis
将redis在内存中的数据库状态保持到磁盘里面,避免数据意外丢失。数据库
- 既能够手动执行,也能够根据服务器配置选项按期执行。
- 生成的RDB文件是一个通过压缩的二进制文件,经过该文件能够还原生成RDB文件时的数据库状态。
- RDB文件载入时,服务器一直处于阻塞状态,直到完成。
命令SAVE、BGSAVE
SAVE命令会阻塞redis服务器进程,直到RDB文件建立完毕为止,在服务器进程阻塞期间,服务器不能处理任何命令请求。
BGSAVE命令会派生出一个子进程,而后由子进程负责建立RDB文件,服务器进程(父进程)继续处理命令请求。数组- AOF文件更新频率一般比RDB文件更新频率高。
so -->
若是开启AOF,服务器优先使用AOF文件还原数据库;
只有AOF关闭,服务器才会使用RDB文件还原数据库。
BGSAVE命令执行时的服务器状态:
(1)BGSAVE执行期间,客户端发送的SAVE命令会被服务器拒绝。
(2)BGSAVE执行期间,客户端发送的BGSAVE命令会被服务器拒绝。
(3)BGSAVE和BGREWRITEAOF不能同时执行:
若是BGSAVE正在执行,那么客户端发送的BGREWRITEAOF会被延迟到BGSAVE后执行;
若是BGREWRITEAOF正在执行,那么客户端发送的BGSAVE会被服务器拒绝。缓存- SAVE保存条件
save 900 1 服务器在900秒以内,对数据库进行了至少1次修改 save 300 10 服务器在300秒以内,对数据库进行了至少10次修改 save 60 10000 服务器在60秒以内,对数据库进行了至少10000次修改
struct redisServer { // ... // 记录保存条件的数组 struct saveparam *saveparams; // 修改计数器 long long dirty; // 上次执行保存的时间 time_t lastsave; // ... } struct saveparam { // 秒数 time_t seconds; // 修改数 int changes; }
ServerCron 函数检查保存条件的过程安全
RDB文件结构将和JAVA CLASS文件一同讨论。服务器
- AOF持久化是经过保存redis服务器所执行的 写命令 来记录数据库状态的。
AOF文件内容是纯文本格式。
e.g.
redis> SET msg "hello"
ok
AOF文件内容(SELECT命令是服务器自动添加的):
2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n
3\r\n$3\r\n$3\r\nSET\r\n$3\r\nmsg\r\n$5\r\nhello\r\napp- AOF持久化实现步骤:
命令追加 --> 文件写入 --> 文件同步- 命令追加是将执行的写命令追加到服务器状态的aof_buf缓存区的末尾:
struct redisServer { // ... // AOF缓冲区 sds aof_buf; // ... }
- 文件的写入与同步
flushAppendOnlyFile()函数考虑是否要将aof_buf中的内容写入和保存到AOF文件里面,行为由服务器配置的appendfsync选项的值来决定。- appendfsync配置:
always:AOF持久化效率最慢,安全性来讲最安全,故障只会丢失一个命令数据。
everysec:AOF持久化效率足够快,安全性来讲,故障只会丢失一秒钟的命令数据。
no:AOF持久化效率最快,安全性来讲,故障会丢失上次同步AOF文件以后的全部写命令数据。ide
- AOF 文件载入过程
- AOF文件重写,解决AOF文件体积膨胀问题。
- AOF文件重写原理:
AOF文件重写并不须要对现有的AOF文件进行读取、分析或者写入操做,而是经过读服务器当前的数据库状态来实现的。
AOF文件重写首先从数据库中读取键如今的值,而后用一条命令记录键值对,代替以前记录这个键的多条命令。
若是元素数量超过redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值,那么重写多条命令记录键的值。- AOF文件后台重写过程(BGREWRITEAOF原理)
参考文献:《redis设计与实现》函数