oZaoHua 2019-06-28
| 方式 | 类似 |
|---|---|
| RDB | 快照 |
| AOF | 写日志,把新的记录添加到末尾 |
其实RDB的原理就是类似于创建快照。
savesave命令是同步的,对于特别大的数据和访问量大的网站都会发生阻塞
bgsavebgsave命令是异步的,所以不会造成命令阻塞,但是因为该命令会额外的创建一个进程的子进程,所以会产生一定量的开销
save 900 1save 300 10save 60 10000
例如:在900秒内有一次改变就发生save命令
建议的配置
dbfilename#二进制文件(快照)的名字dir#二进制文件存放的位置stop-write-on-bgsave-error#bgsave失败,是否停止写入rdbcompression#是否使用压缩格式rdbchecksum#对二进制文件进行校验
文件策略:存在老的RDB文件,新的就会替换老的
缺点:耗时,耗性能,不可控,丢失数据
类似于我们写日志,把操作的每一条命令行都记录到日志文件中
| 命令 | always | everysec | no |
|---|---|---|---|
| 优点 | 不丢失数据 | 每一秒执行一个同步 | 不用管 |
| 缺点 | IO开销大 | 有可能丢失一秒的数据 | 不可控 |
因为在我们实际的使用中,有很多的命令是重复的,多余的或者是过期的,例如set hello word, set hello Peter,实际上只有后句命令才有效,而重写就是只记录了后面的那一句话。
类似于RDB中的bgsave命令
其实也是在内部调用bgrewriteof
| 配置名 | 含义 |
|---|---|
| auto_aof_rewrite_min_size | AOF文件重写需要的尺寸 |
| auto_aof_rewrite_percentage | AOF文件增长率 |
AOF的统计
| 统计名 | 含义 |
|---|---|
| aof_current_size | AOF当前的尺寸(单位:字节) |
| aof_base_size | AOF上次启动和重写的尺寸(单位:字节) |
通过配置启动重写的条件

注意:3-1:当AOF文件重写的过程中,新的数据也会写入到日常的AOF文件中。5-2则是在AOF文件重写的时间段期间有新的命令传进来也会被重写进当前正在重写的AOF文件中。(语文水平有限,哈哈,希望能理解)
appendonly yes#使用AOF一定要开启配置appendfilename "appendonly-${port}.aof"#AOF文件的名称appendfsync everysec#AOF文件的策略dir /#存放的地址no_appendfsync_on_rewrite yes#这个配置就是说明在AOF重写的过程中不进行日常的AOF文件写入auto_aof_rewrite_percentage 100auto_aof_rewrite_min_size 64mb
| 命令 | RDB | AOF |
|---|---|---|
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 丢数据 | 根据策略决定 |
| 轻重 | 重 | 轻 |