上期我们讨论了Redis的主从同步（复制）机制。本期我们将深入探讨Redis的哨兵机制，它可以确保在主节点故障时的高可用性和故障转移。 在互联网应用中，Redis扮演着江湖门派的武林盟主。为了提高门派稳定性，每个门派都会有掌门和副掌门。在一些小门派中，当掌门逝世后，会举行追悼大会并从副掌门中选举出一位新掌门。在一些大型门派（如淘宝、微信），却不可一日无掌门。 以武当派（淘宝Redis）为例，如何保证门派的稳定性呢？我们依赖于副掌门机制（主从复制）进行备份。本期我们将讨论在掌门发生故障后如何高效地交接事务（故障转移）。 在武林门派大会2.8后，每个门派设立了一个专门负责掌门交接事宜的哨兵部门。

哨兵部门的职责

哨兵部门的主要职责包括： 监控：监控所有掌门（主节点和从节点）的状态。 故障转移：在掌门故障后，快速选出一个新的掌门并接替门派事务。 配置提供：向客户端提供主节点信息。 通知：当掌门易主后，向客户端发布新的主节点地址。

3.1 监控 - 感知各掌门的状态

哨兵会定期向各掌门发送ping命令，掌门在规定时间内回复即为正常状态。如果掌门在规定时间内不回复，哨兵就会将其标记为主观下线。

3.2 节点切换

为了防止网络故障或阻塞等因素导致错误判断，哨兵采用客观下线机制。当一个哨兵将节点标记为主观下线后，它会向其他哨兵发出命令。如果多数哨兵（如3个哨兵有2个）都同意此判断，节点才会被标记为客观下线。

3.3 发布通知

当节点被标记为客观下线，哨兵部门会选出新的主节点并向客户端发布新的主节点地址。

3.4 节点恢复

如果客观下线的节点恢复后，哨兵会将其标记为上线状态并重新参与故障转移投票。 哨兵机制具有以下优点： 高可用性：确保在主节点故障时可以快速切换到备份节点，保证业务的连续性。 自动故障转移：哨兵会自动检测和响应主节点故障，无需人工干预。 配置中心：哨兵为客户端提供主节点信息，简化了客户端连接过程。 哨兵一般部署在多个节点上，以保证监控和故障转移的稳定性。哨兵节点之间通过gossip协议进行通信，并定期交换信息以保持一致性。 Redis哨兵机制是一个强大而可靠的高可用性解决方案。企业可以通过部署哨兵集群来增强其Redis应用的高可用性和容错能力，确保业务的稳定高效运行。

---

Redis 学习总结(3) Redis 哨兵模式

在实际开发中不会仅仅部署一个 Redis 服务器，为了获得高可用，Redis 哨兵模式 则是高可用的一种选择。

本文先介绍下 哨兵模式，再介绍了如何在 springboot 项目中使用。

这意味着使用 Sentinel （哨兵模式），您可以创建一个 Redis 部署，它可抵抗某些类型的故障（进行故障迁移）而无需人工干预。

它有这些功能：

Sentinel 的分布式特性 Redis Sentinel 是一个分布式系统，多个 Sentinel 进程协同工作，有这些优势：

部署前需要了解:

三个节点的基本配置

法定人数和仲裁 在配置 哨兵模式时，要指定一个 quorum，它可理解为“法定人数”。 假设有3 个 哨兵，法定人数为2。那么：

哨兵和副本的自动发现 Sentinel 与其他 Sentinel 保持连接，以便相互检查彼此的可用性并交换消息。

但是，您不需要在您运行的每个 Sentinel 实例中配置其他 Sentinel 地址的列表，因为 Sentinel 使用 Redis 实例的 Pub/Sub 功能来发现正在监视相同主节点和副本的其他 Sentinel。

类似地，您不需要配置附加到主服务器的副本地址在哪里，因为 Sentinel 会通过查询 Redis 自动发现它们。

参考我的另一篇文章：

一般需要三个节点，每个节点有一个 redis 和一个哨兵。

下面再分别描述。

我这里按三个 节点，先配置 redis 的主从复制。1个节点作为 master ，2个副本。

配置节点1：master 这里的 redis 作为 master 主redis，其他两个节点作为从节点。 我的文件夹名字叫 box1，这里编辑一个 box1/ 文件，主要配置内容如下:

配置节点2：副本 编辑一个 box2/ 文件，主要配置内容如下:

配置节点3：副本 编辑一个 box3/ 文件，主要配置内容如下:

分别启动这三个redis 命令行执行 redis-server ，并指定 配置文件的路径参数。

如何查看“主从复制”是否配置成功？ 使用 info replication命令，操作如下：

副本节点设置为只读？ 从 Redis 2.6 开始，副本已被默认设置为 只读，无需额外配置。.

一般情况下，至少会需要三个哨兵对redis 进行监控，我们可以通过修改端口启动多个sentinel 服务。

第一个哨兵： 哨兵的 默认端口是 ，这里不改。

第二个哨兵： 修改哨兵端口。

第三个哨兵： 修改哨兵端口。

启动哨兵 使用 redis-sentinel 命令，分别启动这三个哨兵

哨兵的自动发现 当三个哨兵都启动后，在各个哨兵的打印日志里可以看到， 三个哨兵已互相发现了彼此的存在 。

至此，配置完毕了，我们有三个 redis，和三个哨兵，看下截图。

模拟 master 宕机 按 ctrl+c 停止 master，其位于 6379 。停止后，从日志可以看到，哨兵和 redis副本先努力继续连接 6379，反复几次失败后，开始选举出新的 master。截图如下：

至此，配置完毕。

我们看下 springboot 项目的客户端如何配置 以访问 哨兵模式的 redis。

Redis 哨兵支持 对于处理高可用Redis，Spring Data Redis 已经支持Redis Sentinel，使用RedisSentinelConfiguration，如下例所示：

Jedis 和 Lettuce 两种 redis 驱动都可以支持。

RedisSentinelConfiguration 也可以用可以 通过 PropertySource 来设置，它允许您设置以下属性：

配置

比如我这里修改我的 文件如下：

我的配置文件示例：我的 springboot 配置实例：

Redis官网 sentinel 介绍

spring-data/data-redis

Redis哨兵模式的实现原理

Redis哨兵模式的实现原理。 关于哨兵的原理，关键是了解以下几个概念：定时任务：每个哨兵节点维护了3个定时任务。 定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。 主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。 顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。 客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。 需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。 选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。 监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。 选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。