Redis哨兵架构（哨兵搭建，哨兵原理）

Crypto丶三余

已于 2022-03-21 17:16:02 修改

阅读量1.9k

点赞数

分类专栏： Redis 文章标签： redis

于 2022-03-09 00:52:34 首次发布

本文链接：https://blog.csdn.net/mj879158775/article/details/123343823

版权

Redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Redis哨兵架构（哨兵搭建，哨兵原理）

一、Redis哨兵架构搭建
二、Java中使用哨兵架构
三、哨兵机制原理

sentinel哨兵是特殊的Redis服务，不提供读写服务，主要用来监控redis实例节点，实现自动故障转移

一、Redis哨兵架构搭建

基于主从架构搭建一主两从架构
准备开启三个哨兵节点，这里演示安装26379
复制sentinel.conf到26379目录下（目录自己指定）
修改sentinel.conf配置

port 26379

daemonize yes

pidfile "/var/run/redis‐sentinel‐26379.pid"

logfile "26379.log"

dir "/usr/local/redis/26379/"

# sentinel monitor <master‐redis‐name> <master‐redis‐ip> <master‐redis‐port> <quorum>
# quorum是一个数字，指明当有多少个seninel（值一般为：sentinel总数/2+1）认为一个master失效时master才算失效
# mymaster 自己定义，客户端访问时需要
sentinel monitor mymaster 192.168.1.110 6379 2

启动哨兵实例

./bin/redis-sentinel ./26379/sentinel/sentinel.conf
./bin/redis-sentinel ./26380/sentinel/sentinel.conf
./bin/redis-sentinel ./26381/sentinel/sentinel.conf

查看哨兵是否启动成功
info命令查看哨兵信息
查看sentinel.conf中的redis节点信息

二、Java中使用哨兵架构

哨兵架构模式中，客户端访问Redis服务，第一次从哨兵服务中获取Redis主节点信息，后续就会直接访问主节点，不会再通过哨兵代理访问，当主节点发送变化后，哨兵会立即将新的主节点信息通知客户端（客户端一般都订阅了哨兵发布的节点变动信息）

引入依赖

<dependency>
   <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>22.0</version>
</dependency>
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13.2</version>
    <!-- <scope>test</scope>-->
</dependency>

测试代码

/**
 * Jedis连接哨兵架构
 */
public class JedisSentinelTest {

    JedisSentinelPool jedisSentinelPool = null;

    @Before
    public void connect(){
        JedisPoolConfig config = new JedisPoolConfig();
        config.setMaxTotal(20);
        config.setMaxIdle(10);
        config.setMinIdle(5);

        String masterName = "mymaster";

        Set<String> sentinels = new HashSet<>();
        sentinels.add(new HostAndPort("192.168.1.110",26379).toString());
        sentinels.add(new HostAndPort("192.168.1.110",26380).toString());
        sentinels.add(new HostAndPort("192.168.1.110",26381).toString());

        jedisSentinelPool = new JedisSentinelPool(masterName,sentinels,config,3000,null);

    }

    @Test
    public void testSentinel(){
        Jedis jedis = null;

        try {
            jedis=jedisSentinelPool.getResource();
            System.out.println(jedis.set("sentinel","1"));
            System.out.println(jedis.get("sentinel"));
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedis!=null){
                jedis.close();
            }
        }
    }
}

运行结果

三、哨兵机制原理

1. 哨兵机制解决了什么问题

哨兵主要是为了解决主从复制架构中出现宕机的情况，在主节点出现宕机时，哨兵会自动将主节点下的某个从节点升级为新的主节点

2. 哨兵定时监控

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图，哨兵配置时只需要配置对主节点的监控即可，通过向主节点发送info命令，获取从节点的信息，并且当有新的从节点时可以立马感知到
每个哨兵节点每2秒会像redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其他哨兵对主节点状态的判断，其实就是通过消息publish/subscribe来完成的
每一秒每个哨兵会向主节点，从节点，其他哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

3. 主观下线与客观下线

3.1 主观下线

主观下线就是单个哨兵认为某个节点下线

哨兵会以每秒一次的频率向所有与其建立连接的实例（主节点，从节点，其他哨兵节点）发送ping命令，通过判断ping回复是否有效，还是无效来判断实例是否在线

3.2 客观下线

当主观下线的节点是主观节点时，认为主节点主观下线的哨兵节点会通过指令sentinel is-masterdown-by-addr寻求其他哨兵节点对主节点的判断，当主观下线的个数超过quorum个数，此时大部分哨兵节点会都同意下线，这就是客观下线

4. 哨兵leader选举流程

主节点被判定为客观下线后，就需要选取一个哨兵节点来完成故障转移的工作，选举哨兵leader的流程如下：

每个在线的哨兵节点都可以成为leader，当它确认主节点下线后，会向其他哨兵发送is-master-down-by-addr命令，征求判断并要求把自己设置为leader
其他哨兵接收到这个命令后，可以同意或者拒绝它成为领导者
如果哨兵发现自己在选举的过程中的票数大于等于（sentinel/2 +1）时，它将成为leader，如果没有，继续选举