共计 12778 个字符，预计需要花费 32 分钟才能阅读完成。
Redis 的主从复制模式下，一旦主节点因为故障不能提供服务，须要人工将从节点降职为主节点，同时还要告诉利用方更新主节点地址，对于很多利用场景这种故障解决的形式是无奈承受的。Redis 从 2.8 版本开始正式提供了 Redis Sentinel（哨兵）架构来解决这个问题。
基本概念
主从复制的问题
Redis 的主从复制模式能够将主节点的数据扭转同步给从节点，这样从节点就能够起到两个作用：第一，作为主节点的一个备份，一旦主节点出了故障不可达的状况，从节点能够作为后备“顶”上来，并且保证数据尽量不失落（主从复制是最终一致性）。第二，从节点能够扩大主节点的读能力，一旦主节点不能支撑住大并发量的读操作，从节点能够在肯定水平上帮忙主节点分担读压力。
然而主从复制也带来了以下问题：
- 一旦主节点呈现故障，须要手动将一个从节点降职为主节点，同时须要批改利用方的主节点地址，还须要命令其余从节点去复制新的主节点，整个过程都须要人工干预。
- 主节点的写能力受到单机的限度。
- 主节点的存储能力受到单机的限度。
其中第一个问题就是 Redis 的高可用问题，第二、三个问题属于 Redis 的分布式问题，会在“集群”外面介绍。
高可用
Redis 主从复制模式下，一旦主节点呈现了故障不可达，须要人工干预进行故障转移，无论对于 Redis 的利用方还是运维方都带来了很大的不便。对于利用方来说无奈及时感知到主节点的变动，必然会造成肯定的写数据失落和读数据谬误，甚至可能造成利用方服务不可用。对于 Redis 的运维方来说，整个故障转移的过程是须要人工来染指的，故障转移实时性和准确性上都无奈失去保障。
思考到这点，有些公司把故障转移流程自动化了，然而依然存在如下问题：第一，判断节点不可达的机制是否健全和规范。第二，如果有多个从节点，怎么保障只有一个被降职为主节点。第三，告诉客户端新的主节点机制是否足够强壮。Redis Sentinel 正是用于解决这些问题。
Redis Sentinel 的高可用性
Redis Sentinel 是一个分布式架构，其中蕴含若干个 Sentinel 节点和 Redis 数据节点，每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其余 Sentinel 节点进行“协商”，当大多数 Sentinel 节点都认为主节点不可达时，它们会选举出一个 Sentinel 节点来实现主动故障转移的工作，同时会将这个变动实时告诉给 Redis 利用方。整个过程齐全是主动的，不须要人工来染指，所以这套计划很无效地解决了 Redis 的高可用问题。
从逻辑架构上看，Sentinel 节点汇合会定期对所有节点进行监控，特地是对主节点的故障实现主动转移。上面以 1 个主节点、2 个从节点、3 个 Sentinel 节点组成的 Redis Sentinel 为例子进行阐明，拓扑构造如图所示。
整个故障转移的解决逻辑有上面 4 个步骤：
- 主节点呈现故障，此时两个从节点与主节点失去连贯，主从复制失败。
- 每个 Sentinel 节点通过定期监控发现主节点呈现了故障。
- 多个 Sentinel 节点对主节点的故障达成统一，选举出 sentinel- 3 节点作为领导者负责故障转移。
- Sentinel 领导者节点执行了故障转移，整个过程是自动化实现的。
通过下面介绍的 Redis Sentinel 逻辑架构以及故障转移的解决，能够看出 Redis Sentinel 具备以下几个性能：
- 监控：Sentinel 节点会定期检测 Redis 数据节点、其余 Sentinel 节点是否可达。
- 告诉：Sentinel 节点会将故障转移的后果告诉给利用方。
- 主节点故障转移：实现从节点降职为主节点并保护后续正确的主从关系。
- 配置提供者：在 Redis Sentinel 构造中，客户端在初始化的时候连贯的是 Sentinel 节点汇合，从中获取主节点信息。
同时看到，Redis Sentinel 蕴含了若个 Sentinel 节点，这样做也带来了两个益处：
- 对于节点的故障判断是由多个 Sentinel 节点共同完成，这样能够无效地避免误判。
- Sentinel 节点汇合是由若干个 Sentinel 节点组成的，这样即便个别 Sentinel 节点不可用，整个 Sentinel 节点汇合仍然是强壮的。
Sentinel 节点自身就是独立的 Redis 节点，只不过它们有一些非凡，它们不存储数据，只反对局部命令。
装置和部署
上面将以 3 个 Sentinel 节点、1 个主节点、2 个从节点组成一个 Redis
Sentinel 进行阐明。
部署流程
Redis Sentinel 中 Redis 数据节点没有做任何非凡配置，依照惯例办法启动就能够。3 个 Sentinel 节点的部署办法是完全一致的（端口不同），上面以 sentinel- 1 节点的部署为例子进行阐明。
配置 Sentinel 节点
// redis-sentinel-26379.conf
port 26379
daemonize yes
logfile “26379.log”
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
Sentinel 节点的默认端口是 26379，sentinel monitor mymaster 127.0.0.1 6379 2 配置代表 sentinel- 1 节点须要监控 127.0.0.1：6379 这个主节点，2 代表判断主节点失败至多须要 2 个 Sentinel 节点批准，mymaster 是主节点的别名，其余 Sentinel 配置将在当前进行具体阐明。
启动 Sentinel 节点
Sentinel 节点的启动办法有两种：
1. 应用 redis-sentinel 命令：
redis-sentinel redis-sentinel-26379.conf
2. 应用 redis-server 命令加 –sentinel 参数：
redis-server redis-sentinel-26379.conf –sentinel
两种办法实质上是一样的。
确认
Sentinel 节点实质上是一个非凡的 Redis 节点，所以也能够通过 info 命令来查问它的相干信息，从上面 info 的 Sentinel 片段来看，Sentinel 节点找到了主节点 127.0.0.1：6379，发现了它的两个从节点，同时发现 Redis Sentinel 一共有 3 个 Sentinel 节点。这里只须要理解 Sentinel 节点可能彼此感知到对方，同时可能感知到 Redis 数据节点就能够了：
$ redis-cli -h 127.0.0.1 -p 26379 info Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
当三个 Sentinel 节点都启动后，整个拓扑构造如图所示。至此 Redis Sentinel 曾经搭建起来了，整体上还是比拟容易的，然而有两点须要强调一下：
- 生产环境中倡议 Redis Sentinel 的所有节点应该散布在不同的物理机上。
- Redis Sentinel 中的数据节点和一般的 Redis 数据节点在配置上没有任何区别，只不过是增加了一些 Sentinel 节点对它们进行监控。
配置优化
本节将对每个配置的应用和优化进行具体介绍。Redis 装置目录下有一个 sentinel.conf，是默认的 Sentinel 节点配置文件，上面就以它作为例子进行阐明。
配置阐明和优化
port 26379
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel auth-pass <master-name> <password>
sentinel notification-script <master-name> <script-path>
sentinel client-reconfig-script <master-name> <script-path>
（1）sentinel monitor
格局：
sentinel monitor <master-name> <ip> <port> <quorum>
本配置阐明 Sentinel 节点要监控的是一个名字叫做 <master-name>，ip 地址和端口为 <ip><port> 的主节点。<quorum> 代表要断定主节点最终不可达所须要的票数。但实际上 Sentinel 节点会对所有节点进行监控，然而在 Sentinel 节点的配置中没有看到无关从节点和其余 Sentinel 节点的配置，那是因为Sentinel 节点会从主节点中获取无关从节点以及其余 Sentinel 节点的相干信息。
<quorum> 参数用于故障发现和断定，例如将 quorum 配置为 2，代表至多有 2 个 Sentinel 节点认为主节点不可达，那么这个不可达的断定才是主观的。对于 <quorum> 设置的越小，那么达到下线的条件越宽松，反之越严格。个别倡议将其设置为 Sentinel 节点的一半加 1。同时 <quorum> 还与 Sentinel 节点的领导者选举无关，至多要有 max（quorum，num（sentinels）/2+1）个 Sentinel 节点参加选举，能力选出领导者 Sentinel，从而实现故障转移。例如有 5 个 Sentinel 节点，quorum=4，那么至多要有 max（quorum，num（sentinels）/2+1）= 4 个在线 Sentinel 节点才能够进行领导者选举。
（2）sentinel down-after-milliseconds
格局：
sentinel down-after-milliseconds <master-name> <times>
每个 Sentinel 节点都要通过定期发送 ping 命令来判断 Redis 数据节点和其余 Sentinel 节点是否可达，如果超过了 down-after-milliseconds 配置的工夫且没有无效的回复，则断定节点不可达，<times>（单位为毫秒）就是超时工夫。这个配置是对节点失败断定的重要依据。
down-after-milliseconds 越大，代表 Sentinel 节点对于节点不可达的条件越宽松，反之越严格。条件宽松有可能带来的问题是节点的确不可达了，那么利用方须要期待故障转移的工夫越长，也就意味着利用方故障工夫可能越长。条件严格尽管能够及时发现故障实现故障转移，然而也存在肯定的误判率。
down-after-milliseconds 尽管以 <master-name> 为参数，但实际上对 Sentinel 节点、主节点、从节点的失败断定同时无效。
（3）sentinel parallel-syncs
格局：
sentinel parallel-syncs <master-name> <nums>
当 Sentinel 节点汇合对主节点故障断定达成统一时，Sentinel 领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发动复制操作，parallel-syncs 就是用来限度在一次故障转移之后，每次向新的主节点发动复制操作的从节点个数 。如果这个参数配置的比拟大，那么多个从节点会向新的主节点同时发动复制操作， 只管复制操作通常不会阻塞主节点，然而同时向主节点发动复制，必然会对主节点所在的机器造成肯定的网络和磁盘 IO 开销。
（4）sentinel failover-timeout
格局：
sentinel failover-timeout <master-name> <times>
failover-timeout 通常被解释成故障转移超时工夫，但实际上它作用于故障转移的各个阶段：
a）选出适合从节点。
b）降职选出的从节点为主节点。
c）命令其余从节点复制新的主节点。
d）期待原主节点复原后命令它去复制新的主节点。
failover-timeout 的作用具体体现在四个方面：
- 如果 Redis Sentinel 对一个主节点故障转移失败，那么下次再对该主节点做故障转移的起始工夫是 failover-timeout 的 2 倍。
- 在 b）阶段时，如果 Sentinel 节点向 a）阶段选出来的从节点执行 slaveof no one 始终失败（例如该从节点此时呈现故障），当此过程超过 failover-timeout 时，则故障转移失败。
- 在 b）阶段如果执行胜利，Sentinel 节点还会执行 info 命令来确认 a）阶段选出来的节点的确降职为主节点，如果此过程执行工夫超过 failover-timeout 时，则故障转移失败。
- 如果 c）阶段执行工夫超过了 failover-timeout（不蕴含复制工夫），则故障转移失败。留神即便超过了这个工夫，Sentinel 节点也会最终配置从节点去同步最新的主节点，不过就不会按 parallel-syncs 所配置的规定来进行同步了。
（5）sentinel auth-pass
格局：
sentinel auth-pass <master-name> <password>
如果 Sentinel 监控的主节点配置了明码，sentinel auth-pass 配置通过增加主节点的明码，避免 Sentinel 节点对主节点无奈监控。
（6）sentinel notification-script
格局：
sentinel notification-script <master-name> <script-path>
sentinel notification-script 的作用是在故障转移期间，当一些正告级别的 Sentinel 事件产生（指重要事件，例如 -sdown：主观下线、-odown：主观下线）时，会触发对应门路的脚本，并向脚本发送相应的事件参数。
（7）sentinel client-reconfig-script
格局：
sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script 的作用是在故障转移完结后，会触发对应门路的脚本，并向脚本发送故障转移后果的相干参数。当故障转移完结，每个 Sentinel 节点会将故障转移的后果发送给对应的脚本，具体参数如下：
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
- <master-name>：主节点名。
- <role>：Sentinel 节点的角色，别离是 leader 和 observer，leader 代表以后 Sentinel 节点是领导者，是它进行的故障转移；observer 是其余 Sentinel 节点。
- <from-ip>：原主节点的 ip 地址。
- <from-port>：原主节点的端口。
- <to-ip>：新主节点的 ip 地址。
- <to-port>：新主节点的端口。
无关 sentinel notification-script 和 sentinel client-reconfig-script 有几点须要留神：
- <script-path> 必须有可执行权限。
- <script-path> 结尾必须蕴含 shell 脚本头（例如 #！/bin/sh），否则事件产生时 Redis 将无奈执行脚本产生谬误。
- Redis 规定脚本的最大执行工夫不能超过 60 秒，超过后脚本将被杀掉。
- 如果 shell 脚本以 exit 1 完结，那么脚本稍后重试执行。如果以 exit 2 或者更高的值完结，那么脚本不会重试。失常返回值是 exit 0。
- 如果须要运维的 Redis Sentinel 比拟多，倡议不要应用这种脚本的模式来进行告诉，这样会减少部署的老本。
监控多个主节点
Redis Sentinel 能够同时监控多个主节点，配置办法也比较简单，只须要指定多个 masterName 来辨别不同的主节点即可，例如上面的配置监控 monitor master-business-1（10.10.xx.1：6379）和 monitor master-business-2（10.10.xx.2：6379）两个主节点：
sentinel monitor master-business-1 10.10.xx.1 6379 2
sentinel down-after-milliseconds master-business-1 60000
sentinel failover-timeout master-business-1 180000
sentinel parallel-syncs master-business-1 1
sentinel monitor master-business-2 10.16.xx.2 6380 2
sentinel down-after-milliseconds master-business-2 10000
sentinel failover-timeout master-business-2 180000
sentinel parallel-syncs master-business-2 1
调整配置
和一般的 Redis 数据节点一样，Sentinel 节点也反对动静地设置参数，而且和一般的 Redis 数据节点一样并不是反对所有的参数，具体应用办法为：
sentinel set <param> <value>
反对的参数如下：
有几点须要留神一下：
- sentinel set 命令只对以后 Sentinel 节点无效。
- sentinel set 命令如果执行胜利会立刻刷新配置文件，这点和 Redis 一般数据节点设置配置须要执行 config rewrite 刷新到配置文件不同。
- 倡议所有 Sentinel 节点的配置尽可能统一，这样在故障发现和转移时比拟容易达成统一。
- Sentinel 对外不反对 config 命令。
部署技巧
Sentinel 节点不应该部署在一台物理“机器”上
这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比拟风行的容器，它们尽管有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点汇合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。
部署至多三个且奇数个的 Sentinel 节点
3 个以上是通过减少 Sentinel 节点的个数进步对于故障断定的准确性，因为领导者选举须要至多一半加 1 个节点，奇数个节点能够在满足该条件的根底上节俭一个节点。
只配置一套 Sentinel，还是每个主节点配置一套 Sentinel？
Sentinel 节点汇合能够只监控一个主节点，也能够监控多个主节点，那么在理论生产环境中更偏差于哪一种部署形式呢，上面别离剖析两种计划的优缺点。
计划一：一套 Sentinel，很显著这种计划在肯定水平上升高了保护老本，因为只须要保护固定个数的 Sentinel 节点，集中对多个 Redis 数据节点进行治理就能够了。然而这同时也是它的毛病，如果这套 Sentinel 节点汇合出现异常，可能会对多个 Redis 数据节点造成影响。还有如果监控的 Redis 数据节点较多，会造成 Sentinel 节点产生过多的网络连接，也会有肯定的影响。
计划二：多套 Sentinel，显然这种计划的长处和毛病和下面是相同的，每个 Redis 主节点都有本人的 Sentinel 节点汇合，会造成资源节约。然而长处也很显著，每套 Redis Sentinel 都是彼此隔离的。
如果 Sentinel 节点汇合监控的是同一个业务的多个主节点汇合，那么应用计划一、否则个别倡议采纳计划二。
API
以下图进行阐明：Sentinel 节点汇合监控着两组主从模式的 Redis 数据节点。
sentinel master
展现所有被监控的主节点状态以及相干的统计信息。
sentinel master <master name>
展现指定 <master name> 的主节点状态以及相干的统计信息。
sentinel slaves <master name>
展现指定 <master name> 的从节点状态以及相干的统计信息。
sentinel sentinels <master name>
展现指定 <master name> 的 Sentinel 节点汇合（不蕴含以后 Sentinel 节点）。
sentinel get-master-addr-by-name <master name>
返回指定 <master name> 主节点的 IP 地址和端口。
sentinel reset <pattern>
以后 Sentinel 节点对合乎 <pattern>（通配符格调）主节点的配置进行重置，蕴含革除主节点的相干状态（例如故障转移），从新发现从节点和 Sentinel 节点。
sentinel failover <master name>
对指定 <master name> 主节点进行强制故障转移（没有和其余 Sentinel 节点“协商”），当故障转移实现后，其余 Sentinel 节点依照故障转移的后果更新本身配置。
sentinel ckquorum <master name>
检测以后可达的 Sentinel 节点总数是否达到 <quorum> 的个数。例如 quorum=3，而以后可达的 Sentinel 节点个数为 2 个，那么将无奈进行故障转移，Redis Sentinel 的高可用个性也将失去。
sentinel flushconfig
将 Sentinel 节点的配置强制刷到磁盘上，这个命令 Sentinel 节点本身用得比拟多，对于开发和运维人员只有当内部起因（例如磁盘损坏）造成配置文件损坏或者失落时，这个命令是很有用的。
sentinel remove <master name>
勾销以后 Sentinel 节点对于指定 <master name> 主节点的监控，这个命令仅仅对以后 Sentinel 节点无效。
sentinel monitor <master name> <ip> <port> <quorum>
这个命令和配置文件中的含意是齐全一样的，只不过是通过命令的模式来实现 Sentinel 节点对主节点的监控。
sentinel is-master-down-by-addr
Sentinel 节点之间用来替换对主节点是否下线的判断，依据参数的不同，还能够作为 Sentinel 领导者选举的通信形式。
客户端连贯
Redis Sentinel 客户端根本实现原理
实现一个 Redis Sentinel 客户端的根本步骤如下：
1）遍历 Sentinel 节点汇合获取一个可用的 Sentinel 节点，前面会介绍 Sentinel 节点之间能够共享数据，所以从任意一个 Sentinel 节点获取主节点信息都是能够的。
2）通过 sentinel get-master-addr-by-name master-name 这个 API 来获取对应主节点的相干信息。
3）验证以后获取的“主节点”是真正的主节点，这样做的目标是为了避免故障转移期间主节点的变动。
4）放弃和 Sentinel 节点汇合的“分割”，时刻获取对于主节点的相干“信息”。
从下面的模型能够看出，Redis Sentinel 客户端只有在初始化和切换主节点时须要和 Sentinel 节点汇合进行交互来获取主节点信息，所以在设计客户端时须要将 Sentinel 节点汇合思考成 配置（相干节点信息和变动）发现服务。
实现原理
三个定时监控工作
一套正当的监控机制是 Sentinel 节点断定节点不可达的重要保障，Redis Sentinel 通过三个定时监控工作实现对各个节点发现和监控：
1）每隔 10 秒，每个 Sentinel 节点会向主节点和从节点发送 info 命令获取最新的拓扑构造。
这个定时工作的作用具体能够体现在三个方面：
- 通过向主节点执行 info 命令，获取从节点的信息，这也是为什么 Sentinel 节点不须要显式配置监控从节点。
- 当有新的从节点退出时都能够立即感知进去。
- 节点不可达或者故障转移后，能够通过 info 命令实时更新节点拓扑信息。
2）每隔 2 秒，每个 Sentinel 节点会向 Redis 数据节点的 sentinel：hello 频道上发送该 Sentinel 节点对于主节点的判断以及以后 Sentinel 节点的信息，同时每个 Sentinel 节点也会订阅该频道，来理解其余 Sentinel 节点以及它们对主节点的判断。
这个定时工作能够实现以下两个工作：
- 发现新的 Sentinel 节点：通过订阅主节点的__sentinel__：hello 理解其余的 Sentinel 节点信息，如果是新退出的 Sentinel 节点，将该 Sentinel 节点信息保存起来，并与该 Sentinel 节点创立连贯。
- Sentinel 节点之间替换主节点的状态，作为前面主观下线以及领导者选举的根据。
3）每隔 1 秒，每个 Sentinel 节点会向主节点、从节点、其余 Sentinel 节点发送一条 ping 命令做一次心跳检测，来确认这些节点以后是否可达。
通过下面的定时工作，Sentinel 节点对主节点、从节点、其余 Sentinel 节点都建设起连贯，实现了对每个节点的监控，这个定时工作是节点失败断定的重要依据。
主观下线和主观下线
主观下线
每个 Sentinel 节点会每隔 1 秒对主节点、从节点、其余 Sentinel 节点发送 ping 命令做心跳检测，当这些节点超过 down-after-milliseconds 没有进行无效回复，Sentinel 节点就会对该节点做失败断定，这个行为叫做主观下线。
主观下线
当 Sentinel 主观下线的节点是主节点时，该 Sentinel 节点会通过 sentinel is-master-down-by-addr 命令向其余 Sentinel 节点询问对主节点的判断，当超过 <quorum> 个数，Sentinel 节点认为主节点的确有问题，这时该 Sentinel 节点会做出主观下线的决定，这样主观下线的含意是比拟显著了，也就是大部分 Sentinel 节点都对主节点的下线做了批准的断定，那么这个断定就是主观的。
领导者 Sentinel 节点选举
如果 Sentinel 节点对于主节点曾经做了主观下线，那么是不是就能够立刻进行故障转移了？当然不是，实际上故障转移的工作只须要一个 Sentinel
节点来实现即可，所以 Sentinel 节点之间会做一个领导者选举的工作，选出一个 Sentinel 节点作为领导者进行故障转移的工作。Redis 应用了 Raft 算法实现领导者选举，因为 Raft 算法绝对比拟形象和简单，以及篇幅所限，所以这里给出一个 Redis Sentinel 进行领导者选举的大抵思路：
- 每个在线的 Sentinel 节点都有资格成为领导者，当它确认主节点主观下线时候，会向其余 Sentinel 节点发送 sentinel is-master-down-by-addr 命令，要求将本人设置为领导者。
- 收到命令的 Sentinel 节点，如果没有批准过其余 Sentinel 节点的 sentinel is-master-down-by-addr 命令，将批准该申请，否则回绝。
- 如果该 Sentinel 节点发现自己的票数曾经大于等于 max（quorum，num（sentinels）/2+1），那么它将成为领导者。
- 如果此过程没有选举出领导者，将进入下一次选举。
故障转移
领导者选举出的 Sentinel 节点负责故障转移，具体步骤如下：
1)在从节点列表中选出一个节点作为新的主节点，抉择办法如下：
- 过滤：“不衰弱”（主观下线、断线）、5 秒内没有回复过 Sentinel 节点 ping 响应、与主节点失联超过 down-after-milliseconds*10 秒。
- 抉择 slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则持续。
- 抉择复制偏移量最大的从节点（复制的最残缺），如果存在则返回，不存在则持续。
- 抉择 runid 最小的从节点。
2）Sentinel 领导者节点会对第一步选出来的从节点执行 slaveof no one 命令让其成为主节点。
3）Sentinel 领导者节点会向残余的从节点发送命令，让它们成为新主节点的从节点，复制规定和 parallel-syncs 参数无关。
4）Sentinel 节点汇合会将原来的主节点更新为从节点，并放弃着对其关注，当其复原后命令它去复制新的主节点。
开发与运维中的问题
节点运维
节点下线
如果须要对主节点进行下线，比拟正当的做法是选出一个“适合”（例如性能更高的机器）的从节点，应用 sentinel failover 性能将从节点降职主节点。
Redis Sentinel 存在多个从节点时，如果想将指定从节点降职为主节点，能够将其余从节点的 slavepriority 配置为 0，然而须要留神 failove 后，将 slave-priority 调回原值。
如果须要对从节点或者 Sentinel 节点进行下线，只须要确定好是长期还是永恒下线后执行相应操作即可。如果应用了读写拆散，下线从节点须要保障利用方能够感知从节点的下线变动，从而把读取申请路由到其余节点。
须要留神的是，Sentinel 节点仍然会对这些下线节点进行定期监控，这是由 Redis Sentinel 的设计思路所决定的。
节点上线
从节点：增加 slaveof{masterIp}{masterPort}的配置，应用 redis-server 启动即可，它将被 Sentinel 节点主动发现。
sentinel 节点：增加 sentinel monitor 主节点的配置，应用 redis-sentinel 启动即可，它将被其余 Sentinel 节点主动发现。
高可用读写拆散
在个别的 Redis Sentinel 读写拆散的模型中，从节点不是高可用的，如果 slave 节点呈现故障，首先客户端将与其失联，其次 Sentinel 节点只会对该节点做主观下线，因为 Redis Sentinel 的故障转移是针对主节点的。所以很多时候，Redis Sentinel 中的从节点仅仅是作为主节点一个热备，不让它参加客户端的读操作，就是为了保障整体高可用性，但实际上这种应用办法还是有一些节约，尤其是在有很多从节点或者的确须要读写拆散的场景，所以如何实现从节点的高可用是十分有必要的。
Redis Sentinel 在对各个节点的监控中，如果有对应事件的产生，都会发
出相应的事件音讯，其中和从节点变动的事件有以下几个：
- +switch-master：切换主节点（原来的从节点降职为主节点），阐明缩小了某个从节点。
- +convert-to-slave：切换从节点（原来的主节点降级为从节点），阐明增加了某个从节点。
- +sdown：主观下线，阐明可能某个从节点可能不可用（因为对从节点不会做主观下线），所以在实现客户端时能够采纳本身策略来实现相似主观下线的性能。
- +reboot：重新启动了某个节点，如果它的角色是 slave，那么阐明增加了某个从节点。
所以在设计 Redis Sentinel 的从节点高可用时，只有可能实时把握所有从
节点的状态，把所有从节点看做一个资源池，无论是上线还是下线从节点，客户端都能及时感知到（将其从资源池中增加或者删除），这样从节点的高可用指标就达到了。
