Redis Sentinel机制与用法[转]

Redis Sentinel 机制与用法（一）

概述

Redis-sentinel是Redis实例的监控管理、通知和实例失效备援服务，是Redis集群的管理工具。在一般的分布式中心节点数据库中，Redis-sentinel的作用是中心节点的工作，监控各个其他节点的工作情况并且进行故障恢复，来提高集群的高可用性。

Redis-sentinel是Redis的作者antirez在今年6月份完成的，因为Redis实例在各个大公司的应用，每个公司都需要一个Redis集群的管理工具，被迫都自己写管理工具来管理Redis集群，antirez考虑到社区的急迫需要(详情)，花了几个星期写出了Redis-sentinel。

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

功能

它的主要功能有以下几点

• 监控：不时地监控redis是否按照预期良好地运行;
• 通知：如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
• 自动故障恢复：能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

首先Redis-sentinel要建立一个监控的master列表，然后针对master列表的每个master获取监控其的sentinels和slaves供以后故障恢复使用。

1、自动发现sentinel和slave

一个sentinel实例的监控master在配置文件中指定，如sentinel A在配置文件中指定管理的master ip:port列表，并且指定连接失败超时的时间和是否可以故障恢复等参数。这样，sentinel A就建立了监控的master列表。

sentinel A作为客户端建立对其监控master 1的pub/sub连接和命令传输连接，pub/sub连接的目的是通过消息传递来获取监控master 1的所有sentinels，具体方式是订阅”sentinel:hello”频道，并这个频道publish 自己的host信息，这样，所有监控master 1的sentinels都通过订阅master 1的“sentinel:hello”频道来获取其他sentinels的信息。sentinel A就建立了master 1的sentinels列表。
sentinel A还通过间断的info命令获取master 1的slaves列表，如果连接超时或者失败，就会进入故障处理的例程。

2、故障恢复准备

Redis-sentinel定义了故障的master两种状态，O_DOWN(objectively)和S_DOWN(subobjectively)。当sentinel A连接master 1失败后，sentinel A认定master 1为subobjectively状态，然后sentinel A查看监控master 1的sentinels的认定情况。因为sentinel之间会建立连接并且不断的发起info命令询问和回应，因此在sentinel A认定master 1 S_DOWN后，sentinel A通过SENTINEL IS-MASTER-DOWN-BY-ADDR命令来不断获得其他sentinel的认定情况，如果有超过quorum(配置中指定)个sentinel认定master 1已经DOWN，那么就确定master 1为O_DOWN。然后sentinel A必须有master 1的can failover权限，这也是配置文件指定的。接着，sentinel A需要得知master 1的leader sentinel，由leader来进行master 1的错误恢复。

master 1的leader sentinel由选举产生，每个监控master 1的，并且具有错误恢复权限的sentinel都需要进行一次叫做subjective leader判断，也就是sentinel自己认定的leader，然后sentinel之间通过SENTINEL IS-MASTER-DOWN-BY-ADDR命令交流leader的认定情况，然后最终得到一个共识。

然后由这个master 1的leader sentinel来启动错误恢复例程。

3、故障处理

sentinel A作为master 1的leader，会选取一个master 1的slave作为新的master。slave的选取是根据一个判断DNS情况的优先级来得到，优先级相同通过runid的排序得到，但目前优先级设定还没实现，所以直接获取runid排序得到slave 1。

然后发送命令slaveof no one来取消slave 1的slave状态来转换为master。当其他sentinel观察到该slave成为master后,就知道错误处理例程启动了。sentinel A然后发送给其他slave slaveof new-slave-ip-port 命令，当所有slave都配置完后，sentinel A从监测的masters列表中删除故障master，然后通知其他sentinels。

4、总结

Redis-sentinel作为一个集群管理工具，基本满足了要求。但是Redis集群的需求却仍然存在。Redis集群作为分区结果，分区的配置仍然需要客户端或者代理协议实现，Redis集群作为一个整体还需要更长的路。Redis-cluster的草案早于出炉，但是实现却已经停留了很久。antriez承诺在Redis 3.0推出Redis-cluster功能。

Sentinel支持集群

很显然，只使用单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后(sentinel本身也有单点问题，single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群，这样有几个好处：

• 即使有一些sentinel进程宕掉了，依然可以进行redis集群的主备切换；
• 如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;
• 如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

Sentinel版本

Sentinel当前最新的稳定版本称为Sentinel 2(与之前的Sentinel 1区分开来）。随着redis2.8的安装包一起发行。安装完Redis2.8后，可以在redis2.8/src/里面找到Redis-sentinel的启动程序。

强烈建议：
如果你使用的是redis2.6(sentinel版本为sentinel 1)，你最好应该使用redis2.8版本的sentinel 2，因为sentinel 1有很多的Bug，已经被官方弃用，所以强烈建议使用redis2.8以及sentinel 2。

运行Sentinel
运行sentinel有两种方式：

第一种

redis-sentinel /path/to/sentinel.conf

第二种

redis-server /path/to/sentinel.conf --sentinel

以上两种方式，都必须指定一个sentinel的配置文件sentinel.conf，如果不指定，将无法启动sentinel。sentinel默认监听26379端口，所以运行前必须确定该端口没有被别的进程占用。

Sentinel的配置

Redis源码包中包含了一个sentinel.conf文件作为sentinel的配置文件，配置文件自带了关于各个配置项的解释。典型的配置项如下所示：

sentinel monitor mymas