Redis【二】Redis哨兵模式原理

Redis【一】Redis主从复制原理
Redis【二】Redis哨兵模式原理

Redis的高可用实现方案现在官方的有redis-sentinel redis-cluster都是直连（非代理模式）

redis-sentinel 是主从模式，同一时间只有一个master实例可以写，其他从节点是只读的，如果master节点宕机，redis-sentinel之间会通过raft协议选举出一个负责故障迁移的主redis-sentinel，这个主redis-sentinel负责选择一个slave redis节点作为master，设置其他slave的master为这个新的master
redis-cluster 是集群、分片加主从模式

1. redis-sentinel拓扑结构图

redis-sentinel拓扑结构图

如上图所示，sentinel是在正常的redis主从配置的基础上，通过监控redis节点的健康状况，实现自动化的主从切换。如果master节点挂掉了，sentinel会及时的发现，自动化的设置新的master，并把其他的slave指向新的master。
Sentinel本质上也是一个Redis节点，但是仅支持部分命令

redis-sentinel基本配置

port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

其中最主要的配置是sentinel monitor mymaster 127.0.0.1 6379 2，格式为sentinel monitor {masterMame} {masterIP} {masterPort} {quorum}

masterName 是当sentinel同时监控多套redis主从的时候区分不同的主从的。
masterIP masterPort 是监控的Redis实例中master的IP和port，sentinel通过该master可以获取其他所有的slave实例和sentinel节点
quorum 用于故障发现和判定，如果quorum=2，则代表至少2个Sentinel节点认为主节点不可达，这个不可达的判定才是客观的。一般设置为 {sentinel实例个数}/2 + 1

redis-sentinel的3个定时任务

每隔10秒，向Redis master和slave节点发送info命令获取最新的拓扑结构
通过解析info命令中的Replication信息，sentinel就可以获取到所有的最新的master和slave节点，这也是为什么sentinel配而不需要显示的配置slave节点。

定期向Redis master和slave节点发送info命令

每隔2秒，向master节点的sentinel:hello 频道上publish该sentinel节点对于主节点的判断以及当前sentinel节点的信息，同时每个sentinel节点也会订阅该频道，来了解其他sentinel节点以及它们对主节点的判断。所以这个定时任务可以完成以下两个工作：

sentinel节点之间互相发现，每个sentinel节点上只配置了redis master节点，通过这种方式，sentinel节点之间就可以实现互相发现。来实现后续的sentinel节点之间的互相通信、选举操作

sentinel节点之间交换主节点状态，作为后面客观下线以及领导者选举的依据。
sentinel节点publish的消息格式如下：
{sentinel节点IP} {sentinel节点端口} {sentinel节点runId} {sentinel节点配置版本} {主节点名字} {主节点IP} {主节点Port} {主节点配置版本}，示例：

10.xx.xx.xx,26379,811ee2bc21cfc21e6aea0da3ed90f80deeod91kc,1530,mymaster,10.xx.xx.xx,6379,1530

每隔2秒向master publish当前sentinel的状态

每隔1秒，会向master、slave节点、其余sentinel节点发送ping命令做一次心跳检测，来确认这些节点当前是否可达。sentinel就是基于这个ping命令来决定redis节点和sentinel节点是否活着。

每隔1秒向master、slave节点以及其他sentinel节点发送ping

2. redis-sentinel故障迁移流程

主观下线和客观下线

主观下线
上面介绍的sentinel的第三个定时任务每秒对其他的节点ping一次，如果这个节点超过down-after-milliseconds没有有效的回复，该sentinel节点就会对这个节点做失败判定，这个行为是主观下线。由此可见主观下线只是单个sentinel的判定行为，在分布式环境中，肯定不能只靠一个节点的判断。
客观下线
当sentinel主观下线的节点是master时，该sentinel就会向其他sentinel节点发送sentinel is-master-down-by-addr命令询问对主节点的判断，当超过{quorum}个数sentinel节点认为主节点确实有问题，这时该sentinel会做出客观下线的决定。

leader选举

sentinel做出客观下线的决定之后并不会立即进行故障转移，而是要在sentinel之间选举出一个leader，由leader来执行具体的故障转移工作。
其实在上面的客观下线中，sentinel发送sentinel is-master-down-by-addr命令的时候就已经包含了leader选举的一些信息。
sentinel is-master-down-by-addr {故障masterIP} {故障masterPort} {downState} {leader_runid}

downState：1是下线、0是在线
leader_runid：如果为*，表示返回结果只是用来表示主节点是否可达，当leader_runid等于具体的runid时，就代表目标节点同意runid称为leader

故障转移

上面选择出一个sentinel作为leader之后，该leader就会开始操作故障转移，具体步骤如下：

从所有slave中选出一个slave作为新的master，选择方法如下图所示：

选取从节点过程
sentinel leader对选择出来的master执行slaveof no one命令让其成为真正的master
sentinel leader对其他slave发送命令，让它们成为新master的slave，新的slave的复制规则与parallel-syncs（同时允许多少个slave执行sync操作）的配置有关系
sentinel leader将原来的master更新为slave，并保持对其监控，当它恢复后命令它去复制新的master

3. redis-sentinel客户端逻辑

实现一个Redis Sentinel客户端的基本步骤如下：

遍历sentinel节点集合获取一个可用的sentinel节点，对sentinel节点调用sentinel get-master-addr-by-name master这个API来获取对应主节点的相关信息
sentinel客户端订阅sentinel的swtich-master事件，如果master有变更，需要更新redis连接。
sentinel客户端如果是维护的连接池，在获取连接的时候要检查该连接是否与最新的master是一致的，如果不一致就要销毁该连接，重新获取。

redis.clients.jedis.JedisSentinelPool

private HostAndPort initSentinels(Set sentinels, final String masterName) {

    HostAndPort master = null;
    boolean sentinelAvailable = false;

    log.info("Trying to find master from available Sentinels...");
    // 遍历sentinel节点，尝试获取master节点
    for (String sentinel : sentinels) {
      final HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":")));

      log.fine("Connecting to Sentinel " + hap);

      Jedis jedis = null;
      try {
        jedis = new Jedis(hap.getHost(), hap.getPort());
        // 从sentinel获取master节点
        List masterAddr = jedis.sentinelGetMasterAddrByName(masterName);

        // connected to sentinel...
        sentinelAvailable = true;

        if (masterAddr == null || masterAddr.size() != 2) {
          log.warning("Can not get master addr, master name: " + masterName + ". Sentinel: " + hap
              + ".");
          continue;
        }

        master = toHostAndPort(masterAddr);
        log.fine("Found Redis master at " + master);
        break;
      } catch (JedisException e) {
        ...
      } finally {
        if (jedis != null) {
          jedis.close();
        }
      }
    }

    ...

    for (String sentinel : sentinels) {
      final HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":")));

      // MasterListener会订阅sentinel节点的swatich-master渠道，如果master有变更，就会执行initPool操作
      MasterListener masterListener = new MasterListener(masterName, hap.getHost(), hap.getPort());
      // whether MasterListener threads are alive or not, process can be stopped
      masterListener.setDaemon(true);
      masterListeners.add(masterListener);
      masterListener.start();
    }

    return master;
  }
// 根据最新的master更新线程池中的jedis连接
private void initPool(HostAndPort master) {
    if (!master.equals(currentHostMaster)) {
      currentHostMaster = master;
      if (factory == null) {
        factory = new JedisFactory(master.getHost(), master.getPort(), connectionTimeout,
            soTimeout, password, database, clientName);
        initPool(poolConfig, factory);
      } else {
        factory.setHostAndPort(currentHostMaster);

        // clear操作只会destroy idle状态的jedis连接，不会释放正在使用的jedis连接。所以需要在getResource的时候再次做检查
        internalPool.clear();
      }

      log.info("Created JedisPool to master at " + master);
    }
  }
// 从连接池中获取一个连接
public Jedis getResource() {
    while (true) {
      Jedis jedis = super.getResource();
      jedis.setDataSource(this);

      // get a reference because it can change concurrently
      final HostAndPort master = currentHostMaster;
      final HostAndPort connection = new HostAndPort(jedis.getClient().getHost(), jedis.getClient()
          .getPort());
       // 检查当前连接的master与最新的master是否相同，如果相同就可以直接返回
      if (master.equals(connection)) {
        return jedis;
      } else {
        // 如果master不正确，就把该jedis连接返回给连接池，重新尝试从连接池获取
        returnBrokenResource(jedis);
      }
    }
  }