Redis集群模式之哨兵模式工作原理

ゞ浴缸里的玫瑰 2022-08-31 04:42 2阅读 0赞

### 文章目录 ###

*  前言 - 单机Redis的风险与问题
 *  2. 哨兵模式
 *   *  2.1 哨兵简介
     *  2.2 哨兵工作原理
     *   *  2.2.1 阶段一: 监控阶段
         *  2.2.2 阶段二: 通知阶段
         *  2.2.3 阶段三: 故障转移阶段

--------------------

# 前言 - 单机Redis的风险与问题 #

如果Redis设计成单节点, 会有如下风险:

*  问题1: 机器故障
    
    1.  现象: 硬盘故障, 系统崩溃, 造成数据丢失, 很可能对业务造成灾难性打击
    2.  结论: 用户基本上会放弃使用Redis.
 *  问题2: 容量瓶颈
    
    1.  现象: 内存不足, 从16G升级到64G, 从64G升级到128G, 无限升级内存. 原因是项目资金不够, 硬件条件跟不上.
    2.  结论: 用户放弃使用Redis.

结论就是, 为了避免单点Redis服务器故障, 准备多台服务器, 互相连通. 将数据复制多个副本保存在不同的服务器上, 连接在一起, 并保证数据是同步的. 即使有一台服务器宕机, 其他服务器依然可以继续提供服务, 实现Redis的高可用, 同事实现数据冗余备份.

上篇文章介绍了Redis的主从复制[Redis主从复制工作原理][Redis]就是一种解决办法, 但是主从复制也会面临主节点宕机, 无法写入数据的情况. 因此产生了哨兵模式的工作机制. 接下来我们详细介绍.

# 2. 哨兵模式 #

## 2.1 哨兵简介 ##

哨兵(sentinel)是一个分布式系统, 用于对主从结构中的每台服务器进行监控, 当出现故障时通过投票机制选择新的master并将所有slave连接到新的master.

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70_pic_center]  
哨兵的作用

*  监控
    
    1.  不断的检查master和slave是否正常运行.
    2.  master存活检测, master与slave运行情况检测.
 *  通知(提醒)
    
    1.  当被监控的服务器出现问题时, 向其他(哨兵间, 客户端)发送通知.
 *  自动故障转移
    
    1.  断开master与slave连接, 选取一个slave作为master, 将其他slave连接到新的master, 并告知客户端新的服务器地址.

注意: 哨兵也是多台redis服务器, 只是不提供数据服务, 通常哨兵配置数量为单数.

## 2.2 哨兵工作原理 ##

哨兵的作用就是监控Redis集群, 一旦Redis主节点宕机了, 需要将从节点选一个主节点, 哨兵在进行主从切换过程中经历三个阶段.

*  监控
 *  通知
 *  故障转移

### 2.2.1 阶段一: 监控阶段 ###

哨兵节点用于同步各个节点的状态

*  哨兵连接主节点, 查看是否存活.
 *  获取master的转态
    
     *  master属性
        
         *  runid
         *  role: master
 *  获取所有slave的转态(根据master中的slave信息)
    
     *  slave属性
        
         *  runid
         *  role: slave
         *  master\_host, master\_port
         *  offset
         *  …
 *  哨兵连接从节点, 查看从节点是否存活
 *  哨兵集群内部也要互相通信, 也就是哨兵集群之间也会有自己的朋友圈, 哨兵-1会把消息同步给其他哨兵, 其他哨兵也会去连接主从节点.

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70_pic_center 1]

### 2.2.2 阶段二: 通知阶段 ###

通知阶段主要的目的就是哨兵定期发送消息到Redis主从节点, 同时哨兵集群内部也要同步消息, 保证每个哨兵节点存储的redis集群消息是一致的.

*  sentinel1(哨兵节点1)发送消息到主从节点, 观察redis集群健康转态
 *  哨兵1将得到的健康状态同步到哨兵2,哨兵3
 *  哨兵2也会去重复哨兵1的动作, 发送消息到主从节点, 并同步给其他哨兵节点  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]

### 2.2.3 阶段三: 故障转移阶段 ###

*  发现问题
    
    1.  哨兵-1 发送消息到master, 如果没有得到回复, 则把master标记为**主观下线**.
    2.  哨兵-1把master挂了的消息同步给哨兵-2, 哨兵-3, 然后哨兵-2和哨兵-3也发送消息到master确认是否能连通. 如果3个哨兵中超过一半也就是2个哨兵认为master挂了, 那么master就被标记为**客观下线**了.  
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]
 *  哨兵集群内部竞选负责人, 负责人负责选出新的master.
    
     *  哨兵集群内部会进行投票选举, 类似于zk的选举机制, 选出哨兵负责人
 *  哨兵负责人优选新的master
    
     *  肯定要挑选在线的服务器
     *  剔除响应慢的服务器
     *  剔除与原master断开时间久的服务器
     *  剩下的就采用优先原则了
        
         *  offset偏移量小的
         *  runid小的
 *  新master上任, 其他slave切换master, 原master作为slave故障恢复后连接新master.

[Redis]: https://blog.csdn.net/weixin_42641909/article/details/106551395
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20220829/5e8a5825e6a0460088390721c3207c49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20220829/12f0799b23094c4f8340e082757148c0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]: /images/20220829/0bcc6331fb2941c4beb52f3e916d5a7c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]: /images/20220829/83735310b0ce4961a75fc15564d54e3a.png