Redis哨兵配置实现服务高可用（1主1从1哨兵）

redis

Redis Sentinel为 Redis 提供了高可用解决方案。实际上这意味着使用 Sentinel 可以部署一套 Redis，在没有人为干预的情况下去应付各种各样的失败事件。

下面是 Sentinel 的功能列表：

监控（Monitoring）：Sentinel 不断的去检查你的主从实例是否按照预期在工作。
通知（Notification）：Sentinel 可以通过一个 api 来通知系统管理员或者另外的应用程序，被监控的 Redis 实例有一些问题。
自动故障转移（Automatic failover）：如果一个主节点没有按照预期工作，Sentinel 会开始故障转移过程，把一个从节点提升为主节点，并重新配置其他的从节点使用新的主节点，使用 Redis 服务的应用程序在连接的时候也被通知新的地址。
配置提供者（Configuration provider）：Sentinel 给客户端的服务发现提供来源：对于一个给定的服务，客户端连接到 Sentinels 来寻找当前主节点的地址。当故障转移发生的时候，Sentinels 将报告新的地址。

前言

主从使用一主一从，然后使用 sentinel 进行高可用配置，当主服务器挂掉，从服务器自动升为主服务器。

1.配置主服务器

# 使得Redis服务器可以跨网络访问（直接注释也行）
bind 0.0.0.0
#开启持久化
appendonly yes
# 设置密码
requirepass "123456"
#配置哨兵的访问此服务名的密码
masterauth 123456

2.配置从服务器

# 使得Redis服务器可以跨网络访问（直接注释也行）
bind 0.0.0.0
#开启持久化
appendonly yes
# 设置密码
requirepass "123456"
# 指定主服务器，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
slaveof 192.168.11.128 6379
# 主服务器密码，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
masterauth 123456

3.配置一个哨兵（配置 sentinel.conf，这个配置文件一般都是在安装目录下）

#哨兵端口
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  
sentinel auth-pass mymaster 123456

哨兵 docker 配置

这边有个注意点，docker 部署启动容器网络需要使用桥接模式 host

进入容器

docker exec -it  redis /bin/bash

#cd / （进入根目录）#apt-get update (更新依赖)#apt-get install -y vim (安装vim)#vim sentinel.conf  (建立sentinel配置文件保存退出，内容如下)

启动哨兵

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 节点作为主节点：

过滤故障的节点
选择优先级slave-priority最大的从节点作为主节点，如不存在则继续
选择复制偏移量（数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从的偏移量一致，则数据是完全同步）最大的从节点作为主节点，如不存在则继续
选择runid（redis 每次启动的时候生成随机的runid作为 redis 的标识）最小的从节点作为主节点

了解了选举机制我们来看看 sentinel.conf 的具体配置

sentinel down-after-milliseconds sentinel down-after-milliseconds mymaster 30000

这个配置项指定了需要多少失效时间，一个 master 才会被这个 sentinel 主观地认为是不可用的。单位是毫秒，默认为 30 秒

sentinel parallel-syncs

这个配置项指定了在发生 failover 主备切换时最多可以有多少个 slave 同时对新的 master 进行同步，这个数字越小，完成 failover 所需的时间就越长，但是如果这个数字越大，就意味着越多的 slave 因为 replication 而不可用。可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。