@@ -28,7 +28,7 @@ redis 如果仅仅只是将数据缓存在内存里面,如果 redis 宕机了
2828如果同时使用 RDB 和 AOF 两种持久化机制,那么在 redis 重启的时候,会使用 ** AOF** 来重新构建数据,因为 AOF 中的** 数据更加完整** 。
2929
3030#### RDB 优缺点
31- - RDB会生成多个数据文件,每个数据文件都代表了某一个时刻中 redis 的数据,这种多个数据文件的方式,** 非常适合做冷备** ,可以将这种完整的数据文件发送到一些远程的安全存储上去,比如说 Amazon 的 S3 云服务上去,在国内可以是阿里云的 ODPS 分布式存储上,以预定好的备份策略来定期备份redis中的数据 。
31+ - RDB会生成多个数据文件,每个数据文件都代表了某一个时刻中 redis 的数据,这种多个数据文件的方式,** 非常适合做冷备** ,可以将这种完整的数据文件发送到一些远程的安全存储上去,比如说 Amazon 的 S3 云服务上去,在国内可以是阿里云的 ODPS 分布式存储上,以预定好的备份策略来定期备份 redis 中的数据 。
3232- RDB 对 redis 对外提供的读写服务,影响非常小,可以让 redis ** 保持高性能** ,因为 redis 主进程只需要 fork 一个子进程,让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
3333- 相对于 AOF 持久化机制来说,直接基于 RDB 数据文件来重启和恢复 redis 进程,更加快速。
3434
@@ -42,7 +42,7 @@ redis 如果仅仅只是将数据缓存在内存里面,如果 redis 宕机了
4242- AOF 日志文件的命令通过非常可读的方式进行记录,这个特性非常** 适合做灾难性的误删除的紧急恢复** 。比如某人不小心用 ` flushall ` 命令清空了所有数据,只要这个时候后台 ` rewrite ` 还没有发生,那么就可以立即拷贝 AOF 文件,将最后一条 ` flushall ` 命令给删了,然后再将该 ` AOF ` 文件放回去,就可以通过恢复机制,自动恢复所有数据。
4343- 对于同一份数据来说,AOF 日志文件通常比 RDB 数据快照文件更大。
4444- AOF 开启后,支持的写 QPS 会比 RDB 支持的写 QPS 低,因为 AOF 一般会配置成每秒 ` fsync ` 一次日志文件,当然,每秒一次 ` fsync ` ,性能也还是很高的。(如果实时写入,那么 QPS 会大降,redis 性能会大大降低)
45- - 以前 AOF 发生过 bug,就是通过 AOF 记录的日志,进行数据恢复的时候,没有恢复一模一样的数据出来。所以说,类似 AOF 这种较为复杂的基于命令日志/ merge/ 回放的方式,比基于 RDB 每次持久化一份完整的数据快照文件的方式,更加脆弱一些,容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug,因此每次 rewrite 并不是基于旧的指令日志进行 merge 的,而是** 基于当时内存中的数据进行指令的重新构建** ,这样健壮性会好很多。
45+ - 以前 AOF 发生过 bug,就是通过 AOF 记录的日志,进行数据恢复的时候,没有恢复一模一样的数据出来。所以说,类似 AOF 这种较为复杂的基于命令日志 / merge / 回放的方式,比基于 RDB 每次持久化一份完整的数据快照文件的方式,更加脆弱一些,容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致的 bug,因此每次 rewrite 并不是基于旧的指令日志进行 merge 的,而是** 基于当时内存中的数据进行指令的重新构建** ,这样健壮性会好很多。
4646
4747### RDB和AOF到底该如何选择
4848- 不要仅仅使用 RDB,因为那样会导致你丢失很多数据;
0 commit comments