怎么用织梦来做网站后台,qq刷赞网站怎么做,上海人才招聘网,wordpress 作者栏一、RDB
RDB 持久化机制#xff0c;对 Redis 中的数据执行周期性的持久化
二、AOF
AOF 机制对每条写入命令最为日志#xff0c;以 append-only 的模式写入一个日志文件中#xff0c;在 Redis 重启的时候#xff0c;可以通过回放 AOF 日志中的写入指令#xff0c;来重新…一、RDB
RDB 持久化机制对 Redis 中的数据执行周期性的持久化
二、AOF
AOF 机制对每条写入命令最为日志以 append-only 的模式写入一个日志文件中在 Redis 重启的时候可以通过回放 AOF 日志中的写入指令来重新构建整个数据集
分析
如果我们想要 Redis 仅仅作为纯内存的缓存使用那么可以禁止 RDB 和 AOF 所有的持久化机制通过 RDB 或 AOF都可以将 Redis 内存中的数据给持久化到磁盘上来然后可以将这些数据备份到别的地方去比如说云服务如果 Redis挂了服务器上的内存和磁盘上的数据都丢了可以从云服务上拷贝回来之前的数据放到指定的目录中然后重新启动 RedisRedis就会自动根据持久化数据文件中的数据去回复内存中的数据继续对外提供服务如果同时使用 RDB 和 AOF 两种持久化机制那么在 Redis 重启的时候会使用 AOF 来重新构建数据因为 AOF 中的数据更加完整
RDB 持久化机制的优点
RDB 会生成多个数据文件每个数据文件都代表了某一时刻中 Redis 的数据这种多个数据文件的方式非常适合做冷备可以将这种完整的数据文件发送到一些远程的安全存储上去比如 Amazon 的s3 云服务上去在国内可以使阿里云的ODPS 分布式存储上以预定号的备份策略来定期备份 Redis中的数据RDB 对 Redis 对外提供的读写服务影响非常小可以让 Redis 保持高性能因为 Redis 主进程只需要 fork 一个子进程让子进程执行磁盘 IO 操作来进行 RDB 持久化即可相对于 AOF 持久化机制来说直接基于RDB 数据文件来重启和恢复 Redis 进程更加快速
RDB 持久化机制的缺点
如果想要在 Redis 故障时尽可能少的丢失数据那么RDB没有 AOF 好一般来说 RDB数据快照文件都是每隔 5 分钟或者更长时间生成一次这个时候就得接受一点 Redis 进程宕机那么会就是最近 5 分钟的数据RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候如果数据文件特别大可能会导致对客户端提供的服务暂停数毫秒甚至数秒
AOF 持久化机制的优点
AOF 可以更好的保护数据不丢失一般 AOF会每隔1秒通过一个后台线程执行一次 fsync 操作最多丢失 1s 的数据AOF 日志文件以 append-only 模式写入所以没有任何磁盘寻址的开销写入性能非常高而且文件不容易破损即使文件尾部破损也很容易修复AOF 日志文件即使过大的时候出现后台重写操作也不会影响客户端的读写因为在 rewrite log 的时候会对其中的指导进行压缩创建出一份需要回复数据的最小日志出来。创建新日志文件的时候 老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候再交换新老日志文件即可。AOF 日志文件的命令通过非常刻度的方式进行记录这个特性非常适合做灾难性的误删除的紧急恢复。
AOF 持久化机制的缺点
对于同一根数据来说AOF 日志文件通常比 RDB 数据快照文件更大AOF 开启后支持的写 QPS 回避 RDB 支持的写QPS 低因为 AOF 一般会配置成每秒一次 fsync 性能也是非常高的以前 AOF 发生过 bug就是通过 AOF记录的日子进行数据恢复的时候没有恢复成一模一样的数据出来所以说类似 AOF这类比较复杂的基于命令日志/merge/回放的方式比基于 RDB 每次持久化一根万传给你的数据快照文件的方式更加脆弱一些容易有bug。不过 AOF 为了避免 rewrite 郭传给你导致的 bug 因此每次 rewrite 并不是基于就的指令日志进行 merge 的而是基于当时内存中的数据进行指令的重新构建这样健壮性会好很多。
RDB 和 AOF 到底该如何选择
不要仅仅使用 RDB那样会导致你丢失很多数据也不要仅仅使用 AOF 因为那样有两个问题 通过 AOF 做冷备没有 RDB 做冷备来得恢复速度更快RDB 每次简单粗暴生成数据快照更加健壮可以避免 AOF 这种复杂的备份和恢复机制的bug 综合使用 AOF 和RDB 两种持久化机制 用 AOF 保证数据不丢失作为数据恢复的第一选择用 RDB 来做不同程度的冷备在 AOF 文件都丢失或损坏不可用的时候还可以使用 RDB 来进行快速的数据恢复 此系列博客为学习笔记若有侵权请联系我删除
