首先先把基础概念内容相对理一遍:
哨兵
1.基本概念
在这边先对几个名词进行说明:
名词 | 逻辑结构 | 物理结构 |
---|---|---|
主节点(master) | Redis主服务/数据库 | 一个独立的redis进程 |
从节点(slave) | Redis从服务/数据库 | 一个独立的redis进程 |
Redis数据节点 | 主节点和从节点 | 主节点和从节点的进程 |
Sentinel节点 | 监控Redis数据节点 | 一个独立的Sentinel节点进程 |
Sentinel节点集合 | 若干Sentinel节点的抽象组合 | 若干Sentinel节点进程 |
Redis Sentinel | Redis高可用实现方案 | Sentinel节点集合和Redis数据节点进程 |
应用方 | 泛指一个或多个客户端 | 一个或者多个客户端进程或者线程 |
Red Sentinel是Redis的高可用实现方案。
1.1.主从复制的问题
Redis的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作用:第一,作为主节点的一个备份,一旦主节点出了故障不可达的情况,从节点可以作为后备顶上来,并且保证数据尽量不丢失(主从复制是最终一致性)。第二,从节点可以扩展主节点的读能力。
1.2.高可用
Redis主从复制模式下,一旦主节点出现了故障不可达,就需要Redis Sentinel自动完成发现和故障转移,并且通知应用方,从而实现真正的高可用。
Redis Sentinel是一个分布式架构,其中包括若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当他发现节点不可达时,会对节点做下线标识。如果被标志的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时候,它们回选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方。整个过程是完全自动的,不需要人工来介入。
因此,可以总结Redis Sentinel具有以下几个功能:
- 监控:Sentinel节点会定期检测Redis数据节点,其余Sentinel节点是否可达。
- 通知:Sentinel节点会将故障转移的结果通知给应用方。
- 主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。
- 配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节点集合,从中获取主节点信息。
同时看到,Redis Sentinel包含若干个Sentinel节点,这样做也带来了两个好处:
- 对于节点的故障判断是由多个Sentinel节点共同完成的,这样可以有效地防止误判。
- Sentinel节点集合是由若干Sentinel节点组成的,这样即使个别Sentinel节点不可用,整个Sentinel节点集合依然是健壮的。
注意,Sentinel节点本身就是独立的Redis节点,只不过它们有一点特殊,它们不存储任何数据,只支持部分命令。
2.实现原理
Redis Sentinel的基本实现原理,具体包含以下几个方面:
- Redis Sentinel的三个定时任务
- 主观下线和客观下线
- Sentinel领导选举
- 故障转移。
2.1.三个定时任务
1.每隔10s,每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。如:
# Replication
role:master
connected_salves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
slave1:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
复制代码
Sentinel节点通过对上述结果进行解析就可以找到相应的从节点。具体表现在:
- 通过向主节点执行info命令,获取从节点的信息,这也是为什么Sentinel节点不需要显示配置监控从节点。
- 当有新的从节点加入时都可以立刻感知出来。
- 节点不可达或者故障转移后,可以通过info命令实时更新节点拓扑信息。
- 每隔2秒,每个Sentinel节点会向Redis数据节点的**__sentinel__:hello**频道上发送该节点对于主节点的判断以及当前Sentinel节点的信息,同时每隔Sentinel节点也会订阅该频道,来了解其他Sentinel节点以及他们对主节点的判断,所以这个定时任务可以完成以下两个工作:
- 发现新的Sentinel节点
- Sentinel节点之前交换主节点的状态(作为后面客观下线以及领导者选举的依据)
- 每隔1秒,每个Sentinel节点会向主节点,从节点,其余Sentinel节点发送一条ping命令做心跳检测,来确认当前节点是否可达。
简单总结:
1)每隔10秒,会向主从节点发送info获取拓扑信息。2)每隔2秒,向*__sentinel__:hello频道发送对主节点判断和当前Sentinel信息,也就是自己的汇报结果。3)每隔1秒,向其余所有**节点发送ping,保持联系。*
2.2.主观下线和客观下线
-
主观下线:就像前面说的第三个定时任务,每个Sentinel节点每隔1s对主、从节点、其他Sentinel节点发送ping做心跳检测。当这些节点超过配置的时长没有收到有效的恢复,Sentinel节点就会对该节点做失败判定,这个行为叫做主观下线。
可以看出是一家之言,有误判的可能。
-
客观下线:当Sentinel主观下线的节点是主节点时,该Sentinel节点会通过Sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断,当超过个数,Sentinel节点认为主节点确实有问题,这时候Sentinel会做出客观下线的决定,这样客观下线的含义是比较明显了。
上面指的是对主节点客观下线的,注意,从节点、Sentinel节点在主观下线后,没有后续的故障转移操作。
2.4.领导者Sentinel节点选举
故障转移的工作只需要一个Sentinel节点来完成即可,所以Sentinel节点之间会做一个领导者选举的工作,选一个Sentinel节点作为领导者进行故障转移的工作。而采用的就是Raft算法。这边讲解一下Redis Sentinel进行领导者选举的大致思路:
- 每个Sentinel节点都有资格成为领导者。按照前面所说的:当他确认主节点主观下线时候,会向其他Sentinel节点发送Sentinel is-master-down-by-addr命令,这条的作用,也有要求将自己设置为领导者。
- 收到命令的Sentinel节点,如果没有同意过其他Sentinel节点的Sentinel is-master-down-by-addr命令,将同意该请求,否则拒绝。
- 如果该Sentinel节点发现自己的票数已经大于等于max(quorum,num(sentinels)/2+1)。那么它将成为领导。
- 如果此过程没有选举出领导者,将进行下一次选举。
**简单来说:**在客观下线确认的同时,就会请求当领导者的同意。
超过半数Sentinel节点同意,或者配置时候的同意下线人数同意。
2.5.故障转移
从刚刚选举出的领导者Sentinel节点,他来进行故障转移:
-
在从节点列表中选出一个节点作为新的主节点,选择方法如下:
- 过滤不健康的(在心跳检测等等连接中表现不好的)
- 尽量选择(有的话)salve-priority(从节点优先级)最高的从节点列表。
-
对第一部选出来的从节点执行slaveof no one命令让它成为主节点。
-
Sentinel领导者节点会向剩余的从节点发送命令,让它们成为新主节点的从节点,复制规则和parallel-syncs参数有关。
也就是用来限制在一次故障转移之后,每次向新的主节点发起复制操作的从节点个数。(避免对主节点造成过度网络和磁盘IO的开销)
-
Sentinel节点集合会将原理的主节点更新为从节点,并保持着对其关注,当其恢复后命令它去复制新的主节点。
原主节点在重新上线后会被要求去复制新的主节点。也就是说,Sentinel节点依然会对这些下线节点进行定期监控,这是Redis Sentinel设计思路决定的。
前提:本试验环境已经提前安装了docker和docker-compose
说明:本次部署是单机伪集群,想要部署真正的集群,修改ip地址拆分配置到各个主机上部署即可。
部署
这边先说一些部署技巧:
部署至少3个且奇数个的Sentinel节点:
- 3个以上是通过Sentinel节点的个数提高对于故障断定的准确性,因为领导者选举需要至少一般加1个的节点,奇数个节点可以在满足该条件的基础上节省一个节点。详情见前面提及的概念内容。
- Sentinel节点集合可以只监控一个主节点,也可以监控多个主节点。
项目分成两个目录,一个是redis目录。主要存放redis主从节点的docke-compose文件。
-
在redis文件夹下创建redis目录,主要是为了持久化redis。(RDB和AOF路径一样)
-
在同文件夹下新建 docker-compose.yml文件。
├── data │ ├── master │ ├── slave1 │ └── slave2 └── docker-compose.yml 复制代码
-
这边简单说重要的配置项:
... container_name: redis-master ... volumes: - ./data/master:/data command: redis-server --port 6379 --requirepass 123 ... container_name: redis-slave-1 ... volumes: - ./data/slave1:/data command: redis-server --slaveof 192.168.0.107 6379 --port 6380 --requirepass 1234 --masterauth 123 复制代码
需要配置好对应验证密码和容器命以便从节点连接主节点。注意从节点连接不能用127.0.0.1连接上主服务器。这个的原因就是redis主服务器绑定了127.0.0.1,那么跨服务器IP的访问就会失败,从服务器用IP和端口访问主的时候,主服务器发现本机6379端口绑在了127.0.0.1上,也就是只能本机才能访问,外部请求会被过滤。这边我修改为ifconfig获取的网卡地址,如果是线上生产环境建议绑定IP地址。
接下来是在跟目录下建立文件夹sentinel:
- 在文件夹下建立配置文件夹conf。对于3个配置文件:slave1.conf,slave2.conf,slave3.conf内容相同:
sentinel monitor mymaster 192.168.0.107 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster 1234
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
复制代码
-
在文件夹下新建docker-compose.yml。现在sentinel文件夹结构如下:
├── conf │ ├── sentinel1.conf │ ├── sentinel2.conf │ └── sentinel3.conf └── docker-compose.yml 复制代码
-
配置项重点是以下2条(注意配置文件每次成功运行后会自动更新一些节点信息):
#自定义集群名,其中 192.168.8.188 为 redis-master 的 ip,6379 为 redis-master 的端口,2 为最小投票数(因为有 3 台 Sentinel 所以可以设置成 2) sentinel monitor mymaster 192.168.8.188 6379 2 # 每个Sentinel节点都要通过定期发送ping命令来判断redis数据节点和其余Sentinel节点是否可达,超过down-after-milliseconds即为不可达。 sentinel down-after-milliseconds mymaster 30000