Redis Sentinel环境搭建

目的：解决Redis主从方式部署的单点问题及故障恢复，实现高可用。

一、Redis主从部署情况

由于测试环境没有多余的服务器，来搭建真实的集群。只能在同一台服务器上根据端口的不同来虚拟不同的服务器。
部署方式：采用一主两从。
主：
ip及端口：
127.0.0.1 15880
主要配置：
port、requirepass、dir、logfile等。

---

从1：
ip及端口：
127.0.0.1 15881
主要配置：
port、requirepass、dir、logfile等。
slave配置：
slaveof 127.0.0.1 15880
masterauth “xxx”

---

从2：
ip及端口：
127.0.0.1 15882
配置同从1

配置好之后，启动三个redis实例，并登陆redis-cli运行info命令，查看各个实例信息。此时master实例的Replication信息中role为master，其余了两个从实例为slave。证明部署成功。

注：redis主从配置尽量保持一致。

二、Sentinel配置

部署方式：部署3个Sentinel实例。端口：26379、26380、26381。
注：具体要配置几个Sentinel实例，要根据Redis架构来考虑。具体参考官方Sentinel文档说明
主要配置项：
port、dir、sentinel myid（不要重复）、sentinel monitor 、sentinel auth-pass。
具体配置如下：

port 26379dir "/usr/local/redis-service/master_15880"daemonize yeslogfile "/opt/redis/logs/15882/sentinel.log"sentinel myid 4aee597fe6a16437b56c86110faee1beb4a8ceehsentinel monitor master-15880 127.0.0.1 15880 2sentinel auth-pass master-15880 xxxprotected-mode nosentinel config-epoch master-15880 22sentinel leader-epoch master-15880 22sentinel  down-after-milliseconds  master-15880 60000sentinel  parallel-syncs  master-15880 1sentinel  failover-timeout  master-15880 180000sentinel client-reconfig-script master-15880 /usr/local/redis-service/15880/send_mail.sh

其他26380、26381两个实例配置类似。

配置说明：
1：sentinel monitor master-15880 127.0.0.1 15880 2：
告诉 Redis Sentinel一个叫做 master-15880的主服务器，地址为 127.0.0.1，端口为 15880 ，判断这台主服务器失效需要 2 个 Sentinel 同意(如果同意数没有达到，自动故障转移则不会开始)。

2：sentinel down-after-milliseconds master-15880 60000：
要使 Sentinel 开始认为实例已下线(down)，实例不可到达(没有响应我们的 PING，或者响应一个错误) 的毫秒数。这个时间过后，Sentinel 将标记实例为主观下线(subjectively down，也称 SDOWN)，这还不足以开启自动故障转移。但是，如果足够的实例认为具备主观下线条件，实例就会被标记为客观下线(objectively down)。需要同意的 Sentinel 数量依赖于为这台主服务器的配置。

3：sentinel parallel-syncs master-15880 1 ：
在一次故障转移之后，被配置为同时使用新主服务器的从服务器数量。这个数字越小，完成故障转移过程需要的时间就越多，如果从服务器配置为服务旧数据，你可能不太希望所有的从服务器同时从新的主服务器重同步，尽管复制过程通常不会阻塞从服务器，但是在重同步过程中仍然会有一段停下来的时间来加载来自于主服务器的大量数据。设置这个选项的值为 1 可以确保每次只有一个从服务器不可用。

4:sentinel failover-timeout master-15880 180000:
若sentinel在该配置值内未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失败。

5：sentinel client-reconfig-script：
如果在redis进行主从切换后，会执行该配置项指定脚本。（在这里我的脚本内容通过调用jar包发送邮件到相关人员，以提示解决宕机的redis实例）

  1 #! /bin/sh                                                                                                                        2 java -jar mail-1.0.0.jar

需要注意的几个地方：

1、sentinel monitor最后一个2，必须有两个sentinel实例同时检测到redis异常时，才会判断master已下线。

2、主从切换后，redis.conf、sentinel.conf内容都会改变，主要还想要原来的主从架构，要再修改配置文件；

3、master挂掉，sentinel已经选择了新的master，但是还没有将其改成master，但是已经将old master改成了slave。那么这时候如果重启old master，就会处于无主状态。所以一方面要等sentinel稳定后再启动old master，或者重新人工修改配置文件，重新启动集群。

4、sentinel只是在server端做主从切换，app端要自己开发，例如Jedis库的SentinelJedis，能够监控sentinel的状态。这样才能完整的实现高可用性的主从切换。

5、各个Sentinel实例port、dir、sentinel myid不能设置重复。

6、sentinel auth-pass配置项在用客户端连接时需要用到。如用JedisSentinelPool是需要用到password，否则获取不到redis连接。

7、protected-mode no：如果不配置该项客户端将无法连接到该端口。

8、redis.conf中的bind和sentinel.conf中的monitor 中ip和port应对应。

三个Sentinel实例都启动以后的日志信息：

图中信息包括：
1：Sentinel自己的Sentinel ID。
2：监听到了15880master实例需要2个Sentine实例确认其下线，才能确定master已下线。
3：监听到了master实例的2个slave实例信息。
4：和26380、26381两个Sentinel实例的握手信息。

三、测试故障迁移及恢复

1：关闭master服务，或者直接暴力kill。

2：查看Sentinel日志信息：

从图中看到master已经被2个Sentinel实例判定为odown，并且产生投票给了指定Sentinel ID监控的Redis实例为新的maste实例。

3：登陆2个从实例的客户端，查看info的Replication信息，发现15881从服务器的role变成了master。并且从2的master地址端口指向了该实例。具体信息如下：
从1：15881信息：

从2:15882信息：

注：Sentinel是根据redis.cnf中的slave-priority值来选择哪个实例是新的 master。slave-priority越小则优先级越高。默认值为100。
至此，Sentinel实现了故障迁移的功能。
但是由于把原master实例关闭了，其配置文件没有进行修改，但是在实例重启后会对其进行修改。

4：重启原master实例后，会给修改为slave。
Sentinel日志如下：

再次查看原master的info信息如下：

role和master信息也已修改。