Redis哨兵

redis sentinel

redis哨兵为redis提供高可用。这就意味着你用哨兵可以创建一个redis部署，在没有人为干预的情况下抵抗某些失败。（ps：自动故障转移）

redis哨兵还提供其他的附件任务，比如监控，通知，以及作为客户端的配置提供者。

• monitoring（监视） ： 哨兵会不断地检查master和slave实例是否按照预期的那样工作
• notification（通知） ： 哨兵可以通过api的方式来通知管理员（另一台计算机程序），告诉它其中一个被监视的redis实例出了问题
• automatic failover（自动故障转移） ： 如果一个master没有如期望的那样工作，哨兵可以开始一个故障转移处理，处理的结果时一个slave被提升为master，其余的slave将用这个新master重新配置，使用这个redis服务器的应用程序会被通知在连接时使用新的地址。
• configuration provider（配置提供者） ： 哨兵充当客户端服务发现的权威来源：为了对给定的服务请求作出响应，客户端连接到哨兵以获得当前master的地址。如果发生故障转移，前哨将报告新地址。

哨兵的分布式特性

redis哨兵是一个分布式系统：

哨兵自身被设计为在一个配置中运行，其中有多个sentinel进程协同工作。

多个哨兵进程协同工作的优势在于：

1. 当多个哨兵都同意且一致认为给定的master不可用时才会执行失败检测。这降低了误报的概率。
2. 即使不是所有哨兵进程都正常工作（ps：个别哨兵不能正常工作）的情况下，仍然会使得系统对故障有较强的抵抗力。

获得哨兵

当前版本的哨兵被叫做“sentinel 2”。它是用更强大和更简单的预测算法重写最初的sentinel实现。

运行哨兵

redis-sentinel /path/to/sentinel.conf

或者

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

这两种方式是一样的

当运行哨兵时，必须使用一个配置文件，因为系统将会使用这个文件来保存当前状态，以便在重启的时候开业重新加载。如果没有提供配置文件，或者配置文件路径不可写，哨兵将拒绝启动。

默认情况下，哨兵会监听tcp端口26379，因此，为了让哨兵正常工作，服务器的26379端口必须是开放的，以便可以接收到来自其它哨兵实例的ip的连接。否则，哨兵就不能说话，也不能同意，故障转移也永远不会执行。（ps：意思是，哨兵之间用26379端口进行通信，如果不开放这个端口，其它哨兵就无法与它通信，它也不同同意其它哨兵）

部署前哨之前要了解的基本知识：

1、对于一个健壮的部署，你需要至少3个哨兵实例

2、这三个哨兵应该被放置到相对独立的计算机或者虚拟机上（ps：独立失败，意思是一个失败了对其它的没用影响）

3、sentinel + redis分布式系统不能保证在故障期间已经确认的写操作被保留，因为redis使用异步复制。

4、你的redis客户端需要支持哨兵

5、如果你在开发环境（甚至是生产环境）没用经过一次又一次严格的测试，那么没用任何ha是安全的。可能你有一个错误的配置，但是一时半会儿看不出什么问题来，有可能过来很久以后这个错误配置导致的问题才会变得明显起来。（ps：意思是，上线前要严格测试，因为你的生产环境上并不是只有redis，有可能其它的隐患因素，比如防火墙什么的。。。）

6、哨兵、docker，或者其它nat或端口映射，这些混在一起要特别小心

配置哨兵

配置文件 sentinel.conf

一个典型的，最小最简洁的配置如下：

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

你只需要指定要监视的masters，并且给它们（ps：指的是被监视的master）每一个（也许它们有许多slaves）指定一个唯一的名称。不需要指定slaves，哨兵会自动发现它们。哨兵将自动更新配置，向配置文件中添加一些关于slaves的信息（为了在重启的时候保留这些信息）。每次故障转移期间一个slave被提升为master，以及每次发现一个新的哨兵时，都会重写配置文件。

上面的配置示例中，监视两组redis实例，每一组的都由一个master和未知数量的slaves。一个实例叫mymaster，另一个叫resque。

sentinel monitor 语句的格式如下：

sentinel monitor <master-group-name> <ip> <port> <quorum>

第一行是用来告诉redis监视一个叫“mymaster”的master，它的地址是127.0.0.1，端口是6379，法定人数是2。

关于 quorum 参数：

1、quorum 是一个数字，代表需要有多少个哨兵同意给定的master不可达这个事实，为了真正标记这个slave失败，并且如果可能的话最终启动一个故障转移

2、quorum 只用于检测失败。为了真的执行一个故障转移，其中一个哨兵需要被选举成为leader，然后由这个leader来执行故障转移。而且，只有在哨兵中的大多数参与投票选举才算是有效。

如果你有5个哨兵，对于给定master的法定人数是2，那么将会发生：

1、如果两个哨兵都同意并且一致认为master不可访问，那么其中一个将尝试启动一个故障转移

2、如果至少有3个哨兵正常工作且相互可以正常通信，那么故障转移将会被授权，并真正开始执行

也就是说，如果哨兵中的大多数相互之间都无法通信，那么故障转移便从来都不会发生。

（画外音：上面这段话的意思是，只有当至少有法定人数个哨兵认为某个master不可到达的时候，才会尝试启动故障转移，但是最后是否真的执行要看本次投票是否有效，只有当大多数哨兵正常工作时投票才算有效。

也就是说要执行故障转移有两个条件：第一、大多数的哨兵工作正常；第二、至少法定人数个哨兵一致认为master不可访问）

其它哨兵选项

其它的选项大多数都是这样的格式：

sentinel <option_name> <master_name> <option_value>

1、down-after-milliseconds 参数是一个毫秒时间，表示多少毫秒没有回复则认为下线（要么是没有收到ping回复，要么是回复错误）

2、parallel-syncs 参数表示在一个故障转移后新的master需要配置的slave数量。这个数值越小，故障转移完成的所需的时间越长。如果将从服务器配置为服务旧数据，您可能不希望所有从服务器同时与主服务器重新同步。对于slave来说，复制过程基本上不是阻塞的，但有时它会停止从master装载大量数据。通过将此选项设置为1，可以确保一次只能访问一个slave。

哨兵部署示例

参考

其它相关

《redis集群》