RDB:
Redis DataBase 将某⼀个时刻的内存快照(Snapshot),以⼆进制的⽅式写⼊磁盘
。
手动触发:
-
save 命令,使 Redis 处于阻塞状态,直到 RDB 持久化完成,才会响应其他客户端发来的命令,所以在⽣产环境⼀定要慎⽤
-
bgsave 命令,fork出⼀个⼦进程执⾏持久化,主进程只在fork过程中有短暂的阻塞,⼦进程创建之后,主进程就可以响应客户端请求了
自动触发:
-
save m n :在 m 秒内,如果有 n 个键发⽣改变,则⾃动触发持久化,通过bgsave执⾏,如果设置多个、只要满⾜其⼀就会触发,配置⽂件有默认配置(可以注释掉)
-
flushall :⽤于 清空redis所有的数据库 ,flushdb清空当前redis所在库数据(默认是 0 号数据库),会清空RDB⽂件,同时也会⽣成 dump.rdb 、内容为空
-
主从同步 :全量同步时会⾃动触发bgsave命令,⽣成rdb发送给从节点
优点:
- 整个Redis数据库将只包含⼀个⽂件 dump.rdb,⽅便持久化。
-
容灾性好,⽅便备份。
-
性能最⼤化,fork ⼦进程来完成写操作,让主进程继续处理命令,所以是 IO 最⼤化。使⽤单独⼦进程来进⾏持久化,主进程不会进⾏任何 IO 操作,保证了 redis 的⾼性能
-
相对于数据集⼤时,⽐ AOF的启动效率更⾼。
缺点:
-
数据安全性低 。RDB 是间隔⼀段时间进⾏持久化,如果持久化之间 redis 发⽣故障,会发⽣数据丢失。所以这种⽅式更适合数据要求不严谨的时候)
-
由于RDB是通过fork⼦进程来协助完成数据持久化⼯作的,因此,如果当数据集较⼤时,可能会导致整个服务器停⽌服务⼏百毫秒,甚⾄是1 秒钟。会占⽤cpu
AOF:
Append Only File
以⽇志的形式记录服务器所处理的每⼀个写、删除操作,查询操作不会记录,
以⽂本的⽅式记录,可以打开⽂件看到详细的操作记录,调操作系统命令进程刷盘
- 所有的写命令会追加到 AOF 缓冲中。
-
AOF 缓冲区根据对应的策略向硬盘进⾏同步操作。
-
随着 AOF ⽂件越来越⼤,需要定期对 AOF ⽂件进⾏重写,达到压缩的⽬的。
-
当 Redis 重启时,可以加载 AOF ⽂件进⾏数据恢复 。
同步策略:
- 每秒同步:异步完成,效率⾮常⾼,⼀旦系统出现宕机现象,那么这⼀秒钟之内修改的数据将会丢失
- 每修改同步:同步持久化,每次发⽣的数据变化都会被⽴即记录到磁盘中,最多丢⼀条
-
不同步 :由操作系统控制,可能丢失较多数据
优点:
-
数据安全
-
通过 append 模式写⽂件,即使中途服务器宕机也不会破坏已经存在的内容, 可以通过 redis-check-aof ⼯具解决数据⼀致性问题。
-
AOF 机制的 rewrite 模式 。定期对AOF⽂件进⾏重写,以达到压缩的⽬的
缺点:
- AOF ⽂件⽐ RDB ⽂件⼤,且恢复速度慢。
-
数据集⼤的时候,⽐ rdb 启动效率低。
-
运⾏效率没有RDB⾼
对比:
- AOF⽂件⽐RDB更新频率⾼,优先使⽤AOF还原数据。AOF⽐RDB更安全也更⼤
-
RDB性能⽐AOF好
-
如果两个都配了优先加载AOF
![](https://img-blog.csdnimg.cn/a9e55af271d1494f9f461beee434573b.jpeg)