【Redis技术探索】「高可用架构模式」哨兵（sentinel）模式实现主从故障互切换模式详解

哨兵（sentinel）模式实现主从故障互切换模式详解

- Redis的多种模式
- - Redis单机模式
  - - Redis单机模式的优点
    - Redis单机模式的缺点
  - Redis主从复制
  - - 旧版本配置
    - 新版本配置
    - 查看主节点信息
    - 主从模式的优点
    - 主从复制的弊端
  - Redis哨兵模式
  - - 分析哨兵结构组成
    - 哨兵模式的主从切换
    - Redis哨兵模式的原理
    - 常规情况下
    - 故障切换（failover）的过程
    - Redis-Sentinel的作用
    - Redis的多哨兵运行模式
    - - 故障切换（failover）的过程
    - Redis 哨兵模式的配置
    - Redis主节点服务配置
    - - 查看配置信息
      - 重点配置
      - 跨网络访问
        设置密码
    - Redis从服务器配置
    - - 指定主服务器
      - 主服务器密码
      - 禁止保护模式
    - 配置监听的主服务器，
    - sentinel author-pass定义服务的密码
    - 临时配置执行方式
    - - 查看配置哨兵信息
      - 知识点汇总
- 使得Redis服务器可以跨网络访问
- - - 启动Redis服务器进程
    - 启动哨兵进程
    - 哨兵模式的总结
    - Java中使用哨兵模式
    - - sentinel down-after-milliseconds
  - 参考资料
- 下期预告

Redis的多种模式

Redis的架构运行模式：单机模式、主从模式、哨兵模式、集群模式等。

Redis单机模式

只有一个Redis，启动起来，业务调用即可，单机在很多场景也是有使用的，例如在一个并非必须保证高可用的情况下。

Redis单机模式的优点

部署简单
成本低，没有备用节点，不需要其他的开支。
高性能，单机不需要同步数据，数据天然一致性。

Redis单机模式的缺点

可靠性保证不是很好，单节点有宕机的风险。
单机高性能受限于CPU的处理能力，Redis是单线程的。
单机模式选择需要根据自己的业务场景去选择，如果需要很高的性能、可靠性，单机就不太合适了。

Redis主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。
前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。
在这里插入图片描述

主从模式配置很简单，只需要在从节点配置主节点的ip和端口号即可。

旧版本配置

slaveof <masterip> <masterport># 例如# slaveof 192.168.1.214 6379

新版本配置

replicaof <masterip> <masterport># 例如# replicaof 192.168.1.214 6379

查看主节点信息

启动主从节点的所有服务，查看日志即可以看到主从节点之间的服务连接。

从上面很容易就想到一个问题，既然主从复制，意味着master和slave的数据都是一样的，有数据冗余问题。

在程序设计上，为了高可用性和高性能，是允许有冗余存在的。这点希望大家在设计系统的时候要考虑进去，不用为公司节省这一点资源。

对于追求极致用户体验的产品，是绝对不允许有宕机存在的。

主从模式在很多系统设计时都会考虑，一个master挂在多个slave节点，当master服务宕机，会选举产生一个新的master节点，从而保证服务的高可用性。

主从模式的优点

一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。扩展主节点的读能力，分担主节点读压力。

高可用基石：除了上述作用以外，主从复制还是哨兵模式和集群模式能够实施的基础，因此说主从复制是Redis高可用的基石。也有相应的缺点，比如我刚提到的数据冗余问题：

主从复制的弊端

一旦主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。

Redis哨兵模式

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

分析哨兵结构组成

哨兵节点由两部分组成，哨兵节点和数据节点：

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
数据节点：主节点和从节点都是数据节点。

访问redis集群的数据都是通过哨兵集群的，哨兵监控整个redis集群。

一旦发现redis集群出现了问题，比如刚刚说的主节点挂了，从节点会顶上来。但是主节点地址变了，这时候应用服务无感知，也不用更改访问地址，因为哨兵才是和应用服务做交互的。

哨兵模式的主从切换

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

Redis哨兵模式的原理

Redis Sentinel是一个分布式系统，在一个架构中运行多个Sentinel进程，这些进程使用流言协议（gossip protocols）来接收关于主服务器是否下线的信息，使用投票协议（agreement protocols）来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。
Redis Sentinel 衍生出一个单独的可执行文件 redis-sentinel ，但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动 Redis Sentinel 。

在这里插入图片描述

每个Sentinel以每秒钟一次的频率，向它所有的主服务器、从服务器以及其他Sentinel实例发送一个PING 命令。
如果某一个实例（instance）距离最后一次有效回复PING命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel标记为主观下线。
如果一个主服务器被标记为主观下线，那么正在监视这个主服务器的所有 Sentinel节点，要以每秒一次的频率确认，该主服务器是否的确进入了主观下线状态。
如果一个主服务器被标记为主观下线，并且有足够数量的 Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个该主服务器被标记为客观下线。

常规情况下

在一般情况下，每个 Sentinel 会以每10秒一次的频率，向它已知的所有主服务器和从服务器发送 INFO 命令。
当一个主服务器被 Sentinel标记为客观下线时，Sentinel向下线主服务器的所有从服务器发送 INFO 命令的频率，会从10秒一次改为每秒一次。
Sentinel和其他 Sentinel 协商主节点的状态，如果主节点处于 SDOWN`状态，则投票自动选出新的主节点。将剩余的从节点指向新的主节点进行数据复制。
当没有足够数量的 Sentinel 同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向 Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除。

故障切换（failover）的过程

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。
当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。
master节点切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主服务器，这个过程称为客观下线。
这样对于客户端而言，一切都是透明的，当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

Redis-Sentinel的作用

Sentinel 系统用于管理多个 Redis 服务器（instance），该系统执行以下三个任务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。（通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。）
提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

主：6379   ，sentinel：26379

从：6380   ，sentinel：26380

从：6381   ，sentinel：26381

Redis的多哨兵运行模式

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

故障切换（failover）的过程

主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。
当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover的投票操作，就会通过发布订阅模式，投票完成后，让Master哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

Redis 哨兵模式的配置

当主宕机了从接替主成为新的主，宕机的主启动后自动变成了从，其实它和Mysql的双主模式是一样的互为主从；redis哨兵需要用到redis-sentinel程序和sentinel.conf配置文件。

Redis主节点服务配置

vim redis.conf

查看配置信息

daemonize yes
pidfile /usr/local/redis/6379/redis_6379.pid
port 6379
tcp-backlog 128
timeout 0
tcp-keepalive 0
loglevel notice
logfile ""
databases 16
save 900 1    ###save
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb   ###dbfile
dir "/usr/local/redis/6379"
masterauth "123456"
requirepass "123456"
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

重点配置

跨网络访问

bind 0.0.0.0

设置密码

requirepass "123456"

Redis从服务器配置

配置Redis服务器，从服务器比主服务器多一个slaveof/replicaof的配置和密码。

指定主服务器

replicaof/slaveof 192.168.11.128 6379

注意：有关replicaof/slaveof的配置只是配置从服务器，主服务器不需要配置

主服务器密码

masterauth 123456

禁止保护模式

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定义服务的密码

sentinel auth-pass

sentinel auth-pass mymaster 123456

mymaster是服务名称，123456是Redis服务器密码

临时配置执行方式

可以登入哨兵(两台哨兵都需要登入执行)，添加主从监控信息

redis-cli -p 6000
sentinel monitor mymaster 192.168.137.40 6379 2
sentinel set mymaster down-after-milliseconds 5000
sentinel set mymaster failover-timeout 15000
sentinel set mymaster auth-pass 123456

查看配置哨兵信息

vim sentinel.conf

port 6000
dir "/usr/local/redis/sentinel"
# 守护进程模式
daemonize yes
protected-mode no
logfile "/usr/local/sentinel/sentinel.log"

知识点汇总

应用程序连接到哨兵端口，通过指定不同的master名称连接到具体的主副本。
哨兵配置文件中只需要配置主从复制中的主副本ip和端口即可，当主从进行切换时哨兵会自动修改哨兵配置文件中的主副本ip为新在主副本ip。
一个哨兵配置文件中可以同时配置监控多个主从复制。
单个哨兵就可以用来进行主从故障监控，但是如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;这个2代表投票数，当2个sentinel认为一个master已经不可用了以后，将会触发failover，才能真正认为该master已经不可用了。（sentinel集群中各个sentinel也有互相通信，通过gossip协议）;所以合理的配置应该是同时启动多个哨兵进程,并且最好是在不同的服务器中启动。

mymaster的需要在整个网络环境都是唯一的，哨兵之间会自动通过mastername去建立关联关系只要网络环境是相通的。

使得Redis服务器可以跨网络访问

启动Redis服务器进程

./redis-server ../redis.conf

启动哨兵进程

./redis-sentinel ../sentinel.conf

哨兵模式的总结

Sentinel解决了故障转移，在高可用方面又上升了一个台阶，当然Sentinel还有其他功能。比如，主节点存活检测、主从运行情况检测、主从切换。Redis的Sentinel最小配置是一主一从。

Java中使用哨兵模式

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);
    }
}

配置项	参数类型	作用
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的哨兵配置文件，以适应新场景的需要。