方案2：主从同步Redis Server，单实例Sentinel

为了实现高可用，解决方案1中所述的单点故障问题，我们必须增加一个备份服务，即在两台服务器上分别各启动一个Redis Server进程，一般情况下由master提供服务，slave只负责同步和备份。

与此同时，在额外启动一个Sentinel进程，监控两个Redis Server实例的可用性，以便在master挂掉的时候，及时把slave提升到master的角色继续提供服务，这样就实现了Redis Server的高可用。

这基于一个高可用服务设计的依据，即单点故障本身就是个小概率事件，而多个单点同时故障（即master和slave同时挂掉），可以认为是（基本）不可能发生的事件。

对于Redis服务的调用方来说，现在要连接的是Redis Sentinel服务，而不是Redis Server了。

常见的调用过程是，client先连接Redis Sentinel并询问目前Redis Server中哪个服务是master，哪些是slave，

然后再去连接相应的Redis Server进行操作。

当然目前的第三方库一般都已经实现了这一调用过程，不再需要我们手动去实现（例如Nodejs的ioredis，PHP的predis，Golang的go-redis/redis，JAVA的jedis等）。

然而，我们实现了Redis Server服务的主从切换之后，又引入了一个新的问题，

即Redis Sentinel本身也是个单点服务，一旦Sentinel进程挂了，那么客户端就没办法链接Sentinel了。

所以说，方案2的配置并无法实现高可用性

然而，愿景是美好的，现实却是很残酷的。如此架构下，依然无法实现Redis服务的高可用。

这时，Sentinel其实是不会将仅剩的slave切换成master继续服务的，也就导致Redis服务不可用，因为Redis的设定是只有当超过50%的Sentinel进程可以连通并投票选取新的master时，才会真正发生主从切换。

本例中两个Sentinel只有一个可以连通，等于50%并不在可以主从切换的场景中。

你可能会问，为什么Redis要有这个50%的设定？假设我们允许小于等于50%的Sentinel连通的场景下也可以进行主从切换。

试想一下【异常3】，即服务器1和服务器2之间的网络中断，但是服务器本身是可以运行的。如下图所示：

方案4：主从同步Redis Server，三实例Sentinel

现在由三个Sentinel进程来管理两个Redis server实例。

这种场景下，不管是单一进程故障、还是单个机器故障、还是某两个机器网络通信故障，都可以继续对外提供Redis服务。

实际上，如果你的机器比较空闲，当然也可以把服务器3上面也开启一个Redis Server，形成1 master + 2 slave的架构，每个数据都有两个备份，可用性会提升一些。当然也并不是slave越多越好，毕竟主从同步也是需要时间成本的。

在方案4中，一旦服务器1和其他服务器的通信完全中断，那么服务器2和3会将slave切换为master。

对于客户端来说，在这么一瞬间会有2个master提供服务，并且一旦网络恢复了，那么所有在中断期间落在服务器1上的新数据都会丢失。

如果想要部分解决这个问题，可以配置Redis Server进程，让其在检测到自己网络有问题的时候，立即停止服务，避免在网络故障期间还有新数据进来（可以参考Redis的min-slaves-to-write和min-slaves-max-lag这两个配置项）。

结语

搭建任何一个服务，做到“能用”其实是非常简单的，就像我们运行一个单机版的Redis。不过一旦要做到“高可用”，事情就会变得复杂起来。业务中使用了额外的两台服务器，3个Sentinel进程+1个Slave进程，只是为了保证在那小概率的事故中依然做到服务可用。在实际业务中我们还启用了supervisor做进程监控，一旦进程意外退出，会自动尝试重新启动。

相关配置说明：

# Example sentinel.conf  

# 哨兵sentinel实例运行的端口 默认26379  

port 26379  

# 哨兵sentinel的工作目录  

dir /tmp  

# 哨兵sentinel监控的redis主节点的 ip port   

# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。  

# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了  

# sentinel monitor <master-name> <ip> <redis-port> <quorum>  

  sentinel monitor mymaster 127.0.0.1 6379 2  

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码  

# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码  

# sentinel auth-pass <master-name> <password>  

sentinel auth-pass mymaster MySUPER--secret-0123passw0rd  

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒  

# sentinel down-after-milliseconds <master-name> <milliseconds>  

sentinel down-after-milliseconds mymaster 30000  

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，  

这个数字越小，完成failover所需的时间就越长，  

但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。  

可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。  

# sentinel parallel-syncs <master-name> <numslaves>  

sentinel parallel-syncs mymaster 1  

# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：   

#1. 同一个sentinel对同一个master两次failover之间的间隔时间。  

#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。  

#3.当想要取消一个正在进行的failover所需要的时间。    

#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了  

# 默认三分钟  

# sentinel failover-timeout <master-name> <milliseconds>  

sentinel failover-timeout mymaster 180000  

# SCRIPTS EXECUTION  

#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。  

#对于脚本的运行结果有以下规则：  

#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10  

#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。  

#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。  

#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。  

#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，  

这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，  

一个是事件的类型，  

一个是事件的描述。  

如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。  

#通知脚本  

# sentinel notification-script <master-name> <script-path>  

  sentinel notification-script mymaster /var/redis/notify.sh  

# 客户端重新配置主节点参数脚本  

# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。  

# 以下参数将会在调用脚本时传给脚本:  

# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>  

# 目前<state>总是“failover”,  

# <role>是“leader”或者“observer”中的一个。   

# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的  

# 这个脚本应该是通用的，能被多次调用，不是针对性的。  

# sentinel client-reconfig-script <master-name> <script-path>  

 sentinel client-reconfig-script mymaster /var/redis/reconfig.sh