本文共 1145 字,大约阅读时间需要 3 分钟。
redis所有数据保存到内存中,对数据的更新将会异步的持久化到硬盘上面
因为内存数据库的原因,数据容易丢失,所以,持久化是必须的。redis 持久化两种
rdb文件保存二进制
触发机制 --主要 3种方式直接在命令行执行 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
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秒数据
比如 两次 incr num —> 优化为 set num 2
set hello 1 ; set hello 2 —> 优化为 set hello 2 这种可以做到加快恢复速度 还有减少磁盘的占用量转载地址:http://yquzi.baihongyu.com/