文章目录 前言 - 单机Redis的风险与问题2. 哨兵模式2.1 哨兵简介2.2 哨兵工作原理2.2.1 阶段一: 监控阶段2.2.2 阶段二: 通知阶段2.2.3 阶段三: 故障转移阶段
前言 - 单机Redis的风险与问题
如果Redis设计成单节点, 会有如下风险:
问题1: 机器故障 现象: 硬盘故障, 系统崩溃, 造成数据丢失, 很可能对业务造成灾难性打击结论: 用户基本上会放弃使用Redis. 问题2: 容量瓶颈 现象: 内存不足, 从16G升级到64G, 从64G升级到128G, 无限升级内存. 原因是项目资金不够, 硬件条件跟不上.结论: 用户放弃使用Redis.结论就是, 为了避免单点Redis服务器故障, 准备多台服务器, 互相连通. 将数据复制多个副本保存在不同的服务器上, 连接在一起, 并保证数据是同步的. 即使有一台服务器宕机, 其他服务器依然可以继续提供服务, 实现Redis的高可用, 同事实现数据冗余备份.
上篇文章介绍了Redis的主从复制Redis主从复制工作原理就是一种解决办法, 但是主从复制也会面临主节点宕机, 无法写入数据的情况. 因此产生了哨兵模式的工作机制. 接下来我们详细介绍.
2. 哨兵模式 2.1 哨兵简介哨兵(sentinel)是一个分布式系统, 用于对主从结构中的每台服务器进行监控, 当出现故障时通过投票机制选择新的master并将所有slave连接到新的master.
哨兵的作用
注意: 哨兵也是多台redis服务器, 只是不提供数据服务, 通常哨兵配置数量为单数.
2.2 哨兵工作原理哨兵的作用就是监控Redis集群, 一旦Redis主节点宕机了, 需要将从节点选一个主节点, 哨兵在进行主从切换过程中经历三个阶段.
监控通知故障转移 2.2.1 阶段一: 监控阶段哨兵节点用于同步各个节点的状态
哨兵连接主节点, 查看是否存活.获取master的转态 master属性 runidrole: master 获取所有slave的转态(根据master中的slave信息) slave属性 runidrole: slavemaster_host, master_portoffset… 哨兵连接从节点, 查看从节点是否存活哨兵集群内部也要互相通信, 也就是哨兵集群之间也会有自己的朋友圈, 哨兵-1会把消息同步给其他哨兵, 其他哨兵也会去连接主从节点. 2.2.2 阶段二: 通知阶段通知阶段主要的目的就是哨兵定期发送消息到Redis主从节点, 同时哨兵集群内部也要同步消息, 保证每个哨兵节点存储的redis集群消息是一致的.
sentinel1(哨兵节点1)发送消息到主从节点, 观察redis集群健康转态哨兵1将得到的健康状态同步到哨兵2,哨兵3哨兵2也会去重复哨兵1的动作, 发送消息到主从节点, 并同步给其他哨兵节点2.2.3 阶段三: 故障转移阶段 发现问题 哨兵-1 发送消息到master, 如果没有得到回复, 则把master标记为主观下线.哨兵-1把master挂了的消息同步给哨兵-2, 哨兵-3, 然后哨兵-2和哨兵-3也发送消息到master确认是否能连通. 如果3个哨兵中超过一半也就是2个哨兵认为master挂了, 那么master就被标记为客观下线了.
哨兵集群内部竞选负责人, 负责人负责选出新的master. 哨兵集群内部会进行投票选举, 类似于zk的选举机制, 选出哨兵负责人 哨兵负责人优选新的master 肯定要挑选在线的服务器剔除响应慢的服务器剔除与原master断开时间久的服务器剩下的就采用优先原则了 offset偏移量小的runid小的 新master上任, 其他slave切换master, 原master作为slave故障恢复后连接新master.