(1)Redis 持久化的意义, 在于故障恢复
(2) 如果没有持久化的话, Redis 遇到灾难性故障的时候, 就会丢失所有的数据
(3) 如果通过持久化将数据备份一份在磁盘上, 然后定期, 比如说同步和备份到一些云储存服务上去, 那么就可以保证数据不丢失全部, 还是可以恢复一部分数据回来
2:Redis 的企业级的持久化方案是什么? 是用来跟那些企业级的场景结合起来使用
对于一个企业级的 Redis 架构来说, 持久化是不可减少的
企业级 Redis 集群架构: 海量数据, 高并发, 高可用
1,Redis 的持久化和高可用是否有关系呢?
持久化主要是做灾难恢复, 数据恢复, 也可以归纳高高可用的一个环节里面去
比如你的 Redis 挂了, 然后 Redis 就不可用了, 你要做的事情就是让 Redis 变得可用, 当然也不可用, 因为数据都没有了 0_0.
很有可能说, 大量数据请求过来, 缓存全部无法命中, 在 Redis 里根本找不到数据, 这时候就会造成雪崩问题, 所有请求, 没有在 Redis 命中, 就会去 MySQL 数据库中去查询, 当 MySQL 承接高并发, 然后就挂掉了, Redis 都没法去找数据进行恢复
这时候 Redis 的数据应用从哪里来?
如果把 Redis 的持久化做好, 备份和恢复方案做到企业级的程度, 那么即使 Redis 故障了, 也可以通过备份数据, 快速恢复, 一旦恢复立即对外使用
所以说, Redis 的持久化跟高可用是有关系的
3:Redis 持久化: RDB,AOF
1,RDB 和 AOF
(1)RDB 持久机制, 对 Redis 中的数据执行周期性的持久化
(2)AOF 机制对每条写入命令作为日志, 以 append-only 的模式写入一个日志文件中, 在 Redis 重启的时候, 可以用过回放 AOF 日志中的写入指令来重新构建整个数据集
(3) 如果我们想要 Redis 仅仅作为纯缓存来用, 那么可以禁止 RDB 和 AOF 所有的持久机制
通过 RDB 或 AOF, 都可以讲 Redis 内存中的数据给持久化到磁盘上面来, 然后可以将这些数据备份到云存储服务上去
如果 Redis 挂了, 服务器上的内存和磁盘上的数据都丢了, 可以从云服务上拷贝回来, 放到指定的目录中, 然后重新 Redis,Redis 就会自动根据持久化数据文件中的数据, 去回复内存中的数据
(4) 如果同时使用 RDB 和 AOF 两种持久化机制, 那么在 Redis 重启的时候, 会使用 AOF 来重新构建数据, 因为 AOF 中的数据更加完整
2,RDB 持久化机制的有点
(1)RDB 会生成多个数据文件, 每个数据文件都代表了某一个时刻中 Redis 的数据, 这种多个数据文件的方式, 非常适合冷备份, 可以将这种完整的数据文件存储到云服务器上
(2)RDB 对 Redis 对外提供的读写服务, 影响非常的小, 可以让 Redis 保持高性能, 因为 Redis 主进程只需要 fork 一个子进程, 让子进程执行磁盘 IO 操作来就进行 RDB 持久化即可
(3) 相对于 AOF 持久化机制来说, 直接基于 RDB 数据文件来重启和恢复 Redis 进行, 更加快速
3:RDB 持久化机制的缺点
(1) 如果想要在 Redis 故障时, 尽可能少的丢失数据, 那么 RDB 没有 AOF 好. 一般来说, RDB 数据快照文件, 都是每隔 5 分钟, 或者更长时间生成一次, 这个时候就得接受一旦 Redis 宕机, 那么会丢失最近 5 分钟的数据
(2)RDB 每次在 fork 子进程执行 RDB 快照文件生成的时候, 如果数据文件特别大, 可以会导致客户端提供的服务暂定数毫秒, 或者甚至数秒
4:AOF 持久化机制的有点
(1)AOF 可以更好的保护数据不丢失, 一般 AOF 会每隔 1 秒, 通过一个后台线程执行一次 fsync 操作, 最多丢失 1 秒钟的数据
(2)AOF 日志文件以 append-only 模式写入, 使用没有任何磁盘寻址开销, 写入性能非常高, 而且文件不容易破损, 即使文件破损, 也很容易恢复
(3)AOF 日志文件即使过大的时候, 出现后台重写操作, 也不会影响客服端的读写. 因为在 rewrite log 的时候, 会对其中的指令进行压缩, 创建出一份需要恢复数据的最小日志出来.
再创建新日志文件的时候, 老的日志文件还是照常写入, 当写的 merge 后的日志文件 ready 的时候, 在交换新来日志文件即可
(4)AOF 日志文件的命令通过非常可读的方式进行记录, 这个特性非常适合做灾难性的误删除紧急恢复. 比如某人不小心用 flushall 命令清空了所有数据, 重要这个时候后台 rewrite 还没有发生, 那么就可以立即拷贝 AOF 文件,
将最后一条 flushll 命令删除, 然后再将该 AOF 文件放回去, 就用通过恢复机制, 自动恢复所有数据
5:AOF 持久化机制的缺点
(1) 对于同一个数据来说, AOF 日志文件通常比 RDB 数据快照文件更大
(2)AOF 开启后, 支持的鞋 QPS 会不 RDB 的写 QPS 低, 因为 AOF 一般会配置成每秒 fsync 一次日志文件, 当然, 每秒一次 fsync 性能还是很高的
(3) 以前 AOF 发成过 bug, 就是通过 AOF 记录的日志, 进行数据恢复的时候, 没有恢复一模一样的数据出来. 所以类似 AOF 这种较为复杂的基于命令日志 / merge / 回放的方式, 比基于 RDB 每次持久化一份完整的数据快照文件的方式,
更加脆弱一些, 容易有 bug. 不过 AOF 就是为了避免 rewrite 过程导致的 bug, 因此每次 rewrite 并不是基于旧的指令日志进行 merge, 而是基于当时内存中的数据进行指令的重新构建, 在行业内个的健壮性会更好
6:RDB 和 AOF 到底该如何选择
(1) 不要仅仅使用 RDB, 因为那样会导致丢失很多数据
(2) 也不要仅仅使用 AOF, 因为那样有两个问题. 第一, 通过 AOF 做冷备份, 没有 RDB 做冷备份恢复速度快; 第二, RDB 每次简单粗暴生成的数据, 更加健壮, 可以避免 AOF 这种复杂的备份和回复机制的 bug
(3) 综合使用 AOF 和 RDB 两种持久化机制, 用 AOF 来保证数据不丢失, 作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备份, 在 AOF 文件都丢失或损坏不可用的时候, 还可以使用 RDB 来进行快速的数据恢复
来源: http://www.bubuko.com/infodetail-3297350.html