Sentinel（哨兵）

Posted 2023-05-02

参考技术A     Redis主从复制模式下，一旦主节点（主服务器）由于故障不能提供服务，需要人工将节点晋升为主节点，同时还要通知应用方更新主节点的地址，然而应用方无法及时感知到主节点的变化，必然会造成一定的写数据丢失和读数据错误，所以这是在大多数情况是无法接受的。所以Redis提供了一种高可用的解决方法——哨兵。

    Sentinel是Redis的高可用解决方案： 由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态下时，自动将下线主服务器属下的某个从服务器升级为主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。如果下线的主服务器重新连接上线的话，它会被Sentinel系统降级为新主服务器的从服务器。 而这些过程完全是自动的，不需要人工介。

    下面介绍Sentinel系统的具体工作过程。

    Sentinel只是一个运行在特殊模式下的Redis服务器，其本身就是独立的Redis节点，只不过它不存储数据，只支持部分命令。

    Sentinel会读入用户指定的配置文件，为每个要被监视的主服务器创建相应的实例结构保存在Sentinel状态（服务器初始化的一个sentinel结构，用于保存服务器中所有和Sentinel功能有关的状态）的masters属性中。并创建连向主服务器的网络连接，Sentinel将成为主服务器的客户端，并从命令回复中获取相关信息。

    对于每个被Sentinel监视的主服务器来说，Sentinel会创建两个连向主服务器的异步网络连接：

    1) 一个是命令连接，这个连接专门用于向主服务器的网络连接，并接受命令。

    2) 另一个是订阅连接，这个连接专门用于订阅主服务器的_sentinel_:hello频道。

  Sentinel默认每10秒一次的频率，通过命令连接向被 监视的主服务器发送 INFO 命令，并通过 INFO 命令的回复来获取主服务器以下的信息：

    (1) 服务器本身的信息，包括运行ID以及服务器的角色（role）；

    (2) 主服务属下的所有从服务器信息，包括从服务器的IP地址，端口号。 根据这些IP和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器。

    Sentinel根据这些获取的信息对主服务的实例结构进行更新。

    对于上图，Sentinel将分别为3个从服务器创建各自的实例结构，并将这些实例结构保存主服务器实例结构的slaves属性里。

    当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构外，Sentinel还会为创建连接到从服务器的命令连接和订阅连接。

        在创建命令连接之后， Sentinel在默认情况下， 会以每10秒 一次的频率通过命令连接向从服务器发送 INFO 命令，并获取从服务器的回复信息，包括从服务器运行ID、从服务器的角色，主服务器的IP和端口、从服务的优先级等。根据这些信息对从服务器实例结构进行更新。

    在默认情况下，Sentinel会以每2秒一次的频率，通过命令连接向所有被监听的主服务器和从服务器的_sentinel_ hello频道发送一条消息。消息的信息包括Sentinel本身的信息和对主服务器判断的信息。

    当Sentinel与一个主服务器或者从服务器建立起订阅连接之后， Sentinel就会通过订阅连接， 向服务器发送以下命令：SUBSCRIBE _sentinel_:hello 。

    Sentinel对_sentinel_:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。

    这也就是说， 对于每个与Sentinel连接的服务器， Sentinel既通过命令连接向服务器的 sentinel_:hello频道发送信息， 又通过订阅连接从服务器的 sentinel :hello 频道接收信息。

    对于监视同一个服务器的多个Sentinel 来说， 一个Sentinel发送的信息会被其他 Sentinel接收到， 这些信息会被用于更新其他Sentinel对发送信息Sentinel的认知 ，也会被用于更新其他Sentinel对被监视服务器的认知。

    举个例子， 假设现在有sentinel1、sentinel 2、sentinel 3三个Sentinel在监视同一个服务器， 那么当sentinel1向服务器的_sentinel_:hello频道发送一条信息时，所有订阅了_sentinel_:hello频道的Sentinel（包括sentinel1自己在内）都会收到这条信息。

    当一个Sentinel从_sentinel_:hello频道收到一条信息时，Sentinel会对这条信息进行分析，提取出信息中的Sentinel IP地址、端口号、Sentinel运行ID等参数，并作以下检查：

    **如果信息中记录的Sentinel运行ID和接收信息中Sentinel的运行ID 相同，说明这条信息是Sentinel自己发送的，Sentinel将丢弃这条信息，不做进一步处理。

    **如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID不相同，那么说明这条信息是监视同一个服务器的其他Sentinel发来的， 接收信息的Sentinel 将根据信息中的各个参数， 对相应主服务器的实例结构进行更新。

    这里的更新包括：主服务sentinels属性的更新和创建连向其他Sentinel命令连接

    (1)  Sentinel为主服务器创建的实例结构中的sentinels属性保存了除Sentinel本身之外，所有同样监视这个主服务器的其他Sentinel的资料。当一个Sentinel接收到其他Sentinel发来的信息时（我们称呼发送信息的Sentinel为源Sentinel, 接收信息的Sentinel为目标Sentinel），根据信息中提取出主服务器参数，目标Sentinel会在自己的Sentinel状态的masters字典中查找相应的主服务器实例结构， 然后根据提取出的Sentinel参数，检查主服务器实例结构的sentinels中，源Sentinel的实例结构是否存在：

    因为一个Sentinel可以通过分析接收到的频道信息来获取其他Sentinel的存在，并通过发送频道信息让其他Sentinel知道自己的存在，所以用户在使用Sentinel时不需要提供各个Sentinel的地址信息，监视同一个主服务器的多个Sentinel可以自动发现对方。

(2) 创建连向其他Sentinel命令连接

    当Sentinel通过频道信息发现一个新的Sentinel时， 它不仅会为新Sentinel在sentinels中创建相应的实例结构， 还会创建一个连向新Sentinel的命令连接， 而新Sentinel也同样会创建连向这个Sentinel的命令连接， 最终监视同一主服务器的多个Sentinel将形成相互连接的网络。

    在默认情况下，Sentinel会以 每秒一次 的频率向所有与它创建了命令的连接实例 （包括主服务器、从服务器、其他Sentinel在内），发送PING命令 ，并通过实例返回PING命令的回复判断实例是否在线，如果在规定的时间内，连续向Sentinel返回无效的回复（除了+PONG、-LOADING、-MASTERDOWN之外的回复），那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来标识这个实例已经进入了 主观下线状态 。

    当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了， 它会向同样监视这一主服务器的其他Sentinel进行询问， 看它们是否也认为主服务器已经进人了下线状态（可以是主观下线或者客观下线）。 当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后， Sentinel就会将从服务器判定为客观下线， Sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开，标识主服务器已经进入了客观下线状态。

    当一个主服务器被判断为客观下线时，监视这个下线的主服务器的各个Sentinel会进行协商，选举出以个领头Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。

    选举领头Sentinel规则和方法：

      下面两幅图表示当三个Sentinel发现主服务器已经进入客观下线状态后，为了选举出领头Sentinel，三个Sentinel将再次向其他Sentinel发送SENTINEL is-master-down-by-addr命令要求其他Sentinel将自己设置为局部领头Sentinel。根据先到先得规则，如果某个Sentinel发送的命令比其他的快，并最终胜出领头Sentinel的选举，然后这个领头Sentinel就可以开始对服务器执行故障转移操作了。

    在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤：

    (1) 选出新的主服务器

        故障转移的第一步就是在已下线主服务器属下的所有从服务器中挑选出一个状态良好、数据完成整的从服务器，然后向这个从服务器发送slave no one 命令，将这个从服务器装换为主服务器。

    下图展示在一次故障转移操作中，领头Sentinel向选中的从服务器server3发送 SLAVEOF no one 命令。

    在发送 SLAVEOF no one命令之后，领头 Sentinel会以每秒一次的频率（平时是每10秒一次），向被升级的从服服务发送INFO命令，并观察命令回复中角色（role）信息，当被升级的从服务器的role由原来的slave变为master时，领头Sentinel就知道被选中的从服务器顺利升级为主服务器了。

(2) 修改从服务器的复制目标

    当新的主服务器出现之后，领头Sentinel让已下线主服务器属下的所有从服务器去复制新的主服务器，这一动作可以通过向从服务器发送 SLAVE OF 命令来实现。

     (3) 将旧的主服务器变为从服务器

    故障转移操作最后要做的是， 将巳下线的主服务器设置为新的主服务器的从服务器。

    当serverl1重新上线时，Sentinel就会向它发送 SLAVEOF 命令，让它成为server3的从服务器。

    Redis的Sentinel实现主要包含以下几个方面： 三个定时任务、主观下线和客观下线检测、领头Sentinel的选举、故障转移。

  (1) 定时任务

  (2) 主观下线和客观下线检测

    客观下线：当Sentinel将一个主服务器判断为主观下线后，为了确认这个主服务是否真的下线了，他会向同样监视这个主服务器的所有其他Sentinel进行询问，看它们是否也认为主服务器是否进入下线状态，如果有足够多数量的Sentinel认为主服务器进入下线状态时，Sentinel就会将主服务器判定为客观下线状态。

  (3) 领头Sentinel的选举

    在主服务器被判定为客观下线后，Sentinel之间会根据一定的规则选出一个领头Sentinel，故障转移的工作就是这个领头Sentinel来完成的。

  (4) 故障转移

 注：本文参考《Redis设计与实现》，如发现错误，请指正！

Redis哨兵（Sentinel）模式

Redis哨兵（Sentinel）模式

 

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

一、哨兵模式概述

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

 

Redis哨兵

 

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

二、Redis配置哨兵模式

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

服务类型	是否是主服务器	IP地址	端口
Redis	是	192.168.11.128	6379
Redis	否	192.168.11.129	6379
Redis	否	192.168.11.130	6379
Sentinel	-	192.168.11.128	26379
Sentinel	-	192.168.11.129	26379
Sentinel	-	192.168.11.130	26379

 

多哨兵监控Redis

首先配置Redis的主从服务器，修改redis.conf文件如下

# 使得Redis服务器可以跨网络访问
bind 0.0.0.0
# 设置密码
requirepass "123456"
# 指定主服务器，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
slaveof 192.168.11.128 6379
# 主服务器密码，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
masterauth 123456

上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，copy一份进行修改

# 禁止保护模式
protected-mode no
# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，192.168.11.128代表监控的主服务器，6379代表端口，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

上述关闭了保护模式，便于测试。

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

# 启动Redis服务器进程
./redis-server ../redis.conf
# 启动哨兵进程
./redis-sentinel ../sentinel.conf

注意启动的顺序。首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

三、Java中使用哨兵模式

/**
 * 测试Redis哨兵模式
 * @author liu
 */
public class TestSentinels 
    @SuppressWarnings("resource")
    @Test
    public void testSentinel() 
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(10);
        jedisPoolConfig.setMaxIdle(5);
        jedisPoolConfig.setMinIdle(5);
        // 哨兵信息
        Set<String> sentinels = new HashSet<>(Arrays.asList("192.168.11.128:26379",
                "192.168.11.129:26379","192.168.11.130:26379"));
        // 创建连接池
        JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels,jedisPoolConfig,"123456");
        // 获取客户端
        Jedis jedis = pool.getResource();
        // 执行两个命令
        jedis.set("mykey", "myvalue");
        String value = jedis.get("mykey");
        System.out.println(value);
    

上面是通过Jedis进行使用的，同样也可以使用Spring进行配置RedisTemplate使用。

        <bean id = "poolConfig" class="redis.clients.jedis.JedisPoolConfig">
            <!-- 最大空闲数 -->
            <property name="maxIdle" value="50"></property>
            <!-- 最大连接数 -->
            <property name="maxTotal" value="100"></property>
            <!-- 最大等待时间 -->
            <property name="maxWaitMillis" value="20000"></property>
        </bean>
        
        <bean id="connectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
            <constructor-arg name="poolConfig" ref="poolConfig"></constructor-arg>
            <constructor-arg name="sentinelConfig" ref="sentinelConfig"></constructor-arg>
            <property name="password" value="123456"></property>
        </bean>
        
        <!-- JDK序列化器 -->
        <bean id="jdkSerializationRedisSerializer" class="org.springframework.data.redis.serializer.JdkSerializationRedisSerializer"></bean>
        
        <!-- String序列化器 -->
        <bean id="stringRedisSerializer" class="org.springframework.data.redis.serializer.StringRedisSerializer"></bean>
        
        <bean id="redisTemplate" class="org.springframework.data.redis.core.RedisTemplate">
            <property name="connectionFactory" ref="connectionFactory"></property>
            <property name="keySerializer" ref="stringRedisSerializer"></property>
            <property name="defaultSerializer" ref="stringRedisSerializer"></property>
            <property name="valueSerializer" ref="jdkSerializationRedisSerializer"></property>
        </bean>
        
        <!-- 哨兵配置 -->
        <bean id="sentinelConfig" class="org.springframework.data.redis.connection.RedisSentinelConfiguration">
            <!-- 服务名称 -->
            <property name="master">
                <bean class="org.springframework.data.redis.connection.RedisNode">
                    <property name="name" value="mymaster"></property>
                </bean>
            </property>
            <!-- 哨兵服务IP和端口 -->
            <property name="sentinels">
                <set>
                    <bean class="org.springframework.data.redis.connection.RedisNode">
                        <constructor-arg name="host" value="192.168.11.128"></constructor-arg>
                        <constructor-arg name="port" value="26379"></constructor-arg>
                    </bean>
                    <bean class="org.springframework.data.redis.connection.RedisNode">
                        <constructor-arg name="host" value="192.168.11.129"></constructor-arg>
                        <constructor-arg name="port" value="26379"></constructor-arg>
                    </bean>
                    <bean class="org.springframework.data.redis.connection.RedisNode">
                        <constructor-arg name="host" value="192.168.11.130"></constructor-arg>
                        <constructor-arg name="port" value="26379"></constructor-arg>
                    </bean>
                </set>
            </property>
        </bean>

四、哨兵模式的其他配置项

配置项	参数类型	作用
port	整数	启动哨兵进程端口
dir	文件夹目录	哨兵进程服务临时文件夹，默认为/tmp，要保证有可写入的权限
sentinel down-after-milliseconds	<服务名称><毫秒数（整数）>	指定哨兵在监控Redis服务时，当Redis服务在一个默认毫秒数内都无法回答时，单个哨兵认为的主观下线时间，默认为30000（30秒）
sentinel parallel-syncs	<服务名称><服务器数（整数）>	指定可以有多少个Redis服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资源要求越高
sentinel failover-timeout	<服务名称><毫秒数（整数）>	指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟
sentinel notification-script	<服务名称><脚本路径>	指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，比较常用

sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。