Redis 的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要人工进行主从切换，同时⼤量的客⼾端需要被通知切换到新的主节点上，对于上了⼀定规模的应用来说，这种⽅案是无法接受的，于是Redis从2.8开始提供了RedisSentinel（哨兵）来解决这个问题

1. Redis Sentinel的概念

1.1 基本概念

在介绍RedisSentinel之前，先对⼏个名词概念进⾏必要的说明

Redis Sentinel 是Redis 的⾼可⽤实现⽅案，在实际的⽣产环境中，对提⾼整个系统的⾼可⽤是⾮常有帮助的

1.2 引出高可用

主从复制模式很好，但是并不是万能的，它同样遗留下以下⼏个问题：

1. 主节点发⽣故障时，进⾏主从切换的过程是复杂的，需要完全的⼈⼯参与，导致故障恢复时间⽆法保障。
2. 主节点可以将读压⼒分散出去，但写压⼒/存储压⼒是⽆法被分担的，还是受到单机的限制。

其中第⼀个问题是高可用问题，即Redis哨兵主要解决的问题；第⼆个问题是属于存储分布式的问题，留给Redis集群去解决。

人工恢复主节点故障
Redis 主从复制模式下，主节点故障后需要进⾏的人工工作是⽐较繁琐的，我们在图中⼤致展⽰了整体过程

哨兵⾃动恢复主节点故障

当主节点出现故障时，RedisSentinel能⾃动完成故障发现和故障转移，并通知应用方，从⽽实现真正的⾼可⽤。

Redis Sentinel 是⼀个分布式架构，其中包含若⼲个Sentinel节点和Redis数据节点，每个Sentinel 节点会对数据节点和其余Sentinel节点进⾏监控（这些进程之间，建立tcp长连接，定期发送心跳包）。

• 当它发现节点不可达时，会对节点做下线表示。
• 如果下线的是主节点，它还会和其他的Sentinel节点进⾏“协商”（防止误判），当⼤多数Sentinel节点对主节点不可达这个结论达成共识之后，它们会在内部“选举”出⼀个领导节点来完成⾃动故障转移的⼯作，同时将这个变化实时通知给Redis应用方。

整个过程是完全⾃动的，不需要人工介入

针对主节点故障的情况，故障转移流程⼤致如下：

1. 主节点故障，从节点同步连接中断，主从复制停⽌。
2. 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商，达成多数认同主节点故障的共识。这步主要是防⽌该情况：出故障的不是主节点，⽽是发现故障的哨兵节点，该情况经常发⽣于哨兵节点的⽹络被孤⽴的场景下。
3. 哨兵节点之间使⽤Raft算法选举出⼀个领导⻆⾊，由该节点负责后续的故障转移⼯作。
4. 哨兵领导者开始执⾏故障转移：从节点中选择⼀个作为新主节点(slaveof no one)；让其他从节点同步新主节点(slaveof host port)
5. 通知应⽤层转移到新主节点。

通过上面的介绍，可以看出Redis Sentinel具有以下几个功能：

• 监控：Sentinel节点会定期检测Redis数据节点、其余哨兵节点是否可达。
• 故障转移：实现从节点晋升（promotion）为主节点并维护后续正确的主从关系。
• 通知：Sentinel节点会将故障转移的结果通知给应⽤⽅

2. Redis Sentinel的部署（基于docker）

2.1 部署

1. 安装docker和docker-compose

apt install docker-compose

2. 停⽌之前的redis-server

 # 停⽌redis-server
service redis-server stop# 停⽌redis-sentinel 如果已经有的话.
service redis-sentinel stop

3. 使⽤docker获取redis镜像

docker pull redis:5.0.9

解决 Docker 错误：docker: Get https://registry-1.docker.io/v2/: net/http: request canceled 的问题

# 1. 修改 Docker 配置文件
sudo nano /etc/docker/daemon.json# 2.将以下内容添加到配置文件中：
{"registry-mirrors" : ["https://docker.m.daocloud.io","https://docker-cf.registry.cyou"],"insecure-registries" : ["docker.mirrors.ustc.edu.cn"],"debug": true,"experimental": false
}
# 3.重启 Docker 服务
sudo systemctl restart docker

编排redis主从节点：创建三个容器，作为redis数据节点

1. 编写docker-compose.yml

创建/root/redis/docker-compose.yml，同时cd到yml所在⽬录中，编写yml文件

version: '3.7'
services:master:image: 'redis:5.0.9'container_name: redis-masterrestart: alwayscommand: redis-server --appendonly yesports:- 6379:6379slave1:image: 'redis:5.0.9'container_name: redis-slave1restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6380:6379slave2:image: 'redis:5.0.9'container_name: redis-slave2restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6381:6379

2. 启动所有容器

 docker-compose up -d

3. 查看运⾏⽇志

 docker-compose logs

编排 redis-sentinel节点

1. 编写docker-compose.yml

创建/root/redis-sentinel/docker-compose.yml，同时cd到yml所在⽬录中

version: '3.7'services:sentinel1:image: 'redis:5.0.9'container_name: redis-sentinel-1restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel1.conf:/etc/redis/sentinel.confports:- "26379:26379"sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- "26380:26379"  sentinel3:image: 'redis:5.0.9'container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- "26381:26379" 
networks:default:external:name: redis-data_default

2. 创建配置⽂件

创建sentinel1.conf、sentinel2.conf、sentinel3.conf，三份⽂件的内容是完全相同的

bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000

sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数
sentinel down-after-milliseconds：主节点和哨兵之间通过⼼跳包来进⾏沟通，如果⼼跳包在指定的时间内还没回来，就视为是节点出现故障.

3. 启动所有容器

 docker-compose up -d

4. 查看运⾏⽇志

 docker-compose logs

2.2 验证

至此，我们的节点就编排好了

下面我们来验证一下哨兵效果

结论

• Redis主节点如果宕机，哨兵会把其中的⼀个从节点，提拔成主节点.
• 当之前的Redis主节点重启之后，这个主节点被加⼊到哨兵的监控中，但是只会被作为从节点使⽤

2.3 选举流程

假定当前环境如上⽅介绍，三个哨兵(sentenal1、sentenal2、sentenal3)，⼀个主节点(redis-master)，两个从节点(redis-slave1,redis-slave2)，当主节点出现故障，就会触发重新⼀系列过程

1. 主观下线

当redis-master 宕机，此时redis-master和三个哨兵之间的⼼跳包就没有了，此时站在三个哨兵的⻆度来看，redis-master出现严重故障，因此三个哨兵均会把redis-master判定为主观下线(SDown）

2. 客观下线

此时，哨兵sentenal1、sentenal2、sentenal3均会对主节点故障这件事情进⾏投票，当故障得票数>=配置的法定票数之后，此时意味着redis-master故障这个事情被做实了，此时触发客观下线(ODown)

3. 选举出哨兵的leader

接下来需要哨兵把剩余的slave中挑选出⼀个新的master，这个⼯作不需要所有的哨兵都参与，只需要选出个代表(称为leader)，由leader负责进⾏slave升级到master的提拔过程，这个选举的过程涉及到Raft 算法。

下面的过程是面试重点

选举leader的过程：

• 每个哨兵都只有一票
• 当哨兵A第一个发现主节点是客观下线时，就立即给自己投一票，并告知哨兵B、C（相当于拉票）
• 哨兵B、C反应慢半拍，当收到哨兵A的告知，并且自己手中的票还在，就投给哨兵A
  • 若有多个拉票请求，则投给先到达的
• 如果总票数超过哨兵数量的一半，则leader选举完成（哨兵个数为奇数个，就是为了方便投票）
• 其实，投票的过程，就是看哪个哨兵的反应快（网络延迟小）

leader选好后，就需要推举从节点，从节点变为主节点的过程：

• 查看节点优先级：每个redis节点，都配置了一个优先级slave-priority，优先级高的胜出
• 优先级相同，查看offset：offset越大，表示从节点同步主节点的数据越多，二者越接近，offset大的胜出
• 优先级、offset都相同，查看runid：节点的runid是随机的，此时就看缘分了

新的主节点选好后，leader就会控制这个节点，执行slave no one，成为master节点；在控制其它节点，执行slaveof，让这些节点，以新的master作为主节点。

上述过程，都是"⽆⼈值守"，Redis⾃动完成的，这样做就解决了主节点宕机之后需要⼈⼯⼲预的问题，提⾼了系统的稳定性和可⽤性

⼀些注意事项:

• 哨兵节点不能只有⼀个，否则哨兵节点挂了也会影响系统可⽤性.
• 哨兵节点最好是奇数个，⽅便选举leader，得票更容易超过半数.
• 哨兵节点不负责存储数据，仍然是redis主从节点负责存储
  • 哨兵节点可以使用配置不是很高的节点
• 哨兵+主从复制解决的问题是"提⾼可⽤性"，不能解决"数据极端情况下写丢失"的问题
  • 即主节点写的数据，从节点还未同步，主节点就挂了。所以需要写多份数据
• 哨兵+主从复制不能提⾼数据的存储容量，当我们需要存的数据接近或者超过机器的物理内存，这样的结构就难以胜任了
  • 为了能存储更多的数据，需要引⼊了集群