Redis高可用集群-哨兵模式（Redis-Sentinel）搭建配置教程【Windows环境】

Redis哨兵模式，用现在流行的话可以说就是一个“哨兵机器人”，给“哨兵机器人”进行相应的配置之后，这个"机器人"可以7*24小时工作，它能能够自动帮助你做一些事情，如监控，提醒，自动处理故障等。

Redis-sentinel简介

Redis-sentinel是Redis的作者antirez，因为Redis集群的被各大公司使用，每个公司要写自己的集群管理工具，于是antirez花了几个星期写出了Redis-sentinel。

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance），Redis 的 Sentinel 为Redis提供了高可用性。使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。

该系统执行以下三个任务：

监控（Monitoring）：Sentinel会不断地检查你的主服务器和从服务器是否允许正常。
提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）: （1）当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，他会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；
（2）客户端试图连接失败的主服务器时，集群也会向客服端返回新主服务器的地址，是的集群可以使用新主服务器代替失效服务器。

sentinel的分布式特性

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后(sentinel本身也有单点问题，single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群，这样有几个好处：

有一些sentinel进程宕掉了，依然可以进行redis集群的主备切换；

如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;

如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息

一个健壮的部署至少需要三个哨兵实例。

三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。【本次讲解是一个机器上进行搭建，和多级是一个道理】

Redis-sentinel搭建

1.环境

 Windows10
 redis-3.0.504
 
 本次搭建说明：
 master：127.0.0.1:6379 【初始化master】 
 slave：127.0.0.1:6380  127.0.0.1:6381 
 sentinel：127.0.0.1:26379  127.0.0.1:26380  127.0.0.1:26381

2.安装和基本配置

因为之前已经介绍过Redis集群的主从配置，里面有安装和基本配置，所以这里不做介绍，不懂的请查看第一章节：Redis集群主从复制（一主两从）搭建配置教程【Windows环境】

3.sentinel配置

根据安装和基本设置，已经有了主从配置，对应文件夹redis-3.0.504-6379~redis-3.0.504-6381。然后在每个文件夹下面新增一个名为 sentinel.conf 的文件。配置内容如下：

# 这个是 Redis6379 的配置内容，其它文件同理新增，然后修改一下端口即可：26379、26380、26381

# 当前 Sentinel 服务运行的端口
port 26379
# 哨兵监听的主服务器
sentinel monitor mymaster 127.0.0.1 6379 2
# 3s内 mymaster 无响应，则认为 mymaster 宕机了
sentinel down-after-milliseconds mymaster 3000
# 如果10s后，mymaster 仍没启动起来，则启动 failover
sentinel failover-timeout mymaster 10000
# 执行故障转移时，最多有1个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1

配置文件只需要配置 master 的信息就好啦，不用配置 slave 的信息，因为 slave 能够被自动检测到（master节点中有关于slave的信息）。

为了更清楚每一行配置的意义，对每个选项的含义进行简单介绍：

sentinel monitor [master-group-name] [ip] [port] [quorum]

• master-group-name：master 名称（可以自定义）
• ip：ip地址
• port：端口号
• quorun：票数，Sentinel 需要协商同意 master 是否可到达的数量

第一行配置指示 Sentinel 去监听一个名为 mymaster 的主服务器，这个主服务器的 IP 地址为 127.0.0.1，端口号为 6379，而将这个主服务器判断为失效至少需要2个 Sentinel 同意（只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。

票数在本文中：redis 集群中有 3 个 Sentinel 实例，其中 master 宕机啦，这里设置票数为2，表示有两个 Sentinel 认为 master 宕机啦，才能被认为是真正的宕机啦。

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

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

如果服务器在给定的毫秒数之内，没有返回 Sentinel 发送的 PING 命令的回复，或者返回一个错误，那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN）。

不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移：只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后，服务器才会被标记为客观下线（objectively down，简称ODOWN），这时自动故障迁移才会执行。

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

parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。

4.其他配置

新增 Redis 启动脚本：startRedisServer.bat 脚本，此操作在第一章节已完成。

@echo off 
redis-server.exe redis.windows.conf 
@pause

新增 Redis-Sentinel 启动脚本：startRedisSentinel.bat

@echo off
redis-server.exe sentinel.conf --sentinel
@pause

配置启动 startrRedis6379.cmd，其他同理！此操作在第一章节已完成。

@echo off 
cd redis-3.0.504-6379
startRedisServer.bat

配置启动 startrRedisSentinel26379.cmd，其他同理！

@echo off 
cd redis-3.0.504-6379 
startRedisSentinel.bat 

配置完如图：

Redis-Sentinel高可用场景演示

场景1 主服务器 master 宕机

当主服务器master宕机，那么Sentinel会通过选举（算法）机制，从Salve中选出一个作为新Master。
大概原理是当选出一个Slave要作为Master的时候，会发送命令slaveofno one来取消选中的这个slave，使其成为Master。哨兵会发送给其他从服务器Slave配置选中的这个为新主服务器Master，并删除监听列表中出现故障的Master服务器。
（1）关闭吊 6379 主服务器

（2）查看观察选举新的master的过程和显示了failover的过程，整个日志信息还是比较完整的。最后选举了6381为主服务器！

（3）查看6381服务器信息,角色为主，从服务器6380！

场景2 之前故障的6379 master 重新启动

（1）启动6379服务，发现6379成为6381的从服务器！

（2）查看 6381 服务器状态信息：原来的 master 自动切换成 slave，不会自动恢复成 master

场景3 从服务器 Slave 宕机和重启

（1）关闭 6380 从服务器

（2）Sentinel 日志

（3）查看主服务器 6381 的状态信息：

（4）启动从服务器 6380

（5）查看主服务器 6381 的信息：从服务器 Slave 6380又回来了。