sentinel工作原理及使用
sentinel 是一个功能全面的、面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。下面说一下它的工作原理及使用方法。
一、 sentinel工作原理
当sentinel作用在调用的接口上时，会将这个接口抽象成一种资源，调用方需要申请这种资源，使用的方法是SphU.entry()，如果能够申请成功，则说明没有被限流，否则会抛出BlockException，表面已经被限流了。
从SphU.entry()方法往下执行会进入到Sph.entry()，在entry中，会为每一次申请创建一个context，这个context就是记录本次请求的上下文，然后还会为每一种资源创建一组插槽，这一组插槽就是责任链模式，每一个插槽实现一个功能，请求会进行插槽一个一个执行，这些插槽主要有以下几个：
其中，ClusterBuilderSlot会为每一种资源申请一个全局的ClusterNode，这个ClusterNode会在StatistcSlot中记录每个线程对这个接口的调用情况（调用总数、成功次数、失败次数等）。StatistcSlot采用的是滑动窗口统计方法，它有两个重要的参数：windowLength（窗口长度）, intervalInSec（时间间隔）。如窗口长度为500ms，时间间隔是1s，这样系统就会申请两个窗口，然后计算当前时间戳为time，进一步确定落在哪个窗口，具体逻辑如下：
可见通过时间窗口，就可以将一次请求对应到一个窗口，进而计算单位时间的流量，进行流控，同时熔断降级也是通过计算单位时间的异常来实现的，所以时间窗口是十分核心的模块。随着统计的不断进行，当一个窗口时间小于当前时间时，会被系统从当前窗口数组中移除，放入到一个list中，本地会启动一个定时任务，周期性的将list中的窗口数据刷新到本地文件中。当dashboard发送获取统计数据的请求后，本地就会返回文件中的数据给dashboard，这样用户就可以看到统计数据。
二、 sentinel的使用
目前使用sentinel主要用4种方式。
1、在代码中直接使用
在代码中直接调用函数SphU.entry()，由于这种方式是直接入侵代码，所以不推荐
2、通过注解添加
在调用的接口上面添加注解@SentinelResource，这样当调用该接口时，spring会通过AOP的方式对含有SentinelResource注解的接口进行增强，采用环绕通知@Around进行切片捕捉，在执行目标方法前执行SphU.entry()。这是一种比较好的方法，但是不适合大规模配置，如果接口众多，一个一个添加注解很麻烦。
3、在filter中添加
目前我们项目中调用接口时，通过filter时，会获取调用接口的名称，让好通过名称为资源命名，这样每个接口就是一种资源，这样想到于在每个接口上执行SphU.entry()，这样就实现了对每个接口对流量监控
4、在dashboard中添加配置
本地代码中加入sentinel的包，相当与client。在服务器上部署了dashboard，可以通过在dashboard中的配置页面来实现sentinel配置的添加。本地的sentinel通过zk来监听最新的配置消息，当配置修改时，zk通过主动推送的方式将配置消息发送给client。
三、 sentinel集群的实现
sentinel中限流、熔断降级可以在本地进行，也可以几个实例组成一个集群来统一控制。在集群模式中，一个实例做service，其余做client，通过netty进行socket通信。client端遇到流量统计、流控、熔断降级都是发送请求到service，由service统一进行流量统计、流控、熔断降级的处理。client的服务发现通过dashboard的动态配置来完成。
四、 sentinel本地与dashboard通信
sentinel本地和dashboard通过http协议通信，实现方式：本地的sentinel-transport-netty-http模块通过netty实现简单的http服务（采用netty提供的http编码和解码方式：HttpRequestDecoder和HttpResponseEncoder），通过SPI获取本地的继承CommandHandler的类，这些类中找到含有注解CommandMapping的类，CommandMapping的name字段就是http中的url，创建一个map，记录url到Handler的映射关系，当本地服务器接收到dashboard的请求时，从里面的url中找到handler，进行请求的处理。其实就是类似于Spring MVC里面的MappingHandler。
五、总结
sentinel的功能强大，使用简单，可帮助大家快速搭建线上监控系统。
sentinel是什么意思
n. 哨兵
vt. 守卫，放哨
[ 过去式 sentinelled或sentineld 过去分词 sentinelled或sentineld 现在分词 sentinelling或sentineling ]
希望采纳啊，，O(∩_∩)O谢谢
redis sentinel 哨兵，看这一篇就够啦！
redis集群模式，丢失master主服务器是无法继续工作的，所以随时都需要一个master节点。但是服务器宕机是经常出现的事情，集群本身是无法完成故障转移的，所以需要一个第三方的解决方案，帮redis集群完成故障转移（选择主节点、通知从节点修改同步master地址，让原来的主节点成为从节点）。
（1）首先sentinel也属于一种redis服务器，只不过启动时加载的配置文件不同。配置文件里包括了监控的主服务器列表（对，可以是多个主服务器，即就是多个集群）。
（2）sentinel通过配置文件中的主服务器IP：端口号，建立链接和订阅，就是一个双向的通道
（3）sentinel默认每10秒，向建立链接的主服务器，发送INFO命令；主服务器收到命令，返回主服务器信息。
可以看到，返回了主服务器的运行ID，重要的是：同步主服务器的从节点信息
（4）从步骤（3）中获取到的从节点信息，从节点的IP和端口。sentinel和从节点建立链接和订阅
（5）sentinel默认每10秒，向建立链接的从服务器，发送INFO命令，从服务器接收到命令后，返回从服务器信息
主要包括了从服务器对应的master节点的地址：端口号，偏移量
（6）sentinel与主服务器和从服务器建立了链接和订阅，可以向主从服务器发送命令，也可以接收主从服务器的广播
订阅命令：subscribe _sentinel_:hello
通道名：hello
sentinel对hello频道的订阅会一直持续到sentinel和服务器之间的链接断开为止
sentinel向服务器通道发送的消息，其他与该服务器建立订阅关系的sentinel也会收到订阅通知，sentinel自己也会收到自己发出的消息的订阅通知
（7）sentinel默认会每两秒一次，向所有建立链接和订阅的主从服务器，发送广播消息
命令：publish_sentinel__:hello "s_ip,s_port,s_runid,s_epoch,m_name,m_ip,m_port,m_epoch"
可以看到主要包含
s_ip : sentinel自己 IP地址
s_port : sentinel自己端口号
s_runid : sentinel自己的运行ID
s_epoch : sentinel当前的配置纪元
m_name, m_ip, m_port, m_epoch : 当前监控服务器的名称（主或者从）、IP地址、端口号、当前配置纪元
这个消息，也会被其他订阅该通道的sentinel收到
sentinel在接收到订阅消息后（就是上文中自己与别的sentinel，publish的消息），首先过滤掉自己发，然后接收别人的消息，就能获取监听改主服务器的所有sentinel节点
（8）通过上一步，sentinel能够感知到其他监控主服务器的sentinel节点，然后和其他sentinel建立连接，最终，所有监视主服务器的sentinel节点组成了一个相关连接的网络！
sentinel会默认每1s向自己所建立连接的服务器发送PING命令，这些服务器包括（监视master的其他sentinel，master、salve服务器），根据收到的返回值，来确定目标服务器的状态
常见返回值：+PONG、-LOADING、-MASTERDOWN，含义在此处先不关注
判定条件：目标服务器在一定的时间内（配置文件字段：down-after-milliseconds的值），一直返回“失败”
对失败的定义：
（1）目标服务器没有在规定时间内返回（该时间可配置）
（2）目标服务器返回了上述三种返回值之外的值
确定一个目标服务器失败之后，会在sentinel自己的实例表中记录该实例的状态，用：
SRI_S_DOWN表示，S=subjective客观
注：一个master服务器会被多个sentinel监控，多个sentinel可能设置了不同的
down-after-milliseconds
和我们设想的一样，单一的sentinel并不能决定目标master服务器的生死存亡，会拿着自己实例表里的“客观”下线的服务器地址和端口，去向同样监控这台服务器的sentinel询问，看看“别人”这个服务器到底下线没？ 当能够从别的sentinel那里询问到“足够数量”的已下线（客观下线或者主观下线）结果后，sentinel就可以判断目标服务器真的下线了，就可以执行故障转移了。
（1）sentinel发送命令is-master-down-by-addr
SENTINEL is-master-down-by-addr ip port current_epoch runid
发送的目标：监控master服务器的其他sentinel
参数解析：ip、port=自己监控的master服务器的IP，端口，current_epoch=源sentinel当前的配置纪元，runid=源sentinel的唯一标识ID
（2）sentinel对命令is-master-dowm-by-addr的回复
1) down_state ：下线的状态，0-未下线，1-已下线
2) leader_runid ：当前sentinel的局部leader，为 “*” 时表示没有leader
3) leader_epoch ：当前sentinel的局部leader的配置纪元，当没有leader时，该项为0
（3）sentinel收到命令is-master-down-by-addr的回复后
sentinel收到足够数量（可配置）的“已下线”回复（即down_state=1），就会在自己的实例表里将对应的master服务器状态（flags）设置为 SRI_O_DOWN，O=Objective。
监控同一个master服务器的sentinel，对客观下线的条件可以不一致，即收到多少已下线回复才认定客观下线，可以不尽相同。
由于监控同一个master服务器的sentinel有很多，并不能决定是哪个sentinel去执行故障转移，所以需要多个sentinel进行选leader头结点。
具体步骤：
(1)sentinel通过向其他sentinel节点发送is-master-down-by-addr命令，已经可以判断当前master服务器是否客观下线
（2）已经判断master服务器客观下线的sentinel，再次向其他节点发送
is-master-down-by-addr命令，携带自己的runId和配置纪元
这里再复习一遍命令 ：
sentinel is-master-down-by-addr ip,port,cur_epoch,runid
（3）目标sentinel收到源sentinel的 is-master…命令之后，执行以下判断
1判断epoch和自己的纪元是否相等，不相等直接舍弃这条命令
2判断自己的配置表里是否有局部leader，没有的话，将源sentinel的runid设置为自己的局部了leader
如果已经有了局部leader，那么会返回自己的局部leader的信息
3对源sentinel的is-master-down-by-addr命令进行回复
示例：
源sentinel向目标sentinel发送命令，
SENTINEL is-master-down-by-addr 127.0.0.1 8080 0 11522852334a
源sentinel收到命令的回复
1
11522852334a
0
表示有一个sentinel将自己成功设置成为leader（需要把返回的runid和自己的runid比对）
4当过半的sentinel将自己成功设置为局部leader，标识选主成功，如果在一段时间内没有收到过半的成功数，那么会进行下一轮命令的发送，epoch递增+1
例如，共有10个sentinel监视同一个master服务器，其中一个sentinel必须收到10/2+1=6个及以上的成功数，才能认为自己成功当选leader
（1）筛选master节点的备胎（即就是哪些slave节点可以成为新的master）
选择master节点备胎就一个要求，数据尽量完整，状态尽量好
1删除，客观下线或者主观下线的slave服务器
2删除，在最近5s没有回复过头sentinel节点的INFO命令的slave服务器
剩下的slave服务器，根据优先级进行排序，遇到优先级一样的，再根据偏移量排序（目的是筛选出和master服务器数据较同步的slave服务器）。再遇到偏移量一样的，继续根据runid排序，找出runid最小的（没有什么依据，只是个排序），至此，可以作为master的slave服务器就筛选好了。
（2）slave服务器升级为master
头sentinel向步骤（1）中筛选出来的slave服务器发送slaveof_no_one，发送完该转移命令。之后，头sentinel每秒一次的频率向上述slave服务器发送INFO命令，观察INFO命令返回的role字段，看是否变为master，变为master表示成功升级为master服务器。
（3）修改原slave服务器列表的复制/同步目标
头sentinel向原slave服务器列表发送命令：
slave of 127.0.0.1:8080，修改slave的复制目标
（4）修改已下线的master服务器为新master的slave节点
头sentinel保持对已下线master的监控，当已下线master重新上线（对PING命令有回复），就对他发送slave of 127.0.0.1命令，让其成为slave。
至此，故障转移全部结束。
Redis中的Sentinel机制
Redis的Sentinel文档
概述：Redis的Sentinel系统用于管理多个Redis服务器，该系统执行以下三个任务：
如何使用？
启动Sentinel
对于 redis-sentinel 程序，你可以用一下命令来启动Sentinel系统：
对于 redis-server 程序，你可以用下面的命令来启动一个运行在Sentinel模式下的Redis服务器
两种方式都可以启动一个sentinel实例，启动sentinel实例必须指定相应的配置文件，系统会使用配置文件来保存sentinel的当前状态，并在Sentinel重启时通过载入配置文件来进行状态还原。
注意：如果启动Sentinel时没有指定相应的配置文件，或者指定的配置文件不可用（not writabel），那么Sentinel会拒绝启动。
如何配置Sentinel？
Redis 源码中包含了一个名为 sentinel.conf 的文件， 这个文件是一个带有详细注释的 Sentinel 配置文件示例。
运行一个 Sentinel 所需的最少配置如下所示：
解读一下***条指令的意思：
其他选项的基本格式如下
学到这里我们进行实操一下，感受一下哨兵的威力！
我们先在test目录下，新建三个配置文件：26379.conf、26380.conf、26381.conf（Sentinel服务器端口号默认是在redis服务器前拼个2），用 vi 命令创建这三个配置文件，然后我们在配置文件中写入一些简单的配置：
端口号：26379，哨兵名称：mymaster，主机地址：127.0.0.1，监控的redis端口号：6379，必须要2台从Sentinel服务器同意才会切换master，并进行故障迁移。（注意，这三个配置文件监控的redis服务器端口都是6379）
用相同的方法，创建了另外两个sentinel配置文件
我们先启动一个6379作为master
再启动6380、6381，作为两个slave
接下来正菜上场了！启动Sentinel！
可以发现，有两个slave正在跟随master，我们只要拿哨兵监控master，就可以看到有几个slave
我们继续启动，再接着启动两个Sentinel服务器
现在我们做一个小实验：如果我们将master服务器（6379）关闭，两个slave之间会发生什么？
当把master关闭之后，两个slave直接会有一段时间提示主服务器拒绝访问：
而哨兵开始也没有立马进行选举投票，选出新master，因为redis选举默认配的时间是有些长的，要过一点时间才开始选举投票，经过重新选举之后，sentinel选择了6381作为新的master。
那既然6381作为新秀，它应该有了很大的指导权，我们现在看看：
我们可以看到，在6381中设置的数据，确实在6380中可以查的到！说明6380在跟随6381，说明哨兵自动帮我们实现了故障转移。
我们再查看一下配置文件，看看有何变化？
可以发现，和原来我们写进去的2句配置完全不一样了，也就是说哨兵会自己改动配置文件。现在的master是6381。
接下来探讨一个问题：哨兵是如何发现其他哨兵的？
答案是：发布订阅机制。活着的master会去查看slave是谁，然后会去订阅其他的slave
我们可以用 psubscribe 去查看相关的发布订阅情况
Sentinel（哨兵）
Redis主从复制模式下，一旦主节点（主服务器）由于故障不能提供服务，需要人工将节点晋升为主节点，同时还要通知应用方更新主节点的地址，然而应用方无法及时感知到主节点的变化，必然会造成一定的写数据丢失和读数据错误，所以这是在大多数情况是无法接受的。所以Redis提供了一种高可用的解决方法——哨兵。
Sentinel是Redis的高可用解决方案： 由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态下时，自动将下线主服务器属下的某个从服务器升级为主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。如果下线的主服务器重新连接上线的话，它会被Sentinel系统降级为新主服务器的从服务器。 而这些过程完全是自动的，不需要人工介。
下面介绍Sentinel系统的具体工作过程。
Sentinel只是一个运行在特殊模式下的Redis服务器，其本身就是独立的Redis节点，只不过它不存储数据，只支持部分命令。
Sentinel会读入用户指定的配置文件，为每个要被监视的主服务器创建相应的实例结构保存在Sentinel状态（服务器初始化的一个sentinel结构，用于保存服务器中所有和Sentinel功能有关的状态）的masters属性中。并创建连向主服务器的网络连接，Sentinel将成为主服务器的客户端，并从命令回复中获取相关信息。
对于每个被Sentinel监视的主服务器来说，Sentinel会创建两个连向主服务器的异步网络连接：
1) 一个是命令连接，这个连接专门用于向主服务器的网络连接，并接受命令。
2) 另一个是订阅连接，这个连接专门用于订阅主服务器的_sentinel_:hello频道。
Sentinel默认每10秒一次的频率，通过命令连接向被 监视的主服务器发送 INFO 命令，并通过 INFO 命令的回复来获取主服务器以下的信息：
(1) 服务器本身的信息，包括运行ID以及服务器的角色（role）；
(2) 主服务属下的所有从服务器信息，包括从服务器的IP地址，端口号。 根据这些IP和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器。
Sentinel根据这些获取的信息对主服务的实例结构进行更新。
对于上图，Sentinel将分别为3个从服务器创建各自的实例结构，并将这些实例结构保存主服务器实例结构的slaves属性里。
当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构外，Sentinel还会为创建连接到从服务器的命令连接和订阅连接。
在创建命令连接之后， Sentinel在默认情况下， 会以每10秒 一次的频率通过命令连接向从服务器发送 INFO 命令，并获取从服务器的回复信息，包括从服务器运行ID、从服务器的角色，主服务器的IP和端口、从服务的优先级等。根据这些信息对从服务器实例结构进行更新。
在默认情况下，Sentinel会以每2秒一次的频率，通过命令连接向所有被监听的主服务器和从服务器的_sentinel_ hello频道发送一条消息。消息的信息包括Sentinel本身的信息和对主服务器判断的信息。
当Sentinel与一个主服务器或者从服务器建立起订阅连接之后， Sentinel就会通过订阅连接， 向服务器发送以下命令：SUBSCRIBE _sentinel_:hello 。
Sentinel对_sentinel_:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。
这也就是说， 对于每个与Sentinel连接的服务器， Sentinel既通过命令连接向服务器的 sentinel_:hello频道发送信息， 又通过订阅连接从服务器的 sentinel :hello 频道接收信息。
对于监视同一个服务器的多个Sentinel 来说， 一个Sentinel发送的信息会被其他 Sentinel接收到， 这些信息会被用于更新其他Sentinel对发送信息Sentinel的认知 ，也会被用于更新其他Sentinel对被监视服务器的认知。
举个例子， 假设现在有sentinel1、sentinel 2、sentinel 3三个Sentinel在监视同一个服务器， 那么当sentinel1向服务器的_sentinel_:hello频道发送一条信息时，所有订阅了_sentinel_:hello频道的Sentinel（包括sentinel1自己在内）都会收到这条信息。
当一个Sentinel从_sentinel_:hello频道收到一条信息时，Sentinel会对这条信息进行分析，提取出信息中的Sentinel IP地址、端口号、Sentinel运行ID等参数，并作以下检查：
**如果信息中记录的Sentinel运行ID和接收信息中Sentinel的运行ID 相同，说明这条信息是Sentinel自己发送的，Sentinel将丢弃这条信息，不做进一步处理。
**如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID不相同，那么说明这条信息是监视同一个服务器的其他Sentinel发来的， 接收信息的Sentinel 将根据信息中的各个参数， 对相应主服务器的实例结构进行更新。
这里的更新包括：主服务sentinels属性的更新和创建连向其他Sentinel命令连接
(1) Sentinel为主服务器创建的实例结构中的sentinels属性保存了除Sentinel本身之外，所有同样监视这个主服务器的其他Sentinel的资料。当一个Sentinel接收到其他Sentinel发来的信息时（我们称呼发送信息的Sentinel为源Sentinel, 接收信息的Sentinel为目标Sentinel），根据信息中提取出主服务器参数，目标Sentinel会在自己的Sentinel状态的masters字典中查找相应的主服务器实例结构， 然后根据提取出的Sentinel参数，检查主服务器实例结构的sentinels中，源Sentinel的实例结构是否存在：
因为一个Sentinel可以通过分析接收到的频道信息来获取其他Sentinel的存在，并通过发送频道信息让其他Sentinel知道自己的存在，所以用户在使用Sentinel时不需要提供各个Sentinel的地址信息，监视同一个主服务器的多个Sentinel可以自动发现对方。
(2) 创建连向其他Sentinel命令连接
当Sentinel通过频道信息发现一个新的Sentinel时， 它不仅会为新Sentinel在sentinels中创建相应的实例结构， 还会创建一个连向新Sentinel的命令连接， 而新Sentinel也同样会创建连向这个Sentinel的命令连接， 最终监视同一主服务器的多个Sentinel将形成相互连接的网络。
在默认情况下，Sentinel会以 每秒一次 的频率向所有与它创建了命令的连接实例 （包括主服务器、从服务器、其他Sentinel在内），发送PING命令 ，并通过实例返回PING命令的回复判断实例是否在线，如果在规定的时间内，连续向Sentinel返回无效的回复（除了+PONG、-LOADING、-MASTERDOWN之外的回复），那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来标识这个实例已经进入了 主观下线状态 。
当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了， 它会向同样监视这一主服务器的其他Sentinel进行询问， 看它们是否也认为主服务器已经进人了下线状态（可以是主观下线或者客观下线）。 当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后， Sentinel就会将从服务器判定为客观下线， Sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开，标识主服务器已经进入了客观下线状态。
当一个主服务器被判断为客观下线时，监视这个下线的主服务器的各个Sentinel会进行协商，选举出以个领头Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。
选举领头Sentinel规则和方法：
下面两幅图表示当三个Sentinel发现主服务器已经进入客观下线状态后，为了选举出领头Sentinel，三个Sentinel将再次向其他Sentinel发送SENTINEL is-master-down-by-addr命令要求其他Sentinel将自己设置为局部领头Sentinel。根据先到先得规则，如果某个Sentinel发送的命令比其他的快，并最终胜出领头Sentinel的选举，然后这个领头Sentinel就可以开始对服务器执行故障转移操作了。
在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤：
(1) 选出新的主服务器
故障转移的***步就是在已下线主服务器属下的所有从服务器中挑选出一个状态良好、数据完成整的从服务器，然后向这个从服务器发送slave no one 命令，将这个从服务器装换为主服务器。
下图展示在一次故障转移操作中，领头Sentinel向选中的从服务器server3发送 SLAVEOF no one 命令。
在发送 SLAVEOF no one命令之后，领头 Sentinel会以每秒一次的频率（平时是每10秒一次），向被升级的从服服务发送INFO命令，并观察命令回复中角色（role）信息，当被升级的从服务器的role由原来的slave变为master时，领头Sentinel就知道被选中的从服务器顺利升级为主服务器了。
(2) 修改从服务器的复制目标
当新的主服务器出现之后，领头Sentinel让已下线主服务器属下的所有从服务器去复制新的主服务器，这一动作可以通过向从服务器发送 SLAVE OF 命令来实现。
(3) 将旧的主服务器变为从服务器
故障转移操作最后要做的是， 将巳下线的主服务器设置为新的主服务器的从服务器。
当serverl1重新上线时，Sentinel就会向它发送 SLAVEOF 命令，让它成为server3的从服务器。
Redis的Sentinel实现主要包含以下几个方面： 三个定时任务、主观下线和客观下线检测、领头Sentinel的选举、故障转移。
(1) 定时任务
(2) 主观下线和客观下线检测
客观下线：当Sentinel将一个主服务器判断为主观下线后，为了确认这个主服务是否真的下线了，他会向同样监视这个主服务器的所有其他Sentinel进行询问，看它们是否也认为主服务器是否进入下线状态，如果有足够多数量的Sentinel认为主服务器进入下线状态时，Sentinel就会将主服务器判定为客观下线状态。
(3) 领头Sentinel的选举
在主服务器被判定为客观下线后，Sentinel之间会根据一定的规则选出一个领头Sentinel，故障转移的工作就是这个领头Sentinel来完成的。
(4) 故障转移
注：本文参考《Redis设计与实现》，如发现错误，请指正！
如何读sentinel
sentinel 英[ˈsentɪnl] 美[ˈsɛntənəl]
n. 岗哨，哨兵;
[例句]Is one of the goals of the Sentinel system.
解答频率的问题是“哨兵”系统的目标之一。
[其他] 复数：sentinels
Sentinel的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于sentinel key not foundh0007、Sentinel的信息别忘了在本站进行查找喔。