使用docker-compose创建哨兵模式 Redis集群

使用docker-compose创建哨兵模式 Redis集群

版本信息：5.0.6

我们已经知道在主从模式下，如果master服务器挂掉了，那么集群是不能自动容错和恢复的，需要人工处理。而且在此期间无法写数据。为了解决这个问题我们就需要有一种方案让redis宕机后可以自动进行故障转移。

redis给我们提供了一种高可用解决方案redis-sentinel。redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

一、目录结构如下

image.png

  • 在redis_sentinel文件下创建redis、sentinel两个文件夹
  • 在redis文件夹下处理redis主从模式服务的创建
  • 在sentinel文件夹下处理哨兵模式服务的创建

1.1 master/slave

因为哨兵模式依赖主从模式，所以先创建主从模式服务。这里使用一个docker-compose.yaml的形式。

version: '3'

services:
  #master 节点
  redis_master:
    image: redis:latest
    container_name: redis_master
    restart: always
    ports:
      - 6379:6379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.10
    volumes:
      - ./redis_master.conf:/usr/local/etc/redis/redis.conf:rw
      - ./data_master:/data:rw
    command:
      /bin/bash -c "redis-server /usr/local/etc/redis/redis.conf "
  #slave1 节点
  redis_slave1:
    image: redis:latest
    container_name: redis_slave1
    restart: always
    ports:
      - 6380:6379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.11
    volumes:
      - ./redis_slave1.conf:/usr/local/etc/redis/redis.conf:rw
      - ./data_slave1:/data:rw
    command:
      /bin/bash -c "redis-server /usr/local/etc/redis/redis.conf "
  #slave2 节点
  redis_slave2:
    image: redis:latest
    container_name: redis_slave2
    restart: always
    ports:
      - 6381:6379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.12
    volumes:
      - ./redis_slave2.conf:/usr/local/etc/redis/redis.conf:rw
      - ./data_slave2:/data:rw
    command:
      /bin/bash -c "redis-server /usr/local/etc/redis/redis.conf " 

networks:
  mynetwork:
    external: true
  • 这里创建三个节点redis_master、redis_slave1、redis_slave2
  • 使用的配置文件分别是redis_master.conf redis_slave1.conf redis_slave2.conf

1.1.1 redis_master.conf

bind 0.0.0.0
protected-mode no
port 6379
timeout 0
save 300 10
save 60 10000

rdbcompression yes
dbfilename "dump.rdb"
dir "/data"
appendonly yes
appendfsync everysec
requirepass "12345678"
masterauth "12345678"
  • 这里有一点需要注意的 配置masterauth，即配置master节点服务的密码。
    • 我们后面使用哨兵模式能够完成故障转移，现有的Master可能会变成Slave，故在当前Master容器中也要携带masterauth参数，否则会出现原master节点连接不上新master节点

1.1.2 redis_slave.conf

bind 0.0.0.0
protected-mode no
port 6379
timeout 0
save 300 10
save 60 10000

rdbcompression yes
dbfilename "dump.rdb"
dir "/data"
appendonly yes
appendfsync everysec
requirepass "12345678"

masterauth "12345678"

replicaof 172.19.0.10 6379

1.2 Redis Sentinel

1.2.1 哨兵集群配置

这里sentinel也是集群部署的方式，而不是单点。避免如下问题：

  • 单点的sentinel进程宕掉后，整个集群系统将无法按照预期的方式运行
  • 如果只有一个sentinel进程，那么这个进程运行出错，或者网络堵塞，那么将无法实现redis集群的主备切换
version: '3'

services:
  #master 节点
  sentinel_master:
    image: redis:latest
    container_name: sentinel_master
    restart: always
    ports:
      - 26379:26379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.13
    volumes:
      - ./sentinel_master.conf:/usr/local/etc/redis/sentinel.conf:rw
    command:
      /bin/bash -c "redis-sentinel /usr/local/etc/redis/sentinel.conf "
  #slave1 节点
  sentinel_slave1:
    image: redis:latest
    container_name: sentinel_slave1
    restart: always
    ports:
      - 26380:26379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.14
    volumes:
      - ./sentinel_slave1.conf:/usr/local/etc/redis/sentinel.conf:rw
    command:
      /bin/bash -c "redis-sentinel /usr/local/etc/redis/sentinel.conf "
  #slave2 节点
  sentinel_slave2:
    image: redis:latest
    container_name: sentinel_slave2
    restart: always
    ports:
      - 26381:26379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.15
    volumes:
      - ./sentinel_slave2.conf:/usr/local/etc/redis/sentinel.conf:rw
    command:
      /bin/bash -c "redis-sentinel /usr/local/etc/redis/sentinel.conf " 

networks:
  mynetwork:
    external: true

1.2.2 sentinel.conf

port 26379
# 给master起一个名字mymaster，并且配置master的ip和端口
sentinel monitor mymaster 172.19.0.10 6379 2
# master的密码
sentinel auth-pass mymaster 12345678
# 3s未回复PING就认为master主观下线
sentinel down-after-milliseconds mymaster 3000 
# 执行故障转移时，最多可以有2个slave实例在同步新的master实例
sentinel parallel-syncs mymaster 2  
# 如果在10s内未能完成故障转移操作认为故障转移失败
sentinel failover-timeout mymaster 100000

二、验证

~ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                NAMES
ff455bf5676c        redis:latest        "docker-entrypoint.s…"   45 minutes ago      Up 45 minutes       6379/tcp, 0.0.0.0:26380->26379/tcp   sentinel_slave1
2bdbd1a0b5ef        redis:latest        "docker-entrypoint.s…"   45 minutes ago      Up 45 minutes       6379/tcp, 0.0.0.0:26381->26379/tcp   sentinel_slave2
8bb2eb5365e1        redis:latest        "docker-entrypoint.s…"   45 minutes ago      Up 45 minutes       6379/tcp, 0.0.0.0:26379->26379/tcp   sentinel_master
fd6be8564ee8        redis:latest        "docker-entrypoint.s…"   45 minutes ago      Up 45 minutes       0.0.0.0:6380->6379/tcp               redis_slave1
460fa58bdfdc        redis:latest        "docker-entrypoint.s…"   45 minutes ago      Up 38 minutes       0.0.0.0:6381->6379/tcp               redis_slave2
5f842ae41625        redis:latest        "docker-entrypoint.s…"   45 minutes ago      Up 42 minutes       0.0.0.0:6379->6379/tcp               redis_master
~ docker exec -it 5f842ae41625 redis-cli
127.0.0.1:6379> auth 12345678
OK
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.19.0.11,port=6379,state=online,offset=554087,lag=0
slave1:ip=172.19.0.12,port=6379,state=online,offset=554224,lag=0
master_replid:21253f5e0b506d3a84d46b873400fb6d6c28d12c
master_replid2:1474ba786236805dc8ee752d767589c0e8622717
master_repl_offset:554224
second_repl_offset:77733
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:37851
repl_backlog_histlen:516374
127.0.0.1:6379> exit
~ docker exec -it ff455bf5676c redis-cli -p 26379
127.0.0.1:26379> sentinel master mymaster
 1) "name"
 2) "mymaster"
 3) "ip"
 4) "172.19.0.10"
 5) "port"
 6) "6379"
 7) "runid"
 8) "7a4b934799d0aa06580e026b9d8e56184bd9974f"
 9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "190"
19) "last-ping-reply"
20) "190"
21) "down-after-milliseconds"
22) "3000"
23) "info-refresh"
24) "3666"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "2383694"
29) "config-epoch"
30) "2"
31) "num-slaves"
32) "2"
33) "num-other-sentinels"
34) "2"
35) "quorum"
36) "2"
37) "failover-timeout"
38) "100000"
39) "parallel-syncs"
40) "2"
  • docker ps 查看当前运行的容器
  • 执行 docker exec -it 5f842ae41625 redis-cli 进入redis容器
  • 通过 info replication 查看副本信息
    • role:master ：当前节点是master节点
    • connected_slaves:2 ：有两个从节点
  • 执行 docker exec -it ff455bf5676c redis-cli -p 26379 进入sentinel容器
  • 通过 sentinel master mymaster 查看主节点信息
  1. "name"
  2. "mymaster"
  3. "ip"
  4. "172.19.0.10"
  5. "port"
  6. "6379"

三、故障转移

关闭当前master节点，查看当前哨兵日志信息

~ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                NAMES
ff455bf5676c        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:26380->26379/tcp   sentinel_slave1
2bdbd1a0b5ef        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:26381->26379/tcp   sentinel_slave2
8bb2eb5365e1        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:26379->26379/tcp   sentinel_master
fd6be8564ee8        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          0.0.0.0:6380->6379/tcp               redis_slave1
460fa58bdfdc        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          0.0.0.0:6381->6379/tcp               redis_slave2
5f842ae41625        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          0.0.0.0:6379->6379/tcp               redis_master
~ docker stop 5f842ae41625 
5f842ae41625
~

日志信息如下：

# sentinel_slave2 发现 172.19.0.10 6379不能用
sentinel_slave2    | 1:X 06 Sep 2020 07:43:24.229 # +sdown master mymaster 172.19.0.10 6379
# sentinel_master 发现 172.19.0.10 6379不能用
sentinel_master    | 1:X 06 Sep 2020 07:43:24.249 # +sdown master mymaster 172.19.0.10 6379
# sentinel_slave1 发现 172.19.0.10 6379不能用
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.256 # +sdown master mymaster 172.19.0.10 6379

# 投票后，有三个 sentinel发现 master不能用
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.311 # +odown master mymaster 172.19.0.10 6379 #quorum 3/2

# sentinel_slave1 配置被更新
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.311 # +new-epoch 3
# 等待其他sentinel的选举
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.311 # +try-failover master mymaster 172.19.0.10 6379

# 进行投票选举slave服务器
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.322 # +vote-for-leader b58925e28f67202a06be75cddb2c1d532ad0bd86 3
sentinel_master    | 1:X 06 Sep 2020 07:43:24.330 # +new-epoch 3
sentinel_slave2    | 1:X 06 Sep 2020 07:43:24.334 # +new-epoch 3
sentinel_master    | 1:X 06 Sep 2020 07:43:24.340 # +vote-for-leader b58925e28f67202a06be75cddb2c1d532ad0bd86 3
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.340 # 0e96d185235787b3bb3b6eb3ed1ff1c1ae588ce5 voted for b58925e28f67202a06be75cddb2c1d532ad0bd86 3
sentinel_slave2    | 1:X 06 Sep 2020 07:43:24.345 # +vote-for-leader b58925e28f67202a06be75cddb2c1d532ad0bd86 3
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.346 # 94acd9ae410e64241c2b40f441cc5b8bd5a2dcb2 voted for b58925e28f67202a06be75cddb2c1d532ad0bd86 3
sentinel_master    | 1:X 06 Sep 2020 07:43:24.351 # +odown master mymaster 172.19.0.10 6379 #quorum 2/2
sentinel_master    | 1:X 06 Sep 2020 07:43:24.352 # Next failover delay: I will not start a failover before Sun Sep  6 07:46:45 2020
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.386 # +elected-leader master mymaster 172.19.0.10 6379
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.386 # +failover-state-select-slave master mymaster 172.19.0.10 6379

# 选择一个slave当前新的master
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.479 # +selected-slave slave 172.19.0.11:6379 172.19.0.11 6379 @ mymaster 172.19.0.10 6379

# 把选举出来的slave进行身份master切换
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.479 * +failover-state-send-slaveof-noone slave 172.19.0.11:6379 172.19.0.11 6379 @ mymaster 172.19.0.10 6379
sentinel_slave1    | 1:X 06 Sep 2020 07:43:24.565 * +failover-state-wait-promotion slave 172.19.0.11:6379 172.19.0.11 6379 @ mymaster 172.19.0.10 6379
sentinel_slave2    | 1:X 06 Sep 2020 07:43:25.287 # +odown master mymaster 172.19.0.10 6379 #quorum 3/2
sentinel_slave2    | 1:X 06 Sep 2020 07:43:25.287 # Next failover delay: I will not start a failover before Sun Sep  6 07:46:44 2020
sentinel_slave1    | 1:X 06 Sep 2020 07:43:25.378 # +promoted-slave slave 172.19.0.11:6379 172.19.0.11 6379 @ mymaster 172.19.0.10 6379

#把故障转移failover 改变reconf-slaves
sentinel_slave1    | 1:X 06 Sep 2020 07:43:25.379 # +failover-state-reconf-slaves master mymaster 172.19.0.10 6379

# sentinel发送 slaveof命令
sentinel_slave1    | 1:X 06 Sep 2020 07:43:25.438 * +slave-reconf-sent slave 172.19.0.12:6379 172.19.0.12 6379 @ mymaster 172.19.0.10 6379
sentinel_master    | 1:X 06 Sep 2020 07:43:25.447 # +config-update-from sentinel b58925e28f67202a06be75cddb2c1d532ad0bd86 172.19.0.14 26379 @ mymaster 172.19.0.10 6379
sentinel_master    | 1:X 06 Sep 2020 07:43:25.447 # +switch-master mymaster 172.19.0.10 6379 172.19.0.11 6379
sentinel_master    | 1:X 06 Sep 2020 07:43:25.448 * +slave slave 172.19.0.12:6379 172.19.0.12 6379 @ mymaster 172.19.0.11 6379
sentinel_master    | 1:X 06 Sep 2020 07:43:25.448 * +slave slave 172.19.0.10:6379 172.19.0.10 6379 @ mymaster 172.19.0.11 6379
sentinel_slave2    | 1:X 06 Sep 2020 07:43:25.441 # +config-update-from sentinel b58925e28f67202a06be75cddb2c1d532ad0bd86 172.19.0.14 26379 @ mymaster 172.19.0.10 6379
sentinel_slave2    | 1:X 06 Sep 2020 07:43:25.441 # +switch-master mymaster 172.19.0.10 6379 172.19.0.11 6379
sentinel_slave2    | 1:X 06 Sep 2020 07:43:25.443 * +slave slave 172.19.0.12:6379 172.19.0.12 6379 @ mymaster 172.19.0.11 6379
sentinel_slave2    | 1:X 06 Sep 2020 07:43:25.444 * +slave slave 172.19.0.10:6379 172.19.0.10 6379 @ mymaster 172.19.0.11 6379
sentinel_slave1    | 1:X 06 Sep 2020 07:43:26.442 * +slave-reconf-inprog slave 172.19.0.12:6379 172.19.0.12 6379 @ mymaster 172.19.0.10 6379
sentinel_slave1    | 1:X 06 Sep 2020 07:43:26.442 * +slave-reconf-done slave 172.19.0.12:6379 172.19.0.12 6379 @ mymaster 172.19.0.10 6379

# 离开不可用的master
sentinel_slave1    | 1:X 06 Sep 2020 07:43:26.508 # -odown master mymaster 172.19.0.10 6379

# 故障转移完成
sentinel_slave1    | 1:X 06 Sep 2020 07:43:26.508 # +failover-end master mymaster 172.19.0.10 6379

# master地址发生改变
sentinel_slave1    | 1:X 06 Sep 2020 07:43:26.509 # +switch-master mymaster 172.19.0.10 6379 172.19.0.11 6379

#检测salve并添加 slave列表
sentinel_slave1    | 1:X 06 Sep 2020 07:43:26.511 * +slave slave 172.19.0.12:6379 172.19.0.12 6379 @ mymaster 172.19.0.11 6379
sentinel_slave1    | 1:X 06 Sep 2020 07:43:26.511 * +slave slave 172.19.0.10:6379 172.19.0.10 6379 @ mymaster 172.19.0.11 6379

到这里 故障转移完成。根据日志 应该是172.19.0.11 6379 成为了新的master节点。

~ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                NAMES
ff455bf5676c        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:26380->26379/tcp   sentinel_slave1
2bdbd1a0b5ef        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:26381->26379/tcp   sentinel_slave2
8bb2eb5365e1        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          6379/tcp, 0.0.0.0:26379->26379/tcp   sentinel_master
fd6be8564ee8        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          0.0.0.0:6380->6379/tcp               redis_slave1
460fa58bdfdc        redis:latest        "docker-entrypoint.s…"   2 hours ago         Up 2 hours          0.0.0.0:6381->6379/tcp               redis_slave2
~ docker exec -it fd6be8564ee8 redis-cli
127.0.0.1:6379> auth 12345678
OK
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=172.19.0.12,port=6379,state=online,offset=1403250,lag=1
master_replid:29731108d80725192eff7a8ee5f298d76256f1cb
master_replid2:21253f5e0b506d3a84d46b873400fb6d6c28d12c
master_repl_offset:1403250
second_repl_offset:1223636
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:354675
repl_backlog_histlen:1048576
127.0.0.1:6379> exit
~  
~ docker exec -it 460fa58bdfdc redis-cli
127.0.0.1:6379> auth 12345678
OK
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:172.19.0.11
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:1408361
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:29731108d80725192eff7a8ee5f298d76256f1cb
master_replid2:21253f5e0b506d3a84d46b873400fb6d6c28d12c
master_repl_offset:1408361
second_repl_offset:1223636
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:359786
repl_backlog_histlen:1048576
127.0.0.1:6379> exit
  • 通过 docker exec -it fd6be8564ee8 redis-cli 进入当前容器
  • 查看当前容器信息 info replication
    • 当前节点是master节点，且有一个从节点

四、原理

哨兵模式是主从模式的升级版，因为主从的出现故障后，不会自动恢复，需要认为干预。在主从的基础上，实现哨兵模式就是为了监控主从的运行状况，对主从的健壮进行监控，就好像哨兵一样，只要有异常就发出警告，对异常状况进行处理。
image.png
所以，总的概括来说，哨兵模式有以下功能点：

  1. 监控：监控master和slave是否正常运行，以及哨兵之间也会相互监控
  2. 自动故障恢复：当master出现故障的时候，会自动选举一个slave作为master顶上去

哨兵模式的监控配置信息，是通过配置从数据库的 sentinel moitor 来指定的，比如：

# mymaster 表示给master数据库定义了一个名字，后面的是master的IP和端口号，2表示至少需要sentinel进程同意才能将master判断为失效，如果不满足这个条件，那么自动故障转移（failover）不会执行
sentinel monitor mymaster 172.19.0.10 6379 2

4.1 节点通信

当哨兵启动后，会与master建立一条连接，用于订阅master的 _sentinel_:hello 频道。该频道用于获取监控该master的其他哨兵的信息。

并且还会建立一条定时向master发送INFO命令获取master信息的连接。当哨兵与master建立连接后，定期（10s）会向master和slave发送INFO命令，若是master被标记为主观下线，频率就会变为一秒一次。

并且定期向 _sentinel_:hello 频道发送自己的信息，以便其他的哨兵能够订阅获取自己的信息，发送的内容包含[哨兵的IP和端口、运行ID、配置版本、master名字、master的IP、端口还有master的配置版本]等信息。

以及[定期（每秒一次）的向master、slave和其他哨兵发送PING命令，以便检测对象是否存活]，若是对方接收到了PING命令，无障碍情况下，会回复PONG命令。

所以，哨兵通过建立这两条连接，通过定期发送INFO、PING命令来实现哨兵与哨兵、哨兵与master之间的通信。

对于提到的 INFO、PING、PONG以及MEET、FAIL等命令，还有主观下线、客观下线这里进行解释以下：

  • INFO：该命令可以获取主从数据库的最新信息，可以实现新节点的发现
  • PING：该命令被使用最频繁，该命令封装了自身节点和其他节点的状态数据。
  • PONG：当节点收到MEET和PING，会回复PONG，也把自己的状态发送给对象
  • MEET：该命令是在新节点加入集群的时候，会向老节点发送该命令，表示自己是个新人
  • FAIL：当节点下线，会向集群中广播该消息

4.2 上线和下线

当哨兵和master想通之后就会定期一直保持联系，若是某一时刻哨兵发现发送的PING在指定的时间内（sentinel down-after-milliseconds master-name 3000）没有收到回复，那么发送PING命令的哨兵就会认为该maser主线下线（subjectively down）。

因为有可能是哨兵与该master之间的网络问题造成的，而不是master本身的原因，所以哨兵同时会询问其他的哨兵是否也认为该master下线，若是认为该节点下线的哨兵达到一定的数量（前面设置的quorum字段），就会认为该节点客观下线（objectively down）。

若是没有足够数量的sentinel同意该master下线，则该master客观下线的标识会被移除；若是master重新向哨兵的PING命令回复了，客观下线的标识也会被移除。

4.3 选举算法

当master被认为客观下线后，需要进行故障恢复。哨兵中首先选举出一个老大哨兵进行故障恢复，选举老大哨兵的算法叫做Raft算法。

  1. 发现master下线的哨兵（sentinel A）会像其他的哨兵发送命令进行拉票，要求选择自己为哨兵大佬
  2. 若是目标哨兵没有选择其他的哨兵，则会选择该哨兵（sentinel A）为大佬
  3. 若是选择sentinel A的哨兵超过半数（半数原则），则大佬非 sentinel A莫属
  4. 如果有多个哨兵同时竞选，并且可能存在票数一致的情况，就会等待下次的一个随机时间再次发起竞选请求，进行新的一轮投票，直到大佬被选举出来。

选出大佬哨兵之后，大佬哨兵就会对故障进行自动恢复，从slave中选出一名slave作为主数据库，选举的规则如下所示：

  1. 所有的slave中 slave-priority 优先级最高的会被选中
  2. 若是优先级仙童，会选择偏移量最大的，因为偏移量纪录者数据的复制的增量，越大表示数据越完整
  3. 若是以上两者都相同，选择ID最小的。

通过以上的层层筛选最终实现故障恢复，当选的slave晋升为master，其他的slave会向新的master复制数据，若是down掉的master重新上线，会被当作slave角色运行。

五、优缺点

5.1 优点

哨兵模式是主从模式的升级版，所以在系统层面提高了系统的可用性和性能稳定性。当master宕机的时候，能够自动进行故障恢复，而不需要人为的干预。

哨兵与哨兵之间、哨兵与master之间能够进行及时的监控，心跳检测，及时发现系统的问题，这都是弥补了主从模式的缺点。

5.2 缺点

哨兵一主多从的模式同样也会遇到写的瓶颈，以及存储瓶颈，若是master宕机了，故障恢复的时间比较长，写的业务就会受到影响。

增加了哨兵也增加了系统的复杂度，需要同时维护哨兵模式。

到此哨兵模式的redis集群结束。

posted @ 2020-09-10 20:45  在线打工者  阅读(331)  评论(0)    收藏  举报