Redis高可用之-哨兵模式

剑圣无痕
300 阅读7分钟

前言

关于Reids的哨兵模式我们需要掌握如下的核心知识

  • 1.如何搭建Redis哨兵
  • 2.哨兵模式原理
  • 3.哨兵模式优缺点

简介

哨兵模式是Redis的高可用方式，哨兵节点是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。

哨兵模式架构图:

图片.png

Redis Sentinel ，它由两部分组成，哨兵节点和数据节点：

  • 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据，对数据节点进行监控。
  • 数据节点:主节点和从节点都是数据节点；

哨兵模式搭建

本次搭建为单机的哨兵模式，本地环境配置1哨兵和1主和2从。

图片.png

基础配置

哨兵模式是基于主从模式而来，所以需要首先搭建主从模式，详情可以参考juejin.cn/post/711782…

打开/etc/sentinel.conf，编辑内容如下：

#端口
port 26379

# 是否守护进程启动
daemonize no

#文件目录
dir /tmp

#监听主节点
sentinel monitor mymaster 127.0.0.1 6379 2

#主节点密码
sentinel auth-pass mymaster 123456

#发生failover故障转移时最多可以有1个slave同时对新的master进行同步
sentinel parallel-syncs mymaster 2

#检测心跳时间
sentinel down-after-milliseconds mymaster 10000

#故障转移时间
sentinel failover-timeout mymaster 180000

说明：

  • sentinel monitor <master‐name>、ip、redis‐port、quorum master‐name：主节点master的名字 ip:主节点ip地址 redis‐port:主节点端口 quorum：哨兵集群中多少个sentinel 认为 master失效才判定为客观下线，一般配节点数/2+1

  • sentinel down-after-milliseconds：配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。

  • sentinel failover-timeout：故障转移的时间。

  • sentinel parallel-syncs:指定在发生failover故障转移时最多可以有1个slave同时对新的master进行同步

启动哨兵

./redis-server sentinel.conf --sentinel &

查看哨兵状态信息

配置完之后,登录Redis客户端，输入info命令,查看哨兵的状态信息。

哨兵实现原理

哨兵实现原理可以分为：定时监控、主观下线、客观下线、leader选举、故障转移。

定时监控

哨兵启动后,哨兵会与监控的主数据库建立两条连接，其中一条用来订阅该主数据的__sentinel__:hello频道以获取其他同样监控该数据库的哨兵节点的信息，哨兵也需要定期向主数据库发送INFO等命令来获取主数据库本身的信息。和主数据库建立连接完成之后，哨兵会使用另外一条连接来发送命令：

  • 1.每隔10秒，每个哨兵会向主节点和从节点发送INFO命令，获取主节点和从节点的信息。
  • 2.每隔2秒，每个哨兵会向Redis的数据节点的_sentinel_:hello频道发送,该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息.
  • 3.每隔1秒，每个哨兵会向主节点、从节点和其他哨兵节点发送PING命令做一次心跳，来确认这些节点当前是否可达。

主观下线和客观下线

图片.png

主观下线:每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过 down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。

客观下线:当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过quorum个数，Sentinel节点认为主节点确实有问题，这时Sentinel节点会做出客观下线的决定，当有N个实例，最好要有N/2+1个哨兵实例认为其"主观下线"，那么主库才是"客观下线"。这样的好处减少了误判的概率，避免了不必要的开销。

哨兵选举

当哨兵节点发生客观下线,哨兵节点之间会做一个领导者选举的工作，选出一个哨兵节点作为领导者进行故障转移的工作。Redis使用了Raft算法实现领导者选举，基本流程如下：

  • 每个sentinel节点都有资格成为领导者，当它主观认为某个数据节点宕机后，会向其他sentinel节点发送sentinel-is-master-down-by-addr命令，要求自己成为领导者。

  • 收到命令的sentinel节点，如果没有同意过其他sentinel节点的sentinel-is-master-down-by-addr命令，将同意该请求，否则拒绝(每个sentinel节点只有1票)

  • 如果该sentinel节点发现自己的票数已经大于等于MAX(quorum，num(sentinel)/2+1),那么它将成为领导者.

  • 如果此过程没有选举出领导者，将进入下一次选举.

故障转移

领导者选举出的Sentinel节点负责故障转移，过程如下：

图片.png

  • 1.在从节点列表中选出一个节点作为新的主节点，负责故障恢复。
  • 2.哨兵领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点
  • 3.哨兵领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点
  • 4.哨兵节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点。

如何选举新的主节点

选举新主的过程总结为"筛选+排序"。首先哨兵会按照一定的筛选机制筛选掉不符合要求的从库，然后从符合条件的从库中进行排序，从而诞生出新库。

筛选

图片.png

  • 筛除掉所有处于下线或者断线状态的从服务器，这可以保证剩余的从服务器都是正常在线的。
  • 筛除掉所有在规定时间内没有响应哨兵的INFO命令的从服务器，这可以保证剩余的从服务器都是最近成功进行通信的。
  • 筛除掉所有与已下线主服务器连接断开超过down-after-milliseconds*10毫秒的从服务器，这样可以保证剩余的从服务器都没有过早地与主服务器断开连接，换句话来说，列表中的从服务器保存的数据都是比较新的。

排序

  • 哨兵会根据从服务器的优先级，对列表中剩余的从服务器进行排序，选出优先级最好的从服务器。
  • 若有多个相同最好优先级的从服务器，那么哨兵会按照复制偏移量对具有相同优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器。
  • 若有多个优先级最高、复制偏移量最大的从服务器，那么哨兵将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的从服务器。

哨兵模式优缺点

优点

  • 监控(Monitoring)：哨兵会不断地检查主节点和从节点是否运作正常。
  • 自动故障转移(Automatic failover)：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
  • 配置提供者(Configuration provider)：客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
  • 通知(Notification)：哨兵可以将故障转移的结果发送给客户端。

缺点

  • 哨兵模式只有一个主节点对外提供服务，写的效率低，无法支持高并发。
  • 单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。
  • 主从切换的瞬间会导致服务不可用。

总结

本文对Reids的哨兵模式进行详细的讲解，如有疑问请随时反馈。

avatar
文章
阅读
粉丝