【Redis 进阶】哨兵 Sentinel（重点理解流程和原理）_redis sentinel原理

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

# 安装 docker-compose
yum install docker-compose
 
# 停⽌之前的 redis-server
service redis-server stop
 
# 停⽌ redis-sentinel (如果已经有的话)
service redis-sentinel stop
 
# 使⽤ docker 获取 redis 镜像
docker pull redis:5.0.9

version: '3.7'
services:
  master:
    image: 'redis:5.0.9'
    container_name: redis-master
    restart: always
    command: redis-server --appendonly yes
    ports: 
      - 6379:6379
  slave1:
    image: 'redis:5.0.9'
    container_name: redis-slave1
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6380:6379
  slave2:
    image: 'redis:5.0.9'
    container_name: redis-slave2
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6381:6379

也可以直接在 windows 上使用 vscode 编辑好 yml，然后在上传到 Linux 上。 

（2）启动所有容器

新的写法是不带中间横杠，如下：

如果启动后发现前面的配置有误，需要重新操作，使用 docker-compose down 即可停止并删除刚才创建好的容器。

（3）查看运行日志

上述操作必须保证工作目录在 yml 的同级目录中，才能工作。

（4）验证

A. 连接主节点

version: '3.7'
services:
  sentinel1:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-1
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel1.conf:/etc/redis/sentinel.conf
    ports:
      - 26379:26379
  sentinel2:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-2
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel2.conf:/etc/redis/sentinel.conf
    ports:
      - 26380:26379
  sentinel3:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-3
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel3.conf:/etc/redis/sentinel.conf
    ports:
      - 26381:26379
networks:
  default:
    external:
      name: redis-data_default

也可以直接在 windows 上使用 vscode 编辑好 yml，然后在上传到 linux 上。

如果没有加上最后这一段：

那么 docker compose 一下子启动 N 个容器，此时这 N 个容器都处于同一个 “局域网” 中，可以让这 N 个容器之间相互访问。三个 redis-server 节点是一个局域网，三个哨兵节点是另一个局域网，默认情况下，这两网络不是互通的。解决方案就是使用 docker compose 把此处的两组服务给放到同一个局域网中（docker network ls 命令可以列出当前 docker 中的局域网），此时再启动这三个节点就直接让他们加入到同一个局域网中，而不是创建新的局域网。

（2）创建配置文件

创建 sentinel1.conf、sentinel2.conf、sentinel3.conf，三份文件的初始内容是完全相同的，都放到 /root/redis-sentinel/ 目录中。

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

A. 理解 sentinel monitor

sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数

• 主节点名，这个是哨兵内部自己起的名字。
• 主节点 ip，部署 redis-master 的设备 ip。此处由于是使用 docker，可以直接写 docker 的容器名，会被自动 DNS 成对应的容器 ip。
• 主节点端口。
• 法定票数。哨兵需要判定主节点是否挂了，但是有的时候可能因为特殊情况，比如主节点仍然工作正常，但是哨兵节点自己网络出问题了，无法访问到主节点了，此时就可能会使该哨兵节点认为主节点下线，出现误判。使用投票的方式来确定主节点是否真的挂了是更稳妥的做法，需要多个哨兵都认为主节点挂了，票数 >= 法定票数 之后，才会真的认为主节点是挂了。

B. 理解 sentinel down-after-milliseconds

• 主节点和哨兵之间通过心跳包来进行沟通，如果心跳包在指定的时间内还没回来，就视为是节点出现故障。

既然内容相同，为什么要创建多份配置文件？

redis-sentinel 在运行中可能会对配置进行 rewrite，修改文件内容。如果用一份文件，就可能出现修改混乱的情况。

（3）启动所有容器

如果启动后发现前面的配置有误，需要重新操作，使用 docker-compose down 即可停止并删除刚才创建好的容器。

（4）查看运行日志

上述操作必须保证工作目录在 yml 的同级目录中才能工作。可以看到，哨兵节点已经通过主节点认识到了对应的从节点。

（5）观察 redis-sentinel 的配置 rewrite

再次打开哨兵的配置文件，发现文件内容已经被自动修改了。

这里的内容就是自动修改的，对比这三份文件, 可以看到配置内容是存在差异的。

三、重新选举

哨兵存在的意义：能够在 Redis 主从结构出现问题（比如主节点挂了）时，哨兵节点自动帮我们重新选出一个主节点来代替之前挂了的节点，保证整个 Redis 仍然是可用状态。

1、redis-master 宕机之后

手动把 redis-master 干掉：

当主节点挂了之后，哨兵节点就开始工作了，具体如何工作的，来观察哨兵的日志：

可以看到哨兵发现了主节点 sdown，进一步的由于主节点宕机得票达到 3/2，达到法定得票，于是 master 被判定为 odown。

• 主观下线（Subjectively Down，SDown）：哨兵感知到主节点没心跳了，判定为主观下线。
• 客观下线（Objectively Down，ODown）：多个哨兵达成一致意见，才能认为 master 确实下线了。

接下来，哨兵们挑选出了⼀个新的 master。在上图中，是 172.18.0.3:6379 这个节点。此时，对于 Redis 来说仍然是可以正常使用的。

2、redis-master 重启之后

手动把 redis-master 启动起来：

观察哨兵日志，可以看到刚才新启动的 redis-master 被当成了 slave：

使用 redis-cli 也可以进⼀步的验证这⼀点：

3、结论

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

四、选举原理

假定当前环境如上方介绍，三个哨兵（sentenal1、sentenal2、sentenal3），一个主节点（redis-master），两个从节点（redis-slave1、redis-slave2）。

当主节点出现故障，就会触发重新一系列过程。

1、主观下线

哨兵节点通过心跳包来判断 Redis 服务器是否正常工作。当 redis-master 宕机，此时 redis-master 和三个哨兵之间的心跳包就没有了。此时，站在三个哨兵的角度来看，redis-master 出现严重故障。此时还不能排除网络波动的影响，因此三个哨兵均会把 redis-master 判定为主观这个 Redis 节点下线（SDown）。

2、客观下线

此时，哨兵 sentenal1、sentenal2、sentenal3 均会对主节点故障这件事情进行投票。当故障得票数 >= 配置的法定票数之后

sentinel monitor redis-master 172.22.0.4 6379 2

在这个地方配置的 2，即为法定票数。此时意味着 redis-master 故障这个事情被做实了，此时触发客观下线（ODown）。

是否可能出现非常严重的网络波动，而导致所有的哨兵都联系不上 Redis 主节点，而被误判为挂了呢？

是有这个可能的。如果出现这个情况，怕是用户的客户端也连不上 Redis 主节点了，此时这个主节点基本也就无法正常工作了。

“挂了” 不一定是进程崩了，只要是无法访问，都可以被视为是挂了。

3、选举出哨兵的 leader

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

假定一共三个哨兵节点：S1、S2、S3

1. 每个哨兵节点都给其他所有哨兵节点，发起⼀个 “拉票请求”（S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3，S3 -> S1，S3 -> S2）。
2. 收到拉票请求的节点，会回复一个 “投票响应”。响应的结果有两种可能，投 / 不投。比如 S1 给 S2 发了个投票请求, S2 就会给 S1 返回投票响应。到底 S2 是否要投 S1 呢？取决于 S2 是否给别⼈投过票了（每个哨兵只有一票）。如果 S2 没有给别⼈投过票，换而言之，S1 是第一个向 S2 拉票的，那么 S2 就会投 S1，否则则不投。
3. ⼀轮投票完成之后, 发现得票超过半数的节点，自动成为 leader。如果出现平票的情况（S1 投 S2，S2 投 S3，S3 投 S1，每人一票），就重新再投一次即可。这也是为啥建议哨兵节点设置成奇数个的原因。如果是偶数个，则增大了平票的概率，带来不必要的开销。
4. leader 节点负责挑选一个 slave 成为新的 master，当其他的 sentenal 发现新的 master 出现了，就说明选举结束了。

简而言之，Raft 算法的核心就是 “先下手为强”。谁率先发出了拉票请求，谁就有更大的概率成为 leader。这里的决定因素成了 “网络延时”。网络延时本身就带有一定随机性。

具体选出的哪个节点是 leader，这个并不重要，重要的是能选出一个节点即可 。

4、leader 挑选出合适的 slave 成为新的 master

挑选规则：

1. 比较优先级。优先级高（数值小的）的上位，优先级是配置文件中的配置项（slave-priority 或者 replica-priority）。
2. 比较 replication offset 谁复制的数据多，高的上位。
3. 比较 run id，谁的 id 小，谁上位。

当某个 slave 节点被指定为 master 之后，

1. leader 指定该节点执行 slave no one，成为 master。
2. leader 指定剩余的 slave 节点，都依附于这个新 master。

五、小结

上述过程都是 “无人值守”，Redis 自动完成的。这样做就解决了主节点宕机之后需要人工干预的问题，提高了系统的稳定性和可用性。

• 哨兵节点不能只有一个，否则哨兵节点挂了也会影响系统可用性。
• 哨兵节点最好是奇数个，方便选举 leader，得票更容易超过半数。
• 哨兵节点不负责存储数据，仍然是 redis 主从节点负责存储。
• 哨兵 + 主从复制解决的问题是 “提高可用性”，不能解决 “数据极端情况下写丢失” 的问题。
• 哨兵 + 主从复制不能提高数据的存储容量。当我们需要存的数据接近或者超过机器的物理内存，这样的结构就难以胜任了。