刚好紧接上一章 的主从架构，我们这次来分享另外一种 原生高可用方案，就是 sentinel 哨兵 架构

主从架构优势比较明显，可以 保障数据的高可用，从服务器可以扩展主服务器的读能力，有效应对大并发操作

但是，如果主服务器发生故障的时候，需要手动将一个从服务器升级为主服务器，同时需要通知业务方变更配置，并且需要让其它从服务器去复制新主服务器节点，整个过程需要人为干预，比较繁琐；另外还有一个就是，如果没有升级 Redis 到 2.8 以上，则 可能因为 全量同步问题 造成大量资源消耗

所以 Redis 社区推出了一种原生的高可用解决方案，就是 Redis sentinel 架构，由一个或多个 sentinel 实例 组成的 sentinel 系统可以监控任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监控的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务，实现 Redis 架构的 监控、通知 以及 自动故障转移

Redis 的高可用 很大程度上要归功于其 为 事件驱动服务工具，采用 Reactor 模式 使得其 拥有高性能 IO 操作

首先我们先科普一下什么叫 Reactor 模式，即 事件驱动机制，应用程序提供相应的接口并注册到 Reactor 上，如果相应的事件发生，Reactor 将主动调用之前注册的接口，而这些接口又称为 回调函数

上次我们主要讲解的是 RDB 机制，这次我们着重对 AOF 持久化进行详细说明，另外后续我们也会针对 RDB-AOF 混合模式（Redis 4 开始）进行分享…

AOF（Append Only File）顾名思义 只进行追加操作的文件，通过保存 Redis 服务器所执行的 命令来记录数据库的状态，命令数据都是以 Redis 的请求协议格式（RESP 协议）保存在文本中的，协议详情可以参考之前的文章 RESP 协议

• 优势：AOF 提供了多种策略进行 数据持久化，即使是 默认的 每秒钟 fsync 一次，也能保障最多丢失一秒的数据（fsync 是在后台使用 另外的线程进行执行，不影响 业务线程的处理）；AOF 采用 append 的形式，即使服务器在一瞬间宕机，也不会对之前数据造成影响，即使宕机瞬间产生数据格式问题，也可以通过 redis-check-aof 工具进行 一致性修复；另外，AOF 采用了 RESP 协议，具有很强的可读性
• 劣势：AOF 由于保存了所有数据处理命令集，在同样大小数据规模的情况下，AOF文件 比 RDB文件 会大很多；同样道理，在数据恢复方面，AOF 会慢一些

相信能看到这的各位大神 肯定都知道 RDB（Redis DataBase）/ AOF（Append Only File） 两种 Redis 持久化机制，大多数也熟知两种方式的 优劣之处；但是 它们的 原理、存储方式、协议 等等方面 就不是所有人都清楚的了，所以我们接下来就分作两期 分别对 RDB 和 AOF 机制进行详细说明…

RDB（Redis DataBase）顾名思义 Redis 数据存储，将 Redis 服务器里数据以 文件的形式 存入 硬盘 加以备份

• 优势：RDB 为一个紧致的二进制文件，保存了截止到某个点的所有数据集，极其适合备份，可以方便根据业务进行不同时机的备份，由于只有一个文件，无论是在灾备还是在恢复上都十分便利。备份的时候可以选择 fork 出子进程进行持久化操作，这样就可以极大的避免影响服务进程的 IO 操作
• 劣势：由于 RDB 每次备份可能由于 数据集 比较大而 在子进程中 运行一段时间，所以通常都是 定时执行，但是，如果业务对数据的高可用性要求很高，甚至不能容忍几分钟少量的数据丢失，那么 RDB 恐怕不是一个好的选择，毕竟服务器一旦在定时执行之前宕机，那么这段时间的数据将丢失掉

前面几篇介绍了 各种数据类型以及其底层实现， 从这篇开始我们就要介绍 Redis 的高级功能部分，虽然会比较抽象，但是通过 CGDB 调试辅助，还是可以顺利理解

Redis 数据库为 各种数据类型（字符串、列表、集合、有序集合、哈希 类型）的 存储载体，当然 Redis db 也并不仅仅是 存储功能，这次 我们就对其 进行详细解说 ……

有序集合类型 的对象编码方式为 OBJ_ENCODING_ZIPLIST 和 OBJ_ENCODING_HT，对应的 底层数据结构为 压缩列表ziplist 和 字典dict

其实 哈希类型 和 有序集合类型 一定程度上很像，特别是在 ziplist 的类型限制条件上

哈希类型 在使用 ziplist 作为底层数据结构的时候，每个 集合元素 使用紧挨着的两个压缩列表节点表示，第一个节点 保存元素 成员，第二个节点 保存元素 分值；压缩列表中集合元素都是按照 添加时间上 进行排序存储的，后添加的 键值对 从 压缩列表 尾部 压入

而 哈希类型 中的 字典结构 就比较简单了，哈希类型 每个键值对 都对应 字典中的每个键值对，就像我们在 字典篇章 中提到的，比如 HMSET person name "kety" age 20 weight "75kg" height 20，即为 操作 key 为 person 的字典，而 值也是由字典结构数据组成，key=name | key=age | key=weight | key=height

有序集合类型 的对象编码方式为 OBJ_ENCODING_ZIPLIST 和 OBJ_ENCODING_SKIPLIST，对应的 底层数据结构为 压缩列表ziplist 和 跳跃表skiplist

zset 在使用 ziplist 作为底层数据结构的时候，每个 集合元素 使用紧挨着的两个压缩列表节点表示，第一个节点 保存元素 成员，第二个节点 保存元素 分值；压缩列表中集合元素都是按照 分值 从小到大 进行排序存储的，分值比较小的放在靠近 表头的方向

而 zset 在使用 skiplist 作为底层数据结构的时候，跳跃表存储部分 之前在 跳跃表 skiplist 篇 写的非常详细了，需要注意的是 每个 zset 结构都是 包含一个 数据字典 和 一个跳跃表

1
2
3
4
5
6
7

// zset 结构
typedef struct zset {
    // 数据字典
    dict *dict;
    // 跳跃表数据
    zskiplist *zsl;
} zset;

集合类型 的对象编码方式为 OBJ_ENCODING_INTSET 和 OBJ_ENCODING_HT，对应的 底层数据结构为 整数集合 intset 和 字典 dict