redis所有数据保存到内存中,对数据的更新将会异步的持久化到硬盘上面
因为内存数据库的原因,数据容易丢失,所以,持久化是必须的。
redis 持久化两种
- 保存二进制文件 比如 redis rdb文件
- 写日志: redis AOF 文件
关于 RDB
- 什么是RDB
- 触发机制
- 重点
rdb文件保存二进制
触发机制 --主要 3种方式
- save(同步)
- bgsave(异步)
- 自动
直接在命令行执行 save,会造成 redis 的阻塞。
如果有老的RDB文件,会替换掉它
如果是执行 的 bgsave
命令 | save | bgsave |
---|---|---|
IO类型 | 同步 | 异步 |
阻塞 | yes | yes(但是阻塞在fork) |
优点 | 不消耗额外内存 | 不阻塞客户端命令 |
缺点 | 阻塞客户端命令 | 需要fork, 消耗内存 |
当redis 的写操作非常频繁的时候,会不停的 copyOnWrite,
要执行 RDB的话,你需要敲 save 或者 bgsave的命令,当然,redis其实提供了自动 生成 rdb文件的策略
save | seconds | changes |
---|---|---|
save | 900 | 1 |
save | 300 | 10 |
save | 60 | 10000 |
如果redis 写操作太频繁的话,频繁 save操作,会对硬盘造成一定的压力
rdb文件 默认是 dump.rdb
触发RDB的条件
- 全量复制 (主从复制)
- debug reload ()
- shutdown
debug reload
save当前的rdb文件,并清空当前数据库,重新加载rdb,加载与启动时加载类似,加载过程中只能服务部分只读请求(比如info、ping等)
使用 info memory 可以查看redis 内存使用情况
一帮不会用 save的自动配置
RDB是有一些问题的,
比如 耗时、耗费性能
不可控,丢失数据
使用 bgsave,会 fork一个子进程,疯狂的 copy-on-write的策略,不适合大量的写操作情况
丢失数据的话:举个例子,保存了数据到 rdb文件,这个时候,又往redis 上写数据,还没有把新数据写入到 rdb文件里面,如果服务器挂了,就丢失了新数据了。
使用 AOF的话,会在日志里面不停追加命令,这种就不会丢失数据
3种策略
命令 | always | everysec | no |
---|---|---|---|
缺点 | IO开销大 | 丢失1秒的数据 | 不可控 |
优点 | 不丢数据 | 每秒一次 fsync 丢1秒数据 | 不知道 |
通常会使用 eversec 的使用 允许只丢失1秒数据
AOF重写
比如 两次 incr num —> 优化为 set num 2
set hello 1 ; set hello 2 —> 优化为 set hello 2
这种可以做到加快恢复速度 还有减少磁盘的占用量