Redis系列之——哨兵

Posted 11014p

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis系列之——哨兵相关的知识,希望对你有一定的参考价值。

转:https://www.jianshu.com/p/74c4017d57ef

一、Redis Sentinel

Redis Sentinel是一个分布式架构(建议使用2.8以上版本),其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方,从而实现真正的高可用。


 
技术图片
故障转移

 
技术图片
故障转移

Redis Sentinel包含了若个Sentinel节点,对于节点的故障判断是由多个Sentinel节点共同完成,这样可以有效地防止误判。同时,即使个别Sentinel节点不可用,整个Sentinel节点集合依然是健壮的。(生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。)

•监控:Sentinel节点会定期检测Redis数据节点、其余Sen-tinel节点是否可达。  
•通知:Sentinel节点会将故障转移的结果通知给应用方。   
•主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。   
•配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节点集合,从中获取主节点信息。

1、配置与部署

配置说明

#配置Sentinel节点
redis-sentinel-26379.conf
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 

#启动
redis-sentinel redis-sentinel-26379.conf

#确认
$ redis-cli -h 127.0.0.1 -p 26379 info Sentinel
#Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
sentinel monitor <master-name> <ip> <port> <quorum> 

Sentinel节点会对所有节点进行监控,但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置,那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。
<quorum>参数用于故障发现和判定,例如将quorum配置为2,代表至少有2个Sentinel节点认为主节点不可达,那么这个不可达的判定才是客观的。对于<quorum>设置的越小,那么达到下线的条件越宽松,反之越严格。一般建议将其设置为Sentinel节点的一半加1。同时<quorum>还与Sentinel节点的领导者选举有关,至少要max(quorum,num(sentinels)/2+1)个Sentinel节点参与选举,才能选出领导者Sentinel。

sentinel down-after-milliseconds <master-name> <times>

每个Sentinel节点都要通过定期发送ping命令来判断Re-dis数据节点和其余Sentinel节点是否可达,如果超过了down-after-milliseconds配置的时间且没有有效的回复,则判定节点不可达,<times>(单位为毫秒)就是超时时间。
down-after-milliseconds越大,代表Sentinel节点对于节点不可达的条件越宽松,反之越严格。条件宽松有可能带来的问题是节点确实不可达了,那么应用方需要等待故障转移的时间越长,也就意味着应用方故障时间可能越长。条件严格虽然可以及时发现故障完成故障转移,但是也存在一定的误判率。

sentinel parallel-syncs <master-name> <nums>

parallel-syncs就是用来限制在一次故障转移之后,每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大,那么多个从节点会向新的主节点同时发起复制操作,尽管复制操作通常不会阻塞主节点,但是同时向主节点发起复制,必然会对主节点所在的机器造成一定的网络和磁盘IO开销。

sentinel failover-timeout <master-name> <times>

failover-timeout通常被解释成故障转移超时时间,但实际上它作用于故障转移的各个阶段:
a)选出合适从节点。
b)晋升选出的从节点为主节点。
c)命令其余从节点复制新的主节点。
d)等待原主节点恢复后命令它去复制新的主节点。
上面任一阶段超过failover-timeout时间则故障转移失败,如果Redis Sentinel对一个主节点故障转移失败,那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。

部署技巧
Sentinel节点不应该部署在一台物理“机器”上。
部署至少三个且奇数个的Sentinel节点。
只有一套Sentinel,还是每个主节点配置一套Sentinel。(前者维护方便,后者可用性更高)

2、Redis Sentinel API与客服端

API:

#主节点信息
127.0.0.1:26379> sentinel master mymaster-1 
1) "name" 
2) "mymaster-1" 
3) "ip" 
4) "127.0.0.1" 
5) "port" 
6) "6379"

#从节点信息
127.0.0.1:26379> sentinel slaves mymaster-11)  
1) "name"    
2) "127.0.0.1:6380"    
3) "ip"    
4) "127.0.0.1"    
5) "port"    
6) "6380"
.........忽略............

#哨兵信息
127.0.0.1:26379> sentinel sentinels mymaster-1
1) "name"    
2) "127.0.0.1:26380"    
3) "ip"    
4) "127.0.0.1"    
5) "port"   
 6) "26380"
.........忽略............

#获取主节点ip+port
127.0.0.1:26379> sentinel get-master-addr-by-name mymaster-1
1) "127.0.0.1"
2) "6379"

#强制故障转移,运维节点故障时且无法自动转移使用
127.0.0.1:26379> sentinel  failover mymaster-2
OK

#检测当前可达的Sentinel节点总数是否达到<quorum>的个数
127.0.0.1:26379> sentinel ckquorum mymaster-1
OK 3 usable Sentinels. Quorum and failover authorization can be reached

Redis Sentinel客户端在初始化和切换主节点时需要和Sentinel节点集合进行交互来获取主节点信息。
1)遍历Sentinel节点集合获取一个可用的Sentinel节点(Sentinel节点之间可以共享数据),从任意一个Sentinel节点获取主节点信息都是可以的。
2)通过sentinel get-master-addr-by-name master-name这个API来获取对应主节点的相关信息。
3)验证当前获取的“主节点”是真正的主节点,这样做的目的是为了防止故障转移期间主节点的变化。

#JedisSentinelPool
public class JedisSentinelPool extends Pool<Jedis> {

  //按照common-pool的标准模式
  protected GenericObjectPoolConfig poolConfig;

  protected int connectionTimeout = Protocol.DEFAULT_TIMEOUT;
  protected int soTimeout = Protocol.DEFAULT_TIMEOUT;

  protected String password;

  protected int database = Protocol.DEFAULT_DATABASE;

  protected String clientName;

  protected Set<MasterListener> masterListeners = new HashSet<MasterListener>();

  private volatile JedisFactory factory;

  private volatile HostAndPort currentHostMaster;

  public HostAndPort getCurrentHostMaster() {

  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);
        internalPool.clear();
      }
      log.info("Created JedisPool to master at " + master);
    }
  }

 #初始化哨兵节点和获取主节点
  private HostAndPort initSentinels(Set<String> sentinels, final String masterName) {

    HostAndPort master = null;
    boolean sentinelAvailable = false;
    log.info("Trying to find master from available Sentinels...");
    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 get-master-addr-by-name masterName获取主节点信息        
        List<String> masterAddr =  jedis.sentinelGetMasterAddrByName(masterName);
        // connected to sentinel...
        sentinelAvailable = true;
        // 命令返回列表为空或者长度不为2,继续从下一个sentinel节点查询
        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) {
        log.warning("Cannot get master address from sentinel running @ " + hap + ". Reason: " + e
            + ". Trying next one.");
      } finally {
        if (jedis != null) {
          jedis.close();
        }
      }
    }
    if (master == null) {
      if (sentinelAvailable) {
        throw new JedisException("Can connect to sentinel, but " + masterName
            + " seems to be not monitored...");
      } else {
        throw new JedisConnectionException("All sentinels down, cannot determine where is "
            + masterName + " master is running...");
      }
    }
    log.info("Redis master running at " + master + ", starting Sentinel listeners...");
    for (String sentinel : sentinels) {
      final HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":")));
      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;
  }

  #订阅主节点信息
  protected class MasterListener extends Thread {

    protected String masterName;
    protected String host;
    protected int port;
    protected long subscribeRetryWaitTimeMillis = 5000;
    protected volatile Jedis j;
    protected AtomicBoolean running = new AtomicBoolean(false);

    protected MasterListener() {

    public MasterListener(String masterName, String host, int port) {

    public MasterListener(String masterName, String host, int port,

    public void run() {

      running.set(true);

      while (running.get()) {

        j = new Jedis(host, port);

        try {
          // double check that it is not being shutdown
          if (!running.get()) {
            break;
          }

          j.subscribe(new JedisPubSub() {
            @Override
            public void onMessage(String channel, String message) {
              log.fine("Sentinel " + host + ":" + port + " published: " + message + ".");

              String[] switchMasterMsg = message.split(" ");

              if (switchMasterMsg.length > 3) {

                if (masterName.equals(switchMasterMsg[0])) {
                  initPool(toHostAndPort(Arrays.asList(switchMasterMsg[3], switchMasterMsg[4])));
                } else {
                  log.fine("Ignoring message on +switch-master for master name "
                      + switchMasterMsg[0] + ", our master name is " + masterName);
                }

              } else {
                log.severe("Invalid message received on Sentinel " + host + ":" + port
                    + " on channel +switch-master: " + message);//订阅Sentinel节点的+switch-master频道
              }
            }
          }, "+switch-master");

        } catch (JedisConnectionException e) {

          if (running.get()) {
            log.log(Level.SEVERE, "Lost connection to Sentinel at " + host + ":" + port
                + ". Sleeping 5000ms and retrying.", e);
            try {
              Thread.sleep(subscribeRetryWaitTimeMillis);
            } catch (InterruptedException e1) {
              log.log(Level.SEVERE, "Sleep interrupted: ", e1);
            }
          } else {
            log.fine("Unsubscribing from Sentinel at " + host + ":" + port);
          }
        } finally {
          j.close();
        }
      }
    }

    public void shutdown() {
  }
}

3、Redis Sentinel 原理

通过三个定时任务监控reids节点状态

1)每隔10秒,每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。
2)每隔2秒,每个Sentinel节点会向Redis数据节点的__sentinel__:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息。
Sentinel节点之间交换主节点的状态,作为后面客观下线以及领导者选举的依据。
3)每隔1秒,每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测,来确认这些节点当前是否可达。
 
技术图片
1.png
 
技术图片
2.png

 

 
技术图片
3.png

主观下线和客观下线
主观下线。
每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测,当这些节点超过down-after-milliseconds没有进行有效回复,Sentinel节点就会对该节点做失败判定,这个行为叫做主观下线。
客观下线
当Sentinel主观下线的节点是主节点时,该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断,当超过<quorum>个数,Sentinel节点认为主节点确实有问题,这时该Sentinel节点会做出客观下线的决定,这样客观下线的含义是比较明显了,也就是大部分Sentinel节点都对主节点的下线做了同意的判定,那么这个判定就是客观的。
领导者Sentinel节点选举
故障转移的工作只需要一个Sentinel节点来完成即可,所以Sentinel节点之间会做一个领导者选举的工作,选出一个Sentinel节点作为领导者进行故障转移的工作(Redis使用了Raft算法实现领导者选举)。
 
技术图片
领导者Sentinel节点选举.png

如果该Sentinel节点发现自己的票数已经大于等于max(quorum,num(sentinels)/2+1),那么它将成为领导者。如果此过程没有选举出领导者,将进入下一次选举。
故障转移
具体步骤如下:
1)在从节点列表中选出一个节点作为新的主节点,选择方法如下:
a)过滤:“不健康”(主观下线、断线)、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过down-after-mil-liseconds*10秒。
b)选择slave-priority(从节点优先级)最高的从节点列表,如果存在则返回,不存在则继续。
c)选择复制偏移量最大的从节点(复制的最完整),如果存在则返回,不存在则继续。
d)选择runid最小的从节点。
2)Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
3)Sentinel领导者节点会向剩余的从节点发送命令,让它们成为新主节点的从节点,复制规则和parallel-syncs参数有关。
4)Sentinel节点集合会将原来的主节点更新为从节点,并保持着对其关注,当其恢复后命令它去复制新的主节点。
 
技术图片
故障转移.png

以上是关于Redis系列之——哨兵的主要内容,如果未能解决你的问题,请参考以下文章

redis系列之主从复制与哨兵机制

Redis系列之——哨兵

Redis进阶高可用之哨兵

Redis数据库系列Redis哨兵模式

redis系列:哨兵

Spring之redis主从复制(非哨兵模式)