标签:proc 一个 不能 重写原理 ext images write 添加 file
2018-1-17 by Atlas将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\n- AOF持久化实现步骤:
命令追加 --> 文件写入 --> 文件同步- 命令追加是将执行的写命令追加到服务器状态的aof_buf缓存区的末尾:
struct redisServer {
// ...
// AOF缓冲区
sds aof_buf;
// ...
}
- 文件的写入与同步
flushAppendOnlyFile()函数考虑是否要将aof_buf中的内容写入和保存到AOF文件里面,行为由服务器配置的appendfsync选项的值来决定。- appendfsync配置:
always:AOF持久化效率最慢,安全性来说最安全,故障只会丢失一个命令数据。
everysec:AOF持久化效率足够快,安全性来说,故障只会丢失一秒钟的命令数据。
no:AOF持久化效率最快,安全性来说,故障会丢失上次同步AOF文件之后的所有写命令数据。
- AOF 文件载入过程
- AOF文件重写,解决AOF文件体积膨胀问题。
- AOF文件重写原理:
AOF文件重写并不需要对现有的AOF文件进行读取、分析或者写入操作,而是通过读服务器当前的数据库状态来实现的。
AOF文件重写首先从数据库中读取键现在的值,然后用一条命令记录键值对,代替之前记录这个键的多条命令。
如果元素数量超过redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值,那么重写多条命令记录键的值。- AOF文件后台重写过程(BGREWRITEAOF原理)
参考文献:《redis设计与实现》
标签:proc 一个 不能 重写原理 ext images write 添加 file
原文地址:http://blog.51cto.com/damon188/2062259