江苏龙网

  1. 主页 > 生活百科 > >

Redis高可用全景一览( 三 )

Redis


到这里 ， 我们就大致理清了 Redis 保证服务少中断所采取的一系列方案了 。那 Redis 是如何保证数据少丢失的呢？
三、AOF和RDB了解 MySQL 的同学可能听说过 ， MySQL 是具有 Crasf-Safe 的能力的 ， 这归功于数据库的写前日志（Write Ahead Log, WAL） Redo Log 。同样 ， Redis 也提供了 AOF 日志 。
3.1 主库宕机了 ， 如何避免数据丢失？AOF 里记录的是 Redis 收到的每一条命令 ， 这些命令是以文本形式保存的 。我们以 Redis 收到“set testkey testvalue”命令后记录的日志为例 ， 看看 AOF 日志的内容 。其中 ， “ *3 ”表示当前命令有三个部分 ， 每部分都是由“$+数字”开头 ， 后面紧跟着具体的命令、键或值 。这里 ， “数字”表示这部分中的命令、键或值一共有多少字节 。例如 ， “$3 set”表示这部分有 3 个字节 ， 也就是“set”命令 。

Redis高可用全景一览

文章插图
AOF日志内容
但是 ， 因为记录的是操作命令 ， 而不是实际的数据 ， 所以 ， 用 AOF 方法进行故障恢复的时候 ， 需要逐一把操作日志都执行一遍 。如果操作日志非常多 ， Redis 就会恢复得很缓慢 ， 影响到正常使用 。
因此 ， Redis 提供了另一种数据持久化方法：内存快照 RDB 。和 AOF 相比 ， RDB 记录的是某一时刻的数据 ， 并不是操作 ， 所以 ， 在做数据恢复时 ， 我们可以直接把 RDB 文件读入内存 ， 很快地完成恢复 。
对于快照来说 ， 系统多久执行一次快照直接影响数据丢失的多少 。如下图所示 ， 我们先在 T0 时刻做了一次快照 ， 然后又在 T0+t 时刻做了一次快照 ， 在这期间 ， 数据块 5 和 9 被修改了 。如果在 t 这段时间内 ， 机器宕机了 ， 那么 ， 只能按照 T0 时刻的快照进行恢复 。此时 ， 数据块 5 和 9 的修改值因为没有快照记录 ， 就无法恢复了 。
Redis高可用全景一览

文章插图
RDB数据丢失
所以 ， 要想尽可能恢复数据 ， t 值就要尽可能小 。那么 ， t 值可以小到什么程度呢 ， 比如说是不是可以每秒做一次快照？
3.2 宕机后 ， 如何快速恢复数据？Redis 4.0 中提出了一个混合使用 AOF 和 RDB 的方法 。简单来说 ， 内存快照以一定的频率执行 ， 在两次快照之间 ， 使用 AOF 日志记录这期间的所有命令操作 。
这样一来 ， 快照不用很频繁地执行 。而且 ， AOF 日志也只用记录两次快照间的操作 ， 也就是说 ， 不需要记录所有操作了 ， 因此 ， 就不会出现文件过大的情况了 ， 也可以避免重写开销 。
Redis高可用全景一览

文章插图
RDB与AOF混合使用
这个方法既能享受到 RDB 文件快速恢复的好处 ， 又能享受到 AOF 只记录操作命令的简单优势 。
小结我来总结一下本文的内容 。Redis 系统的高可用 ， 具体可以通过两个方面来理解：一是服务少中断 ， 二是数据少丢失 。我整理的知识消化链路如下 。
服务少中断 -> 多副本 -> 主从库模式保证数据一致及从库的高可用 -> 哨兵保证主库的高可用 -> 哨兵集群保证哨兵高可用 。数据少丢失 -> AOF日志 -> AOF恢复数据较慢 -> RDB内存快照 -> 执行快照间隔不宜过短 -> AOF+RDB关于哨兵机制的更多实现细节 ， 我会在后面的内容里继续更新 ， 敬请关注 。公众号「杨同学technotes」 ， 欢迎技术交流 。




推荐阅读


上一篇：什么是AOP，AOP能做什么？AOP的特点，Spring AOP的实现

下一篇：“怪胎”ChatGPT的前世今生，以及未来