#
为Redis提供了高可用解决方案。实际上这意味着使用Sentinel可以部署一套Redis，在没有人为干预的情况下去应付各种各样的失败事件。
下面是Sentinel的功能列表：
+ 监控（Monitoring）：Sentinel不断的去检查你的主从实例是否按照预期在工作。
+ 通知（Notification）：Sentinel可以通过一个api来通知系统管理员或者另外的应用程序，被监控的Redis实例有一些问题。
+ 自动故障转移（Automatic failover）：如果一个主节点没有按照预期工作，Sentinel会开始故障转移过程，把一个从节点提升为主节点，并重新配置其他的从节点使用新的主节点，使用Redis服务的应用程序在连接的时候也被通知新的地址。
+ 配置提供者（Configuration provider）：Sentinel给客户端的服务发现提供来源：对于一个给定的服务，客户端连接到Sentinels来寻找当前主节点的地址。当故障转移发生的时候，Sentinels将报告新的地址。
* * *
# 前言
>**主从使用一主一从，然后使用sentinel进行高可用配置，当主服务器挂掉，从服务器自动升为主服务器。**
# 1.配置主服务器
```bash
# 使得Redis服务器可以跨网络访问（直接注释也行）bind 0.0.0.0#开启持久化appendonly yes# 设置密码requirepass "123456"#配置哨兵的访问此服务名的密码masterauth 123456
```
# 2.配置从服务器
```bash
# 使得Redis服务器可以跨网络访问（直接注释也行）bind 0.0.0.0#开启持久化appendonly yes# 设置密码requirepass "123456"# 指定主服务器，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置slaveof 192.168.11.128 6379# 主服务器密码，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置masterauth 123456
```
# 3.配置一个哨兵（配置sentinel.conf，这个配置文件一般都是在安装目录下）
```bash
#哨兵端口port 26380 # 禁止保护模式protected-mode no# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，192.168.11.128代表监控的主服务器，6379代表端口，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。sentinel monitor mymaster 192.168.11.128 6379 2# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码# sentinel auth-pass <master-name> <password>sentinel auth-pass mymaster 123456
```
# **哨兵docker配置**
**这边有个注意点，docker部署启动容器网络需要使用桥接模式host**
进入容器
```javascript
dockerexec -it redis /bin/bash
```
```bash
#cd / （进入根目录）#apt-get update (更新依赖)#apt-get install -y vim (安装vim)#vim sentinel.conf (建立sentinel配置文件保存退出，内容如下)
```
启动哨兵
```undefined
redis-sentinel sentinel.conf
```
> 如果配置，主服务器（master）出现故障后，哨兵选举新的主服务器(master)
>
> 的时间默认为3分钟
## 要想配置这个时间，我们先来了解下redis哨兵的选举机制
### 1、主观下线
Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在`down-after-milliseconds`时间内没有回复Sentinel节点的心跳包，则该redis节点被该Sentinel节点主观下线。
### 2、客观下线
当节点被一个Sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。
该Sentinel节点会询问其他Sentinel节点，如果Sentinel集群中超过`quorum`数量的Sentinel节点认为该redis节点主观下线，则该redis客观下线。
如果客观下线的redis节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。
### 3、Sentinel集群选举Leader
如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。
每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。
如果一个Sentinel节点获得的选举票数达到Leader最低票数(`quorum`和`Sentinel节点数/2+1`的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。
### 4、Sentinel Leader决定新主节点
当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：
1. 过滤故障的节点
2. 选择优先级`slave-priority`最大的从节点作为主节点，如不存在则继续
3. 选择复制偏移量（数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从的偏移量一致，则数据是完全同步）最大的从节点作为主节点，如不存在则继续
4. 选择`runid`（redis每次启动的时候生成随机的`runid`作为redis的标识）最小的从节点作为主节点
### 了解了选举机制我们来看看sentinel.conf的具体配置
1.
```bash
sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 30000
```
这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒
```bash
sentinel parallel-syncs <master-name> <numslaves>
```
这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
