redis 点滴（七）sentinel 哨兵

Redis中的sentinel系统用于管理多个Redis服务器，该系统执行以下三个任务：

1.监控：sentinel会不断的监控你的主服务器与从服务器的状态

2.提醒：当被监控的某个redis服务器出现异常时，sentinel可以通过API向管理员或者其他程序发送通知

3.故障迁移：当一个主服务器不能正常工作时，sentinel会开始进行一次自动故障迁移操作，它会把失效的主服务器的其中一台从服务器升级为主服务器，并让其它的从服务器指向这台新的主服务器。

启动sentinel

对于redis-sentinel程序，你可以用一下命令来启动Sentinel系统：

redis-sentinel /path/to/sentinel.conf

对于redis-server程序，你可以用以下命令来启动一个运行在Sentinel模式下的Redis服务器：

redis-server sentinel.conf --sentinel

2种方法都可以启动一个sentinel实例

启动Sentinel实例必须指定相应的配置文件，系统会使用配置文件来保存Sentinel的状态，并在Sentinel重启时通过载入配置文件来进行状态还原。

如果在重启的时候没有找到Sentinel配置文件，那么Sentinel会拒绝启动。

 配置Sentinel

Redis配置文件中包含了一个名为Sentinel.conf的文件，这个文件是一个带有Sentinel配置文件的详情信息。

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

第一行的配置是Sentinel去监视了一个名为mymaster的主服务器，这个服务器的地址是127.0.0.1 端口号是6379 ，而将这个主服务器判断失效的至少需要2台Sentinel同意

不过要注意的是，无论你设置多少个Sentinel同意才能判断一个服务器失效，一个Sentinel都需要获得系统中多数Sentinel的支持，才能发起一次自动故障迁移，换句话说就是，在只有少数Sentinel进程正常运行的情况，Sentinel是不能执行自动故障迁移。

其他选项的基本格式如下：

sentinel <选项名字> <主服务器名字> <选项的值>

down-after-milliseconds 选项指定了Sentinel认为服务器已经断线所需要的毫秒数。

如果服务器在给定的毫秒之内，没有返回Sentinel发送的ping命令的回复，那么Sentinel会将该服务器标记为主观下线。

不过一台Sentinel标记为主观下线不一定会引起服务器的自动故障迁移，只有在足够数量的Sentinel都将一个服务器标记为主观下线之后，服务器才会标记会客观下线，这时才会自动故障迁移。

将服务器标记为客观下线所需的Sentinel数量对主服务器的配置决定的。

paraller-syncs 这个变量指定了在执行故障过程中，最多可以有多少个从服务器进行同步，这个数字越小，完成故障迁移的时间就越长。

主观下线与客观下线

1.主观下线：指的是单个Sentinel实例对服务器做出下线的判断

2.客观下线：指的是多个Sentinel实例对服务器做出下线判断，并且通过Sentinelis-master-doen-by-addr命令相互交流之后，得出下线的判断。

如果一个服务器没有在Sentinelis-master-after-milliseconds选项指定的时间内，对向它发送ping命令的Sentinel返回一个有效的回复，那么Sentinel就会把这个服务器标记为主观下线。

注意，一个服务器必须在master-down-after-milliseconds选项的值为30000毫秒，那么只要服务器在29内收到了回复，那么就会认为该服务器仍然

处于正常状态。

从主观下线到客观下线使用的是流言协议。如果Sentinel在给定的时间范围内，从其他的Sentinel那里收到了足够数量的主服务器下线的通知，那么Sentinel就会将主服务器从主观下线改为客观下线。如果之后其它的Sentinel不再报告主服务器已经下线，那么主观下线就会被移除。

客观下线只适合主服务器：对于任何的Redis实例，Sentinel在将他们判断为下线前不需要进行协商，所以从服务器或者其它的Sentinel永远不会客观下线。

只要一个Sentinel发现某个主服务器进入了客观下线，那么这个Sentinel就会被其它的Sentinel推送出，并对失效的主服务器进程故障迁移。

每个Sentinel都需要定期执行的任务

1.每个Sentinel以每秒钟一次的频率向它所知的主武器，从服务器以及其它的Sentinel发送一个ping命令。

2.如果一个实例距离最后一次回复时间大于down-after-milliseconds选项所指定的值，那么这个实例会被Sentinel标记会主观下线

3.如果主服务确定进入了主观下线的状态时，那么监听这个主服务器的Sentinel会以每秒一次的频率确定主服务器的确进入了主观下线。

4.如果主服务器被标记为主观下线，并且有足够数量的Sentinel在指定的范围时间内同意这一判断，那么该主服务器会标记为客观下线。

5.在一般情况下，每个Sentinel会以10秒的频率向主从服务器发送info命令，当一个主服务器被Sentinel标记为客观下线时，那么Sentinel会向从服务器由原来的10秒改为每秒一次。

6.当没有足够的Sentinel标记主服务器为客观下线，那么客观下线状态就会被移除。

自动发现Sentinel和从服务器

你无效为运行的每个Sentinel分别配置其它的Sentinel的地址，因为Sentinel可以通过发布与订阅功能来发现正在监视相同的主服务器的其它Sentinel，这一功能是通过频道——Sentinel_：hello 发送信息来实现的。

与此类似，你也不列出主服务器下所有的从服务器，因为Sentinel可以通过主服务器来获得所有的从服务器的信息。

Sentinel API

在默认情况下，Sentinel监听的26379端口；

有两种方法可以和Sentinel进行通信：

1.第一种方法就是直接发送命令来查询被监听的Redis服务器当前状态，以及Sentinel所知道的关于其他Sentinel的信息

2.另外一种就是使用发布与订阅频道，通过接收Sentinel发送的通知：当故障发生转移操作，或者某个被监听的服务器被判断为主观下线或者客观下线时，Sentinel就会发送想要的。

发布与订阅信息

客户端可以将Sentinel看做是一个只订阅了Redis服务器，你不可以发送Publish命令，但你可以使用subscribe命令或者psubscribe命令，通过订阅的频道来获取相应的事件提醒。

故障迁移

一次故障迁移操作有以下步骤组成:

1.发现主服务器已经进入了客观下线状态。

2.如果当选失败之后，那么会在设定的故障迁移超时时间的两倍之后，重新尝试当选。如果当选成功，那么执行以下步骤。

3.选出一个从服务器，并将它升级为主服务器。

4.向被当选的从服务器发送slaveof no one 命令，将它转变成主服务器。

5.通过发布与订阅功能，将更新后的配置传播给所有其他的Sentinel，其他的Sentinel对它们自己的配置进行更新。

6.向已下线主服务器的从服务器发送slave命令，让它们去复制新的主服务器。

7.当所有的从服务器已经开始复制新的主服务器时，领头的Sentinel终止这次故障迁移操作。