美团二面为什么Redis会有哨兵？

　　话不多说，发车发车！
　　提纲为什么要有哨兵机制？
　　在Redis的主从架构中，由于主从模式是读写分离的，如果主节点（master）挂了，那么将没有主节点来服务客户端的写操作请求，也没有主节点给从节点（slave）进行数据同步了。
　　主节点挂了
　　这时如果要恢复服务的话，需要人工介入，选择一个从节点切换为主节点，然后让其他从节点指向新的主节点，同时还需要通知上游那些连接Redis主节点的客户端，将其配置中的主节点IP地址更新为新主节点的IP地址。
　　这样也不太智能了，要是有一个节点能监控主节点的状态，当发现主节点挂了，它自动将一个从节点切换为主节点的话，那么可以节省我们很多事情啊！
　　Redis在2。8版本以后提供的哨兵（Sentinel）机制，它的作用是实现主从节点故障转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。哨兵机制是如何工作的？
　　哨兵其实是一个运行在特殊模式下的Redis进程，所以它也是一个节点。从哨兵这个名字也可以看得出来，它相当于是观察者节点，观察的对象是主从节点。
　　当然，它不仅仅是观察那么简单，在它观察到有异常的状况下，会做出一些动作，来修复异常状态。
　　哨兵节点主要负责三件事情：监控、选主、通知。
　　哨兵的职责
　　所以，我们重点要学习这三件事情：哨兵节点是如何监控节点的？又是如何判断主节点是否真的故障了？根据什么规则选择一个从节点切换为主节点？怎么把新主节点的相关信息通知给从节点和客户端呢？如何判断主节点真的故障了？
　　哨兵会周期性地给所有主从节点发送PING命令，当主从节点收到PING命令后，会发送一个响应命令给哨兵，这样就可以判断它们是否在正常运行。
　　哨兵监控主从节点
　　如果主节点或者从节点没有在规定的时间内响应哨兵的PING命令，哨兵就会将它们标记为主观下线。这个规定的时间是配置项downaftermilliseconds参数设定的，单位是毫秒。
　　主观下线？难道还有客观下线？
　　是的没错，客观下线只适用于主节点。
　　之所以针对主节点设计主观下线和客观下线两个状态，是因为有可能主节点其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的PING命令。
　　所以，为了减少误判的情况，哨兵在部署的时候不会只部署一个节点，而是用多个节点部署成哨兵集群（最少需要三台机器来部署哨兵集群），通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
　　具体是怎么判定主节点为客观下线的呢？
　　当一个哨兵判断主节点为主观下线后，就会向其他哨兵发起命令，其他哨兵收到这个命令后，就会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。
　　当这个哨兵的赞同票数达到哨兵配置文件中的quorum配置项设定的值后，这时主节点就会被该哨兵标记为客观下线。
　　例如，现在有3个哨兵，quorum配置的是2，那么一个哨兵需要2张赞成票，就可以标记主节点为客观下线了。这2张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。
　　PS：quorum的值一般设置为哨兵个数的二分之一加1，例如3个哨兵就设置2。
　　哨兵判断完主节点客观下线后，哨兵就要开始在多个从节点中，选出一个从节点来做新主节点。如何选新主节点？
　　那么多从节点，到底选择哪个从节点作为新主节点的？
　　随机的方式好吗？随机的方式，实现起来很简单，但是如果选到一个网络状态不好的从节点作为新主节点，那么可能在将来不久又要做一次主从故障迁移。
　　所以，我们首先要把网络状态不好的从节点给过滤掉。首先把已经下线的从节点过滤掉，然后把以往网络连接状态不好的从节点也给过滤掉。
　　怎么判断从节点之前的网络连接状态不好呢？
　　Redis有个叫downaftermilliseconds10配置项，其downaftermilliseconds是主从节点断连的最大连接超时时间。如果在downaftermilliseconds毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了10次，就说明这个从节点的网络状况不好，不适合作为新主节点。
　　至此，我们就把网络状态不好的从节点过滤掉了，接下来要对所有从节点进行三轮考察：优先级、复制进度、ID号。在进行每一轮考察的时候，哪个从节点优先胜出，就选择其作为新主节点。第一轮考察：哨兵首先会根据从节点的优先级来进行排序，优先级越小排名越靠前，第二轮考察：如果优先级相同，则查看复制的下标，哪个从主节点接收的复制数据多，哪个就靠前。第三轮考察：如果优先级和下标都相同，就选择从节点ID较小的那个。第一轮考察：优先级最高的从节点胜出
　　Redis有个叫slavepriority配置项，可以给从节点设置优先级。
　　每一台从节点的服务器配置不一定是相同的，我们可以根据服务器性能配置来设置从节点的优先级。
　　比如，如果A从节点的物理内存是所有从节点中最大的，那么我们可以把A从节点的优先级设置成最高。这样当哨兵进行第一轮考虑的时候，优先级最高的A从节点就会优先胜出，于是就会成为新主节点。第二轮考察：复制进度最靠前的从节点胜出
　　如果在第一轮考察中，发现优先级最高的从节点有两个，那么就会进行第二轮考察，比较两个从节点哪个复制进度。
　　什么是复制进度？主从架构中，主节点会将写操作同步给从节点，在这个过程中，主节点会用masterreploffset记录当前的最新写操作在replbacklogbuffer中的位置，而从节点会用slavereploffset这个值记录当前的复制进度。
　　如果某个从节点的slavereploffset最接近masterreploffset，说明它的复制进度是最靠前的，于是就可以将它选为新主节点。第三轮考察：ID号小的从节点胜出
　　如果在第二轮考察中，发现有两个从节点优先级和复制进度都是一样的，那么就会进行第三轮考察，比较两个从节点的ID号，ID号小的从节点胜出。
　　什么是ID号？每个从节点都有一个编号，这个编号就是ID号，是用来唯一标识从节点的。
　　到这里，选主的事情终于结束了。简单给大家总结下：过滤掉已经离线的从节点；过滤掉历史网络连接状态不好的从节点；将剩下的从节点，进行三轮考察：优先级、复制进度、ID号。在每一轮考察过程中，如果找到了一个胜出的从节点，就将其作为新主节点。由哪个哨兵进行主从故障转移？
　　前面说过，为了更加客观的判断主节点故障了，一般不会只由单个哨兵的检测结果来判断，而是多个哨兵一起判断，这样可以减少误判概率，所以哨兵是以哨兵集群的方式存在的。
　　那在选定了即将作为主节点的从节后，由哨兵集群中的哪个节点进行主从故障转移呢？
　　所以这时候，还需要在哨兵集群中选出一个leeder，让Leader来执行主从切换。
　　选举leeder的过程其实是一个投票的过程，在投票开始前，肯定得有个候选者。
　　那谁来作为候选者呢？
　　哪个哨兵节点判断主节点为客观下线，这个哨兵节点就是候选者，所谓的候选者就是想当Leader的哨兵。
　　举个例子，假设有三个哨兵。当哨兵A先判断到主节点主观下线后，就会给其他实例发送ismasterdownbyaddr命令。接着，其他哨兵会根据自己和主节点的网络连接情况，做出赞成投票或者拒绝投票的响应。
　　当哨兵A收到赞成票数达到哨兵配置文件中的quorum配置项设定的值后，就会将主节点标记为客观下线，此时的哨兵A就是一个Leader候选者。
　　候选者如何选举成为Leader？
　　候选者会向其他哨兵发送命令，表明希望成为Leader来执行主从切换，并让所有其他哨兵对它进行投票。
　　每个哨兵只有一次投票机会，如果用完后就不能参与投票了，可以投给自己或投给别人，但是只有候选者才能把票投给自己。
　　那么在投票过程中，任何一个候选者，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的quorum值。
　　举个例子，假设哨兵节点有3个，quorum设置为2，那么任何一个想成为Leader的哨兵只要拿到2张赞成票，就可以选举成功了。如果没有满足条件，就需要重新进行选举。
　　这时候有的同学就会问了，如果某个时间点，刚好有两个哨兵节点判断到主节点为客观下线，那这时不就有两个候选者了？这时该如何决定谁是Leader呢？
　　每位候选者都会先给自己投一票，然后向其他哨兵发起投票请求。如果投票者先收到候选者A的投票请求，就会先投票给它，如果投票者用完投票机会后，收到候选者B的投票请求后，就会拒绝投票。这时，候选者A先满足了上面的那两个条件，所以候选者A就会被选举为Leader。
　　为什么哨兵节点至少要有3个？
　　如果哨兵集群中只有2个哨兵节点，此时如果一个哨兵想要成功成为Leader，必须获得2票，而不是1票。
　　所以，如果哨兵集群中有个哨兵挂掉了，那么就只剩一个哨兵了，如果这个哨兵想要成为Leader，这时票数就没办法达到2票，就无法成功成为Leader，这时是无法进行主从节点切换的。
　　因此，通常我们至少会配置3个哨兵节点。这时，如果哨兵集群中有个哨兵挂掉了，那么还剩下两个个哨兵，如果这个哨兵想要成为Leader，这时还是有机会达到2票的，所以还是可以选举成功的，不会导致无法进行主从节点切换。
　　当然，你要问，如果3个哨兵节点，挂了2个怎么办？这个时候得人为介入了，或者增加多一点哨兵节点。
　　再说一个问题，Redis1主4从，5个哨兵，quorum设置为3，如果2个哨兵故障，当主节点宕机时，哨兵能否判断主节点客观下线？能否自动切换？哨兵集群可以判定主节点客观下线。哨兵集群还剩下3个哨兵，当一个哨兵判断主节点主观下线后，询问另外2个哨兵后，有可能能拿到3张赞同票，这时就达到了quorum的值，因此，哨兵集群可以判定主节点为客观下线。哨兵集群可以完成主从切换。当有个哨兵标记主节点为客观下线后，就会进行选举Leader的过程，因为此时哨兵集群还剩下3个哨兵，那么还是可以拿到半数以上（5213）的票，而且也达到了quorum值，满足了选举Leader的两个条件，所以就能选举成功，因此哨兵集群可以完成主从切换。
　　如果quorum设置为2的话，并且有3个哨兵故障。此时哨兵集群还是可以判定主节点为客观下线，但是哨兵不能完成主从切换了，大家可以自己推演下。
　　quorum的值建议设置为哨兵个数的二分之一加1，例如3个哨兵就设置2，5个哨兵设置为3，而且哨兵节点的数量应该是奇数。如何通知客户端新主节点的信息？
　　经过前面一系列的操作后，哨兵集群终于完成了主从故障迁移，那么新主节点的信息要如何通知给客户端呢？
　　这主要通过Redis的发布者订阅者机制来实现的。每个哨兵节点提供发布者订阅者机制，客户端可以从哨兵订阅消息。
　　比如，客户端订阅了主从切换的事件，当哨兵把新主节点选择出来后，就会发布新主节点的IP地址和端口信息，这个时候客户端就可以收到这条信息，然后用这里面的新主节点的IP地址和端口进行通信了。哨兵集群是如何组成的？
　　前面提到了Redis的发布者订阅者机制，那就不得不提一下哨兵集群的组成方式，因为它也用到了这个技术。
　　在我第一次搭建哨兵集群的时候，当时觉得很诧异。因为在配置哨兵的信息时，竟然只需要填下面这几个参数，设置主节点名字、主节点的IP地址和端口号以及quorum值。sentinelmonitormasternameipredisportquorum
　　不需要填其他哨兵节点的信息，我就好奇它们是如何感知对方的，又是如何组成哨兵集群的？
　　后面才了解到，哨兵节点之间是通过Redis的发布者订阅者机制来相互发现的。
　　在主从集群中，主节点上有一个名为sentinel：hello的频道，不同哨兵就是通过它来相互发现，实现互相通信的。
　　在下图中，哨兵A把自己的IP地址和端口的信息发布到sentinel：hello频道上，哨兵B和C订阅了该频道。那么此时，哨兵B和C就可以从这个频道直接获取哨兵A的IP地址和端口号。然后，哨兵B、C可以和哨兵A建立网络连接。
　　通过这个方式，哨兵B和C也可以建立网络连接，这样一来，哨兵集群就形成了。
　　哨兵集群会对从节点的运行状态进行监控，那哨兵集群如何知道从节点的信息？
　　主节点知道所有从节点的信息，所以哨兵会向主节点发送INFO命令来获取所有从节点的信息。
　　如下图所示，哨兵B给主节点发送INFO命令，主节点接受到这个命令后，就会把从节点列表返回给哨兵。接着，哨兵就可以根据从节点列表中的连接信息，和每个从节点建立连接，并在这个连接上持续地对从节点进行监控。哨兵A和C可以通过相同的方法和从节点建立连接。
　　正式通过Redis的发布者订阅者机制，哨兵之间可以相互感知，然后组成集群，同时，哨兵又通过INFO命令，在主节点里获得了所有从节点连接信息，于是就能和从节点建立连接，并进行监控了。
　　参考资料：《Redis核心技术与实战》《Redis设计与实现》总结
　　Redis在2。8版本以后提供的哨兵（Sentinel）机制，它的作用是实现主从故障自动转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。
　　哨兵一般是以集群的方式部署，至少需要3个哨兵节点，哨兵集群主要负责三件事情：监控、选主、通知。
　　哨兵节点通过Redis的发布者订阅者机制，哨兵之间可以相互感知，相互连接，然后组成哨兵集群，同时哨兵又通过INFO命令，在主节点里获得了所有从节点连接信息，于是就能和从节点建立连接，并进行监控了。
　　哨兵集群会通过投票的方式判定主节点是否客观下线，如果判定主节点为客观下线，那么就会从所有的从节点中选择一个作为新主节点，选择的规则有以下步骤：过滤掉已经离线的从节点；过滤掉历史网络连接状态不好的从节点；将剩下的从节点，进行三轮考察：优先级、复制进度、ID号。在每一轮考察过程中，如果找到了一个胜出的从节点，就将其作为新主节点。
　　选择好从节点后，就需要从哨兵集群选择一个leader执行主从切换。选举leader的过程，也是一个投票的过程，任何一个想成为leader的哨兵节点，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的quorum值。
　　选举完leader哨兵节点后，就执行主从切换。完成主从切换后，通过Redis的发布者订阅者机制通知客户端新主节点的IP地址和端口。原文链接：https：mp。weixin。qq。comsHJHNq3MOSJDC0cPAFzIw
　　作者：小林coding
　　如果觉得本文对你有帮助，可以转发关注支持一下