转载：http://blog.csdn.net/gqtcgq/article/details/50273431
哨兵
在一个典型的一主多从的Redis 系统中，从库在整个系统中起到了数据冗余备份和读写分离的作用。当主库遇到异常中断服务后，开发者可以通过手动的方式选择一个从库来升级为主库，以使得系统能继续提供服务。
然而整个过程相对麻烦且需要人工介入，难以实现自动化。为此，Redis 2.8中提供了“哨兵”工具来实现自动化的系统监控和故障恢复功能。
注意 Redis 2.6 版也提供了哨兵工具，但此时的哨兵是1.0版，存在非常多的问题，任何情况下都不应该使用这个版本的哨兵。本章介绍的哨兵都是Redis 2.8提供的哨兵
1：什么是哨兵
哨兵的作用就是监控 Redis系统的运行状况。它的功能包括：
a：监控主库和从库是否正常运行；
b：主库出现故障时自动将从库转换为主库；
哨兵是一个独立的进程，使用哨兵的一个典型架构如下图所示，其中虚线表示主从复制关系，实线表示哨兵的监控路径：
在一主多从的Redis系统中，可以使用多个哨兵进行监控，以保证系统足够稳健，此时，不仅哨兵会监控主库和从库，哨兵之间也会互相监控。如下图所示：
2：实践
在理解哨兵的原理前，首先实际使用一下哨兵，来了解哨兵是如何工作的。为了简单起见，在同一个主机上建立3个Redis实例，包括一个主库和两个从库。主库的端口为6379，两个从库的端口分别为6380和6381。使用Redis-cli获取复制状态，以保证复制配置正确。首先是主库：
可见其连接了两个从库。然后用同样的方法查看两个从库的配置：
接下来开始配置哨兵。建立一个配置文件sentinel.conf，内容为：
其中mymaster表示要监控的主库的名字，可以自己定义。这个名字必须仅由大小写字母、数字和”.-_”这3个字符组成。后两个参数表示主库的IP地址和端口号。最后的1表示最低通过票数，后面会介绍。
接下来启动 Sentinel进程，并将上述配置文件的路径传递给哨兵：
配置哨兵监控一个系统时，只需要配置其监控主库即可，哨兵会自动发现所有复制该主库的从库，具体原理后面会详细介绍。
启动哨兵后，哨兵输出如下内容：
其中”+slave”表示新发现了从库，可见哨兵成功地发现了两个从库。
现在哨兵已经在监控这3个Redis实例了，这时将主库关闭（杀死进程或使用 shutdown 命令），等待指定时间后（可配置，默认为 30 秒），哨兵会输出如下内容：
其中”+sdown”表示哨兵主观认为主库停止服务了，而”+odown”则表示哨兵客观认为主库停止服务了，关于主观和客观的区别后文会详细介绍。此时哨兵开始执行故障恢复，即挑选一个从库，将其升级为主库。输出如下内容：
“+try-failover”表示哨兵开始进行故障恢复，”+failover-end”表示哨兵完成故障恢复，期间涉及的内容比较复杂，包括领头哨兵的选举、备选从库的选择等，放到后面介绍，此处只需要关注最后4条输出。”+switch-master”表示主库从6379端口迁移到6381端口，即6381端口的从库升级为主库，两个”+slave”则列出了新主库的两个从库，端口分别为6380和6379。其中6379就是之前停止服务的主库。
哨兵并没有彻底清除停止服务实例的信息，这是因为停止服务的实例可能会在之后的某个时间恢复服务，这时哨兵会让其重新加入进来，所以当实例停止服务后，哨兵会更新该实例的信息，使得当其重新加入后可以按照当前信息继续对外提供服务。此例中6379端口的主库实例停止服务了，而6381 端口的从库已经升级为主库，当6379端口的实例恢复服务后，会转变为6381端口实例的从库来运行，所以哨兵将6379端口实例的信息修改成了 6381端口实例的从库。
故障恢复完成后，可以使用”info replication”重新检查6380和6381两个端口上的实例的复制信息：
可见6381端口上的实例已经确实升级为主库了，同时6380端口上的实例是其从库。整个故障恢复过程就此完成。
如果此时将6379端口上的实例重新启动，会发生什么情况呢？首先哨兵会监控到这一变化，并输出：
“-sdown”表示实例6379已经恢复了服务（与+sdown相反），同时”+convert-to-slave”表示将6379端口的实例设置为6381端口实例的从库。这时使用”info replication”查看6379端口实例的复制信息为：
同时6381端口实例的复制信息为：
正如预期一样，6381端口实例的从库变为了两个，6379成功恢复服务。
3：实现原理
哨兵进程启动时读取配置文件的内容，通过如下的配置找出需要监控的主库：
master-name 是主库的名字，因为考虑到故障恢复后当前监控的系统的主库的地址和端口会产生变化，所以哨兵提供了命令可以通过主库的名字获取当前系统的主库的IP地址和端口号。
ip表示当前系统中主库的地址，redis-port则表示端口号。
quorum表示执行故障恢复操作前，至少需要几个哨兵节点同意，后文会详细介绍。
一个哨兵节点可以同时监控多个Redis主从系统，只需要提供多个”sentinel monitor”配置即可，例如：
多个哨兵节点也可以同时监控同一个Redis 主从系统，从而形成网状结构。
配置文件中还可以定义其他监控相关的参数，每个配置选项都包含主库的名字使得监控不同主库时可以使用不同的配置参数。例如：
上面的两行配置分别配置了mymaster 和othermaster的”down-after-milliseconds”选项，分别为60000和10000。
哨兵启动后，会与要监控的主库建立两条连接，这两个连接的建立方式与普通的Redis客户端无异。其中一条用来订阅该主库的”__sentinel__:hello”频道，以获取其他同样监控该数据库的哨兵节点的信息。
另外哨兵也需要定期向主库发送info等命令来获取主库本身的信息，之前介绍过当客户端的连接进入订阅模式时就不能再执行其他命令了，所以这时哨兵会使用另外一条连接来发送这些命令。
和主库的连接建立完成后，哨兵会定时执行下面3个操作。
a：每10秒向主库和从库发送info命令；
b：每2秒向主库和从库的”__sentinel__:hello”频道发送自己的信息，也就是说哨兵不但订阅了该频道，而且还会向该频道发布信息，以使其他哨兵得到自己的信息；
c：每1秒向主库、从库和其他哨兵节点发送ping命令。
这3个操作贯穿哨兵进程的整个生命周期中，非常重要。下面分别详细介绍。
首先，发送info命令使哨兵可以获得当前数据库的相关信息（包括运行ID、复制信息等）从而实现新节点的自动发现。配置哨兵监控 Redis 主从系统时只需要指定主库的信息即可，因为哨兵正是借助info命令来获取所有复制该主库的从库信息的。
启动后，哨兵向主库发送info命令得到从库列表，而后对每个从库同样建立两个连接，两个连接的作用和与主库建立的两个连接完全一致。在此之后，哨兵会每 10 秒定时向已知的所有主从库发送info命令来获取更新信息，并进行相应操作。比如对新增的从库建立连接并加入监控列表，对主从库的角色变化（由故障恢复操作引起）进行信息更新等。
接下来哨兵向主从库的”__sentinel__:hello”频道发送信息来与同样监控该数据库的哨兵分享自己的信息。发送的消息内容为：
<哨兵的地址>,<哨兵的端口>, <哨兵运行ID>, <哨兵的配置版本>, <主库的名字>, <主库的地址>, <主库的端口>, <主库的配置版本>
哨兵会订阅每个其监控的数据库的”__sentinel__:hello”频道，所以当其他哨兵收到消息后，会判断发消息的哨兵是不是新发现的哨兵。如果是，则将其加入已发现的哨兵列表中并创建一个到其的连接（与数据库不同，哨兵与哨兵之间只会创建一条连接用来发送ping命令，而不需要创建另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可实现自动发现其他哨兵）。
同时，哨兵会判断信息中主库的配置版本，如果该版本比当前记录的主库的版本高，则更新主库的数据。配置版本的作用会在后面详细介绍。
实现了自动发现从库和其他哨兵节点后，哨兵要做的就是定时监控这些数据库和节点有没有停止服务。这是通过每隔一定时间向这些节点发送ping命令实现的。
发送ping的时间间隔与”down-after-milliseconds”选项有关，最长间隔为1秒。当”down-after-milliseconds”的值小于1秒时，哨兵会每隔”down-after-milliseconds”指定的时间发送一次ping命令，当down-after-milliseconds的值大于1秒时，哨兵会每隔1秒发送一次ping命令。
如果超过”down-after-milliseconds”指定时间后，被ping的节点仍未回复，则哨兵认为其主观下线(subjectively down)。主观下线表示，从当前的哨兵进程看来，该节点已经下线。如果该节点是主库，则哨兵会进一步判断是否需要对其进行故障恢复：哨兵发送”SENTINEL is-master-down-by-addr”命令询问其他哨兵节点以了解他们是否也认为该主库主观下线，如 果达到指定数量时，哨兵会认为其客观下线(objectively down)，并选举领头的哨兵节点发起故障恢复。这个指定数量即为前文介绍的”quorum”参数。例如，下面的配置：
该配置表示只有当至少两个哨兵节点（包括当前节点）认为该主库主观下线时，当前哨兵节点才会认为该主库客观下线。
接下来开始进行领头哨兵的选举。虽然当前哨兵节点发现了主库客观下线，需要故障恢复，但是故障恢复需要由领头的哨兵来完成，这样可以保证同一时间只有一个哨兵节点来执行故障恢复。选举领头哨兵的过程使用了 Raft算法，具体过程如下。
a：发现主库客观下线的哨兵节点（下面称作A）向每个哨兵节点发送命令，要求对方选自己成为领头哨兵。
b：如果目标哨兵节点没有选过其他人，则会同意将A设置成领头哨兵。
c： 如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则A成功成为领头哨兵。
d：若有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。
具体过程可以参考Raft算法的过程http://raftconsensus.github.io/。因为要成为领头哨兵必须有超过半数的哨兵节点支持，所以每次选举最多只会选出一个领头哨兵。
选出领头哨兵后，领头哨兵开始对主库进行故障恢复。故障恢复的过程相对简单，具体如下：
首先领头哨兵将从停止服务的主库的从库中挑选一个来充当新的主库。挑选的依据如下：
a：所有在线的从库中，选择优先级最高的从库。优先级可以通过”slave-priority”选项来设置；
b：如果有多个最高优先级的从库，则复制的命令偏移量越大（即复制越完整）越优先；
c：如果以上条件都一样，则选择运行ID较小的从库。
选出一个从库后，领头哨兵将向从库发送”slaveof no one”命令，使其升级为主库。而后领头哨兵向其他从库发送slaveof命令来使其成为新主库的从库。
最后一步则是更新内部的记录，将已经停止服务的，旧的主库更新为新的主库的从库，使得当其恢复服务时自动以从库的身份继续服务。
4：哨兵的部署
哨兵以独立进程的方式对一个主从系统进行监控，监控的效果好坏取决于哨兵的视角是否有代表性。如果一个主从系统中配置的哨兵较少，哨兵对整个系统的判断的可靠性就会降低。极端情况下，当只有一个哨兵时，哨兵本身就可能会发生单点故障。整体来讲，相对稳妥的哨兵部署方案是使得哨兵的视角尽可能地与每个节点的视角一致，即：
a：为每个节点（无论是主库还是从库）部署一个哨兵；
b：使每个哨兵与其对应的节点的网络环境相同或相近；
这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。举个例子：当网络分区后，如果哨兵认为某个分区是主要分区，即意味着从每个节点观察，该分区均为主分区。
同时设置 quorum 的值为 N/2 + 1（其中N为哨兵节点数量），这样使得只有当大部分哨兵节点同意后才会进行故障恢复。
当系统中的节点较多时，考虑到每个哨兵都会和系统中的所有节点建立连接，为每个节点分配一个哨兵会产生较多连接，尤其是当进行客户端分片时使用多个哨兵节点监控多个主库，会因为 Redis 不支持连接复用而产生大量冗余连接，具体可以见此issue： https://github.com/antirez/redis/issues/2257；同时如果Redis节点负载较高，会在一定程度上影响其对哨兵的回复以及与其同机的哨兵与其他节点的通信。所以配置哨兵时还需要根据实际的生产环境情况进行选择。
216
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
