哨兵

  • 集群监控:负责监控 redis master 和 slave 进程是否正常工作。
  • 消息通知:Sentinel节点会将故障转移的结果通知给应用方。
  • 故障转移:如果 master node 挂掉了,sentinel会自动选出一个新的redis master node
  • 配置中心:客户端在初始化的时候连接的是Sentinel节点集合,从中获取主节点 信息如果故障转移发生了,通知 client 客户端新的 master 地址

哨兵至少需要 3 个实例,来保证自己的健壮性

当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossip protocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master

2020224134359 屏幕截图 2020-10-07 155936

高可用读写分离:

屏幕截图 2020-10-08 144313

原理

三个定时任务:

  • 每隔10秒,每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构
  • 每隔2秒,每个Sentinel节点会向Redis数据节点的 sentinel :hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息 每个Sentinel节点也会订阅该频道
  • 每隔1秒,每个Sentinel节点会向主节点、从节点、其余Sentinel节点 发送一条ping命令做一次心跳检测

sdown与odown:

  • sdown:主观宕机,某一哨兵发现无法连接master
  • odown,一定数量的哨兵发现无法连接master

sentinel领导节点选举:通过raft算法 由sentienl领导节点进行故障转移的操作

故障转移

  • 选择一个新主节点

屏幕截图 2020-10-08 143210

  • Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命 令让其成为主节点
  • Sentinel领导者节点会向剩余的从节点发送命令,让它们成为新主节点的从节点
  • Sentinel节点集合会将原来的主节点更新为从节点,并保持着对其关注,当其恢复后命令它去复制新的主节点

数据丢失

  • 主备切换时,master异步向salve同步的命令丢失导致数据丢失
  • 网络异常,导致master暂时失联,当master重新连接上网络时,变成了slave,数据丢失

解决:拒绝客户端的写请求

哨兵集群的自动发现

通过 redis 的 pub/sub 系统实现的,每个哨兵都会往 __sentinel__ :hello 这个 channel 里发送一个消息,内容是自己的 host、ip 和 runid 还有对这个 master 的监控配置,这时候所有其他哨兵都可以消费到这个消息,并感知到其他的哨兵的存在

哨兵配置

# sentinel.conf
port 26379
sentinel monitor mymaster 172.17.0.5 6379 2

这个配置代表需要监控127.0.0.1:6379这个主节点,2代表判断主节点失败至少需要2个Sentinel节点同意,mymaster是主节点的别名

# 启动哨兵
redis-sentinel sentinel.conf

哨兵的一些配置项:

# 如果超过了down-after-milliseconds配置的时间且没有有效的回复,则判定节点不可达
sentinel down-after-milliseconds <master-name> <times>
# 用来限制在一次故障转移之后,每次向新的主节点发起复制操作的从节点个数
sentinel parallel-syncs <master-name> <nums>
# slaveof no one一直失败(例如该从节点此时出现故障),当此过程超过failover-timeout时,则故障转移失败
sentinel failover-timeout <master-name> <times>
# 主节点通信密码
sentinel auth-pass <master-name> <password>
# 当一些警告级别的Sentinel事件发生(指重要事件,例如-sdown:客观下线、-odown:主观下线)时,会触发对应路径的脚本
sentinel notification-script <master-name> <script-path>
# 故障转移结束后,会触发对应路径的脚本
sentinel client-reconfig-script <master-name> <script-path>

动态调整配置: sentinel set 命令

监控多个主节点

sentinel monitor master-business-1 10.10.xx.1 6379 2
sentinel monitor master-business-2 10.16.xx.2 6380 2

屏幕截图 2020-10-07 161029

部署

  • Sentinel节点不应该部署在一台物理机器上
  • 部署至少三个且奇数个的Sentinel节点
  • 一套sentinel还是多套sentinel
    • 一套Sentinel,很明显这种方案在一定程度上降低了维护成本 但如果这套Sentinel节点集合出现异常,可能会对多个Redis数据节点造成影响
    • 多套Sentinel会造成资源浪费。但是优点也很明显,每套Redis Sentinel都是彼此隔离的

运维

节点下线:

  • 主节点下线 使用sentienl failover命令选出一个新主节点 将原来的主节点下线
  • 从节点或者sentienl节点下线 保证客户端能感受到从节点的变化 避免发送无效请求

节点上线:

  • 添加从节点 添加slaveof配置启动即可
  • 添加sentienl节点 添加sentienl monitor配置启动即可

API

# 查看所有被监控的主节点状态以及相关的统计信息
sentinel masters
# 查看指定主节点
sentinel master <master name>
# 查看指定主节点的从节点
sentinel slaves <master name>
# 列出指定的主从集群sentinel节点(不包含本节点)
sentinel sentinels <master name>
# 返回指定的主节点地址和端口
sentinel get-master-addr-by-name <master name>
# 对符合<pattern>(通配符风格)主节点的配置进行重置
sentinel reset <pattern>
# 强制对集群进行故障转移
sentinel failover <master name>
# 检测当前可达的Sentinel节点总数是否达到<quorum>的个数
sentinel ckquorum <master name>
# 将Sentinel节点的配置强制刷到磁盘上
sentinel flushconfig
# 取消当前sentinel节点对指定master的监控那个
sentinel remove <master name>
# 监控指定master
sentinel monitor <master name> <ip> <port> <quorum>
# Sentinel节点之间用来交换对主节点是否下线的判断
sentinel is-master-down-by-addr

客户端连接

1)遍历Sentinel节点集合获取一个可用的Sentinel节点

2)通过sentinel get-master-addr-by-name master-name这个API来获取对应主节点的相关信息

3)验证当前获取的“主节点”是真正的主节点,这样做的是为了防止获取之后主节点又发生了变化

4)保持和Sentinel节点集合的“联系”,时刻获取关于主节点的相关“信息”

Java 客户端:

JedisSentinelPool pool =
    new JedisSentinelPool("mymaster", Set.of("192.168.1.101:26379","192.168.1.101:26380","192.168.1.101:26381"));
Jedis resource = pool.getResource();
System.out.println(resource.ping());
resource.close();

results matching " "

No results matching " "

results matching " "

No results matching " "