Redis篇-20--运维篇2-哨兵机制（主从节点监听，故障转移，高可用，配置案例）

1、概述

Redis哨兵机制是一种高可用的解决方案，它通过一组哨兵进程来监控Redis主从节点的运行状态。当主节点出现故障时，哨兵会自动将其中一个从节点提升为新的主节点，并通知其他从节点和客户端更新配置，从而实现自动故障转移。

下图为"1主2从3哨兵"示意图：

2、哨兵机制的主要功能

- 监控 ：哨兵进程会定期向Redis主从的每个节点发送PING命令，检测它们的运行状态。
- 自动故障转移 ：当主节点出现故障时，哨兵会自动选择一个从节点提升为主节点，并通知其他节点和客户端更新配置。
- 配置提供者 ：哨兵可以作为客户端的配置提供者，通知客户端新的主节点地址。
- 通知：哨兵可以通过API向管理员或其他应用程序发送通知，告知Redis节点的状态变化。

3、哨兵机制的工作原理

1、节点发现与配置

哨兵通过配置文件指定要监控的Redis主节点和从节点，启动后哨兵会连接到这些节点，并获取它们的拓扑结构和状态信息。
2、心跳检测

哨兵会定期向Redis主从节点发送PING命令，检测它们的运行状态。如果主节点在规定时间内没有响应PING命令，哨兵会将其标记为主观下线。
3、客观下线判断

当多个哨兵都将主节点标记为主观下线时，哨兵之间会进行协商，如果达到法定人数（quorum），则主节点会被标记为客观下线。
4、选主与故障转移

主节点被标记为客观下线后，哨兵会开始选举一个新的主节点。选举过程会考虑从节点的优先级、复制进度等因素。选举完成后，哨兵会将新的主节点信息广播给其他哨兵和客户端，所有其他的从节点也会重新配置为复制新的主节点。
5、配置更新与通知

哨兵会更新集群的配置信息，并通知客户端新的主节点地址。客户端在接收到通知后，会更新自己的配置，并开始向新的主节点发送请求。

4、哨兵中重点概念介绍

1、主观下线 (Subjectively Down, SDOWN)

当一个哨兵节点认为某个主服务器（master）不可达时，它会将这个主服务器标记为"主观下线"。这种判断是基于单个哨兵节点的视角，即如果哨兵在指定的时间内没有从主服务器收到有效的回复（比如PING命令），那么该哨兵就会认为主服务器可能已经故障了。

2、客观下线 (Objectively Down, ODOWN)

一旦一个主服务器被标记为主观下线，哨兵会向其他哨兵发送消息，询问它们是否也认为该主服务器不可达。如果足够数量的哨兵（达到quorum参数定义的数量）同意这个观点，那么主服务器就会被标记为"客观下线"。ODOWN是一个集体决策的结果，确保了故障转移不是由单一哨兵节点的误判触发的。

3、法定人数 (Quorum)

quorum参数定义了在决定一个主服务器客观下线以及执行自动故障转移时需要多少个哨兵达成一致。法定人数可以防止少数哨兵错误地启动故障转移，同时也保证了在部分哨兵网络分区的情况下，系统仍然能够正常运作。

4、领导选举 (Leader Election)

在进行故障转移之前，哨兵集群需要选出一个领头的哨兵来协调整个过程。这个过程通过Raft算法或者类似的共识算法实现。领头哨兵负责选择新的主服务器，并通知其他哨兵和从服务器更新配置。选举过程中，哨兵之间会互相交流，以确定哪个哨兵最适合担任领导角色。

5、故障转移 (Failover)

当主服务器被标记为ODOWN后，领头哨兵将发起一次故障转移操作。这包括以下几个步骤：

选择新的主服务器：通常会选择一个与旧主服务器数据最同步的从服务器作为新的主服务器。
晋升新主服务器：领头哨兵会向选中的从服务器发送命令，将其晋升为新的主服务器。
重新配置从服务器：所有其他的从服务器会被配置为复制新的主服务器。
通知客户端：领头哨兵还会更新其内部的配置，使得后续连接到哨兵的客户端能够获得最新的主服务器信息。

6、多哨兵部署

为了提高哨兵系统的可靠性和容错性，通常建议部署多个哨兵实例。这些哨兵可以分布在不同的物理机器上，甚至是在不同的数据中心或云区域中。多哨兵部署有助于避免单点故障，并且可以通过法定人数机制确保即使某些哨兵不可用，系统仍能正确地进行故障检测和转移。

7、哨兵之间的通信

哨兵之间使用特殊的Redis命令集来进行通信，如SENTINEL is-master-down-by-addr用于检查某个主服务器的状态，SENTINEL reset用于重置对特定主服务器的监控等。此外，哨兵还会订阅Redis的发布/订阅频道，以便接收来自其他哨兵的消息和事件通知。

8、监控与通知

除了上述的核心功能外，哨兵还可以设置通知机制，允许管理员或其他应用程序通过API或脚本接收到关于Redis集群状态变化的通知。例如，当发生故障转移时，哨兵可以发送电子邮件、短信或调用Webhook来提醒相关人员。

5、哨兵机制配置示例

如实现：1主2从3哨兵的配置。

1、主节点 (Master) 配置

主节点redis.conf文件配置：

java 复制代码

端口号
port 6379

绑定IP地址（根据实际情况修改）
bind 127.0.0.1

 开启持久化（可选，根据需求配置）
appendonly yes

 设置密码（如果需要）
requirepass yourpassword

主节点启动：

java 复制代码

redis-server /path/to/redis.conf

2、从节点 (Slave) 配置

两个从节点的redis.conf文件配置：
从节点1:

java 复制代码

 端口号
port 6380

 绑定IP地址（根据实际情况修改）
bind 127.0.0.1

 开启持久化（可选，根据需求配置）
appendonly yes

 设置密码（如果需要）
requirepass yourpassword

 指定主节点的地址和端口
slaveof 127.0.0.1 6379
masterauth yourpassword

从节点2:

java 复制代码

端口号
port 6381

绑定IP地址（根据实际情况修改）
bind 127.0.0.1

开启持久化（可选，根据需求配置）
appendonly yes

设置密码（如果需要）
requirepass yourpassword

指定主节点的地址和端口
slaveof 127.0.0.1 6379
masterauth yourpassword

启动两个从节点实例 ：

redis-server /path/to/redis.conf

3、哨兵节点配置

三个哨兵节点的sentinel.conf文件配置""
说明：启动redis服务是修改redis.conf配置文件，启动哨兵配置是修改sentinel.conf文件。

java 复制代码

哨兵端口号，相同ip下时注意切换不同哨兵节点的端口
port 26379

绑定IP地址（根据实际情况修改）
bind 127.0.0.1

哨兵监控的主节点信息
sentinel monitor mymaster 127.0.0.1 6379 2

设置法定人数（quorum），即至少需要多少个哨兵同意才能认为主节点下线
sentinel quorum mymaster 2

设置哨兵认为主节点失效的时间阈值（毫秒）
sentinel down-after-milliseconds mymaster 30000

设置故障转移的超时时间（毫秒）
sentinel failover-timeout mymaster 180000

如果设置了Redis密码，还需要配置密码
sentinel auth-pass mymaster yourpassword

可选：设置哨兵日志级别
logfile "/path/to/sentinel.log"
loglevel notice

可选：指定哨兵之间的通信端口（通常不需要修改）
sentinel announce-ip 127.0.0.1
sentinel announce-port 26379

启动3个哨兵实例：

java 复制代码

redis-sentinel /path/to/sentinel.conf

哨兵配置信息说明：

java 复制代码

（1）、监听主节点配置
sentinel monitor mymaster 127.0.0.1 6379 2
  - sentinel monitor：这是固定的命令，用于告诉哨兵开始监控一个Redis主节点。
  - mymaster：这是主节点的名称，不是固定的，你可以根据需要自定义这个名称。它只是一个标识符，用于在哨兵配置和日志中引用该主节点。确保这个名字在整个哨兵集群中是唯一的。
  - 127.0.0.1：这是主节点的IP地址。你需要将其替换为实际的主节点IP地址。
  - 6379：这是主节点的端口号。你需要将其替换为实际的主节点端口号。
  - 2：这是法定人数（quorum），表示至少需要多少个哨兵同意才能认为主节点下线。这个数字应该小于或等于哨兵的数量，以确保有足够的哨兵参与决策。

（2）、法定人数配置
sentinel quorum mymaster 2
- sentinel quorum是固定的关键词，后面的名称（如mymaster）和法定人数（如2）可以根据实际情况调整。即：哨兵系统需要多少个哨兵同意才能认为该主节点客观下线（ODOWN）。这个值应该根据你的哨兵数量合理设置，避免过低或过高。

（3）、主节点失效时间 (sentinel down-after-milliseconds)
sentinel down-after-milliseconds mymaster 30000
- sentinel down-after-milliseconds是固定的关键词，后面的名称（如mymaster）和时间（如30000）可以根据实际情况调整。即：如果哨兵在指定时间（单位：毫秒）内没有收到主节点的响应，它会认为主节点可能已经故障。

（4）、故障转移超时时间 (sentinel failover-timeout)
sentinel failover-timeout mymaster 180000
- sentinel failover-timeout是固定的关键词，后面的名称（如mymaster）和时间（如180000）可以根据实际情况调整。即：如果在这个时间（单位：毫秒）内故障转移未能完成，哨兵将认为故障转移失败。

（5）、Redis密码 (sentinel auth-pass)
sentinel auth-pass mymaster yourpassword
- sentinel auth-pass是固定的关键词，后面的名称（如mymaster）和密码（如yourpassword）需要根据实际情况填写。如果Redis主节点设置了密码保护，你需要在这里提供相应的密码。

（6）、日志文件 (logfile)
logfile "/path/to/sentinel.log"
   - logfile是固定的关键词，后面的路径（如/path/to/sentinel.log）可以根据实际情况调整。即：指定哨兵的日志文件路径。日志记录了哨兵的操作和状态变化，有助于调试和监控。

（7）、日志级别 (loglevel)
loglevel notice
- loglevel是固定的关键词，后面的级别（如notice）可以根据需求调整。设置哨兵的日志级别。常见的日志级别包括debug、verbose、notice、warning等。notice是一个常用的级别，记录重要的信息而不产生过多的噪音。

6、哨兵配置文件不需要指定从节点

如上的示例可以看到，哨兵机制配置只需要显式地指定了对主节点的信息，并不需要单独为每个从节点配置监听。

原因如下：
1、哨兵自动发现从节点

当哨兵开始监控一个主节点（通过sentinel monitor命令）时，它不仅会监控该主节点，还会自动发现并监控与主节点关联的所有从节点。这是因为Redis的主从复制机制是基于订阅/发布（Pub/Sub）模式的，主节点会向所有连接的从节点发送状态更新。哨兵通过与主节点通信，能够获取到所有从节点的信息。

2、如何发现从节点
- 初始发现 ：当哨兵第一次连接到主节点时，它会通过INFO replication命令获取主节点的当前从节点列表。这个命令返回了所有从节点的IP地址和端口号。
- 动态更新：在哨兵启动后，主节点的从节点列表可能会发生变化（例如，新的从节点加入或旧的从节点离开）。哨兵会定期查询主节点的状态，并通过Redis的发布/订阅机制（如+slave事件）实时接收从节点的变化通知，确保其始终掌握最新的从节点信息。

3、哨兵对从节点的监控

一旦哨兵发现了从节点，它会像监控主节点一样，定期向这些从节点发送PING命令，检查它们的健康状况。哨兵还会监控从节点的复制进度、延迟等信息，以确保它们能够及时跟上主节点的数据变化。

4、从节点的角色

在哨兵机制中，从节点的主要作用是：

数据备份：从节点通过复制主节点的数据，提供冗余备份，防止数据丢失。
故障转移：当主节点发生故障时，哨兵会选择一个合适的从节点晋升为新的主节点，确保服务的连续性。

学海无涯苦作舟！！！