Redis的哨兵机制

1. 文章前言

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

• Redis Sentinel的概念。
• Redis Sentinel的部署。
• Redis Sentinel命令。
• Redis Sentinel客户端。
• Redis Sentinel实现原理。

2. 基本概念

（1）由于对Redis的许多概念都有不同的名词解释，所以在介绍Redis Sentinel之前，先对几个名词概念进行必要的说明，如下表所示。
Redis Sentinel是Redis的高可用实现方案，在实际的生产环境中，对提高整个系统的高可用是非常有帮助的，本节首先整体梳理主从复制模式下故障处理可能产生的问题，而后引出高可用的概念，最后重点分析Redis Sentinel的基本架构、优势，以及是如何实现高可用的。

2.1 主从复制的问题

（1）Redis的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：

• 第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备“顶” 上来，并且保证数据尽量不丢失(主从复制表现为最终一致性) 。
• 第二，从节点可以分担主节点上的读压力，让主节点只承担写请求的处理,将所有的读请求负载均衡到各个从节点上。但是主从复制模式并不是万能的，它同样遗留下以下几个问题：
  1. 主节点发生故障时，进行主备切换的过程是复杂的，需要完全的人工参与，导致故障恢复时间无法保障。
  2. 主节点可以将读压力分散出去，但写压力/存储压力是无法被分担的，还是受到单机的限制。

其中第一个问题是高可用问题，即Redis哨兵主要解决的问题。第二个问题是属于存储分布式的问题，留给Redis集群去解决，本章我们集中讨论第一个问题。

2.2 人工恢复主节点故障

（1）Redis主从复制模式下，主节点故障后需要进行的人工工作是比较繁琐的，我们在图中大致展示了整体过程。redis主节点故障后需要进行的操作：

1. 运维人员通过监控系统，发现Redis主节点故障宕机。
2. 运维人员从所有节点中，选择- -个(此处选择了slave 1)执行slaveof no one,使其作为新的主节点。
3. 运维人员让剩余从节点(此处为slave 2)执行slaveof {newMasterlp} {newMasterPort}从新主节点开始数据同步。
4. 更新应用方连接的主节点信息到{newMasterlp} {newMasterPort}。
5. 如果原来的主节点恢复,执行slaveof {newMasterlp} {newMasterPort}让其成为一个从节点。

上述过程可以看到基本需要人工介入，无法被认为架构是高可用的。而这就是Redis Sentinel所要做的。

2.3 哨兵机制自动恢复主节点故障

（1）当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

• Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线表示。
• 如果下线的是主节点，它还会和其他的Sentinel节点进行“协商” ，当大多数Sentinel节点对主节点不可达这个结论达成共识之后，它们会在内部“选举” 出一 个领导节点来完成自动故障转移的工作，同时将这个变化实时通知给Redis应用方。整个过程是完全自动的，不需要人工介入。整体的架构如图所示。
• 这里的分布式架构是指: Redis 数据节点、Sentinel 节点集合、客户端分布在多个物理节点上，不要与后边章节介绍的Redis Cluster分布式混淆。

（2）Redis Sentinel架构：

（3）Redis Sentinel相比于主从复制模式是多了若干(建议保持奇数) Sentinel 节点用于实现监控数据节点，哨兵节点会定期监控所有节点(包含数据节点和其他哨兵节点)。针对主节点故障的情况，故障转移流程大致如下：

1. 主节点故障，从节点同步连接中断，主从复制停止。
2. 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商，达成多数认同主节点故障的共识。这步主要是防止该情况:出故障的不是主节点，而是发现故障的哨兵节点，该情况经常发生于哨兵节点的网络被孤立的场景下。
3. 哨兵节点之间使用Raft算法选举出一个领导角色，由该节点负责后续的故障转移工作。
4. 哨兵领导者开始执行故障转移:从节点中选择一个作为新主节点;让其他从节点同步新主节点;通知应用层转移到新主节点。

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

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

3. 安装部署哨兵（基于docker）

3.1 安装docker

（1）安装docker和docker-compose：

• docker-compose的安装：

# ubuntu
apt install docker-compose
# centos
yum 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 

3.2 编排redis主从节点

（1）编写docker-compose. yml：

• 创建docker-compose.yml文件，同时cd到yml所在目录中。
• 注意：docker中可以通过容器名字，作为ip地址，进行相互之间的访问。

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

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

（3）查看运行日志：

docker-compose logs 

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

（4）验证：

• 连接主节点：

[root@host ~]# redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.22.0.3,port=6379,state=online,offset=348,lag=1
slave1:ip=172.22.0.4,port=6379,state=online,offset=348,lag=1
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:348
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:348

• 连接两个从节点：

[root@host ~]# redis-cli -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:446
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:446
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:446

[root@host ~]# redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:516
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:516
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:516

3.3 编排redis-sentinel节点

（1）也可以把redis-sentinel放到和上面的redis的同一个yml中进行容器编排。此处分成两组，主要是为了两方面：

• 观察日志方便。
• 确保redis主从节点启动之后才启动redis-sentinel。如果先启动redis-sentinel的话，可能触发额外的选举过程，混淆视听(不是说先启动哨兵不行,而是观察的结果可能存在一定随机性)。

（2）编写docker-compose.yml文件：

• 创建docker- compose.yml文件，同时cd到yml所在目录中。
• 注意：每个目录中只能存在一个docker-compose.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:26379sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379sentinel3: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

（3）创建配置文件：

• 创建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

（4）理解 sentinel monitor：

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

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

（5）理解sentinel down-after-milli seconds：

• 主节点和哨兵之间通过心跳包来进行沟通。如果心跳包在指定的时间内还没回来就视为是节点出现故障。
• 既然内容相同为啥要创建多份配置文件？redis-sentinel在运行中可能会对配置进行rewrite，修改文件内容。如果用一份文件，就可能出现修改混乱的情况。

（6）启动所有容器：

docker-compose up -d 

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

（7）查看运行日志：

docker-compose logs 

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

（8）观察redis-sentinel的配置rewrite：

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

bind 0.0.0.0
port 26379
sentinel myid 4d2d562860b4cdd478e56494a01e5c787246b6aa
sentinel deny-scripts-reconfig yes
# Generated by CONFIG REWRITE
dir "/data"
sentinel monitor redis-master 172.22.0.4 6379 2
sentinel down-after-milliseconds redis-master 1000
sentinel config-epoch redis-master 1
sentinel leader-epoch redis-master 1
sentinel known-replica redis-master 172.22.0.2 6379
sentinel known-replica redis-master 172.22.0.3 6379
sentinel known-sentinel redis-master 172.22.0.7 26379 f718caed536d178f5ea6d1316d
sentinel known-sentinel redis-master 172.22.0.5 26379 2ab6de82279bb77f8397c309d3
sentinel current-epoch 1
# Generated by CONFIG REWRITE这里的内容就是自动修改的.

对比这三份文件，可以看到配置内容是存在差异的。

4. 重新选举

（1）手动把redis-master干掉，redis-master宕机之后：

docker stop redis-master 

（2）观察哨兵的日志：

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

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

（4）接下来，哨兵们挑选出了一个新的master。在上图中，是172.22. 04:6379这个节点。

（5）此时对于Redis来说仍然是可以正常使用的。redis-master重启之后手动把redis-master 启动起来。

docker start redis-master 

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

（7）使用redis-cli也可以进一步的验证这一点：

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:172.22.0.4
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:324475
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:ececc285a2892fba157318c77ebe1409f9c2254e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:324475
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:318295
repl_backlog_histlen:6181

（8）结论：

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

5. 选举原理

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

（2）主观下线：

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

（3）客观下线：

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

sentinel monitor redis-master 172.22.0.4 6379 2 

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

（4）选举出哨兵的leader：

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

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

1. 每个哨兵节点都给其他所有哨兵节点，发起一一个"拉票请求"(S1->S2、S1->S3、S2-> S1、S2-> S3、S3-> S1、S3-> S2)。
2. 收到拉票请求的节点,会回复一个"投票响应"。响应的结果有两种可能，投or不投。比如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出现了，就说明选举结束了。

（6）简而言之，Raft算法的核心就是"先下手为强".谁率先发出了拉票请求，谁就有更大的概率成为leader。这里的决定因素成 了"网络延时"。网络延时本身就带有一定随机性。具体选出的哪个节点是leader这个不重要，重要的是能选出一个节点即可。

（7）leader挑选出合适的slave成为新的master的挑选规则：

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

（8）当某个slave节点被指定为master之后：

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

6. 总结

（1）上述的所有过程都是 "无人值守"的，Redis 自动完成的。这样做就解决了主节点宕机之后需要人工干预的问题，提高了系统的稳定性和可用性。一些注意事项如下：

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

为了能存储更多的数据，就引入了集群这个概念。