Redis中sentinel集群的搭建和Jedis测试 图文教程[三]

　　在前两篇Redis中sentinel集群的搭建和Jedis测试 图文教程[一] 和Redis中sentinel集群的搭建和Jedis测试 图文教程[二] 中分别简述了Redis中sentinel集群的搭建和Java代码的Jedis测试。 　　 　　这篇主要来简单分析一下Redis-sentinel集群的原理，根据追踪sentinel信息来完成Redis-sentinel集群测试中的详细的原理分析。包括master-slave各个中的sentinel信息的分析，failover过程，master宕机后的leader选举过程等等方面深层次详细简述了其各个原理。

一、Redis常见HA方案

　　HA(High Available，高可用性群集)机集群系统简称，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，且分为活动节点及备用节点。通常把正在执 行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。From 百度百科. 　　Redis 一般以主/从方式部署（这里讨论的应用从实例主要用于备份，主实例提供读写）该方式要实现 HA 主要有如下几种方案： 　　1）keepalived：通过 keepalived 的虚拟 IP，提供主从的统一访问，在主出现问题时， 通过 keepalived 运行脚本将从提升为主，待主恢复后先同步后自动变为主，该方案的好处是主从切换后，应用程序不需要知道(因为访问的虚拟 IP 不变)，坏处是引入 keepalived 增加部署复杂性，在有些情况下会导致数据丢失； 　　2） zookeeper： 通过 zookeeper 来监控主从实例， 维护最新有效的 IP， 应用通过 zookeeper取得 IP，对 Redis 进行访问，该方案需要编写大量的监控代码； 　　3）sentinel：通过 Sentinel 监控主从实例，自动进行故障恢复，该方案有个缺陷：因为主从实例地址(IP&PORT)是不同的， 当故障发生进行主从切换后， 应用程序无法知道新地址，故 在 Jedis2.2.2 中 新 增 了 对 Sentinel 的 支 持 ， 应 用 通 过redis.clients.jedis.JedisSentinelPool.getResource()取得的Jedis实例会及时更新到新的主实例地址。 　　下面是该方案的部署逻辑图。

二、Redis-sentinel配置与部署

　　详情请见Redis中sentinel集群的搭建和Jedis测试 图文教程[一] 　　由于 sentinel 服务器已经在 redis 服务器的环境中（redis-sentinel），我们这里就直接使用它们（在生产环境中，sentinel 服务器和 redis-server 服务器一般是分离的，部署在不同的pc-server 上面，同时 sentinel 的个数和 redis-server 个数也没联系，下面为了方便学习使用将3 台 sentinel 服务都放到了一台 pc 上)。 　　注意： sentinel 配置文件只和默认的 master 有关系，和 slave 都没有关系。我们上面的例子是用了 3 个 redis-server 和 3 个 redis-sentinel，其实 redis-sentinel的个数不一定要和 redis-sever 对应，1~n 个都可以。 　　首先要清楚，sentinel是一个独立于redis之外的进程，不对外提供key/value服务。在redis的安装目录下名称叫 redis-sentinel 。 主要用来监控redis-server进程，进行master/slave管理，如果你的redis没有运行在master/slave模式下，不需要设置sentinel。

三、Redis-sentinel启动和检测

　　分别启动 redis-server 和redis-sentinel。 　　 　　1）启动 redis-0 时 redis-0 的 sentinel 控制台 　　

　　 　　2）启动 redis-1 时 reids-1 的 sentinel 控制台 　　

　　 　　启动 redis-1 时 reids-0 的 sentinel 控制台 　　

　　 　　3）启动 redis-2 时 reids-2 的 sentinel 控制台 　　

　　 　　启动 redis-2 时 reids-0 的 sentinel 控制台 　　

　　 　　启动 redis-2 时 reids-1 的 sentinel 控制台 　　

　　通过上的控制输出信息可以看出，在依次启动服务时，对用控制台输出了+sentinel、+slave、-sdown 等信息，说明各个 sentinel 之间进行了通讯，而且也监控到了 redis-server 的情况。+sentinel 表示有新的 sentinel 实例加入到监控。提示：首次构建 sentinel 环境时，，必须首先启动 master 机器。 　　 　　4）查看相关信息 　　使用 # netstat -ntlp | grep redis 命令可以看到当前 redis 运行情况。 　　

　　 　　通过 redis-cli 查看 redis-server 的状态

/usr/local/webserver/redis/redis-cli -h 127.0.0.1 -p 6379 -a abcd123457 info Replication

　　(上面的 -a 用来输入密码) 　　

说明：info 指令 　　该指令将会打印完整的服务信息，包括集群，我们只需要关注”Replication”部分（在上面的命令中，我们在 info 后面加上了 Replication 的限制，如果不加，这还会输出 Server、Clients、Memory、Persistence、Stats、CPU 和 Keyspace 等信息），这部分信息将会告诉我们”当前 server 的角色”以及指向它的所有的 slave 信息。可以通过在任何一个 slave 上，使用”INFO”指令获得当前 slave 所指向的 master 信息。下面是 slave1 的 Replication 信息。 　　

　 　　 　　同时，该指令不仅可以帮助我们获得集群的情况，当然 sentinel 组件也是使用”INFO”做同样的事情。下面是 slave2 的 sentinel 信息。 　　

　 　　 　　通过上面信息，可以清楚看到 redis 服务状态和主从关系。　 　 　　5）failover 测试 　　当上述部署环境稳定后，我们直接关闭 redis-0，在等待”down-after-milliseconds”秒之后(30 秒)，redis-0/redis-1/redis-2 的 sentinel 窗口会立即打印”+sdown”、”+odown”、”+failover”、”+selected-slave”、 “+promoted-slave”、 “+slave-reconf”等等一系列指令， 这些指令标明当 master失效后，sentinel 组件进行 failover 的过程。 　　模拟 mater 宕机的情况。此时各 sentinel 控制台输出如下信息。 　　 　　redis-0 上的 sentinel 信息. 　　

贪婪是最真实的贫穷，满足是最真实的财富