Redis 哨兵模式

目录

1. 哨兵模式

2. 安装部署（基于 docker）

3. 重新选举

4. 选举原理

---

1. 哨兵模式

Redis的主从复制模式下，当主节点发生故障，需要人工进行主从切换，同时大量的客户端需要被通知切换到新的主节点上，对于一定规模的应用来说，这种方案不可行，因此 Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）解决这个问题

人工恢复主节点故障

Redis 主从复制模式下，主节点故障后需要进行的人工工作是比较繁琐的，下面是整体的过程

1）通过监控发现 Redis 主节点故障

2）从所有的节点中选择一个执行 slaveof no noe，使其称为新的主节点

3）让剩余节点执行从新的主节点开始同步数据

4）更新应用方连接的主节点信息

5）如果原来的节点恢复，让其成为一个从节点

哨兵自动恢复主节点故障

当主节点出现故障，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用

Redis Sentinel 是一个分布式架构，其中包含若干个 Sentinel 节点和 Redis 数据节点，每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控，如果主节点下线，它会和其他的 Sentinel 节点进行"协商"，当大多数 Sentinel 节点对主节点下线折合结论达成共识，它们会在内部"选举"出一个领导节点完成自动故障转移的工作，同时将这个变化实时通知给 Redis 应用方，整个过程是自动完成，不需要人工介入，整体的架构图如下

Redis Sentinel 架构

Redis Sentinel 相比于主从复制模式是多了若干个 Sentinel 节点（奇数）用于实现监控数据节点，哨兵节点会定期监控和所有节点（包含数据节点和其他哨兵节点），针对主节点故障，做出如下转移

1）主节点故障，从节点同步连接中断，主从复制停止

2）哨兵节点通过定期监控发现主节点故障，哨兵节点和其他哨兵节点进行协商，达成多数认为主节点发生故障

3）哨兵节点之间使用 Raft 算法选举出一个领导角色，由该节点负责后续的故障转移工作

4）哨兵领导者开始执行故障转移：从节点中选择一个作为新的主节点，让其他从节点同步新主节点，通知应用层转移到新主节点

2. 安装部署（基于 docker）

1）安装 docker 和 docker-compose

docker-compose 的安装

apt install docker-compose

2）停止 redis-server

# 停⽌ redis-server

service redis-server stop

# 停⽌ redis-sentinel 
service redis-sentinel stop

3）使用 docker 获取 redis 镜像

docker pull redis:5.0.9

编排 redis 主从节点

1）编写 docker-compose.yml

创建 /root/redis/docker-compose.yml，cd 到 yml 所在的目录中

version: '3.7'
services:
  master:
    image: 'redis:5.0.9'
    container_name: redis-master
    restart: always
    command: redis-server --appendonly yes
    ports:
      - 6379:6379
  slave1:
    image: 'redis:5.0.9'
    container_name: redis-slave1
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6380:6379
  slave2:
    image: 'redis:5.0.9'
    container_name: redis-slave2
    restart: always
    command: redis-server --appendonly yes --slaveof redis-master 6379
    ports:
      - 6381:6379

2）启动所有容器

docker-compose up -d

3）查看运行日志

 docker-compose logs 

4）验证

连接主机点

redis-cli -p 6379

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.22.0.3,port=6379,state=online,offset=348,lag=1
slave1:ip=172.22.0.4,port=6379,state=online,offset=348,lag=1
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:348
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:348

连接从节点

redis-cli -p 6380

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:redis-master
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:446
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:446
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:446

编排 redis-sentinel 节点

1）编写 docker-compose.yml

创建 /root/redis-sentinel/docker-compose.yml，cd 到 yml 所在的目录

每个目录中只能存在一个 docker-compose.yml 文件

version: '3.7'
services:
  sentinel1:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-1
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel1.conf:/etc/redis/sentinel.conf
    ports:
      - 26379:26379
  sentinel2:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-2
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel2.conf:/etc/redis/sentinel.conf
    ports:
      - 26380:26379
  sentinel3:
    image: 'redis:5.0.9'
    container_name: redis-sentinel-3
    restart: always
    command: redis-sentinel /etc/redis/sentinel.conf
    volumes:
      - ./sentinel3.conf:/etc/redis/sentinel.conf
    ports:
      - 26381:26379
networks:
  default:
    external:
      name: redis-data_default

2）创建配置文件

创建  sentinel1.conf、 sentinel2.conf、sentinel3.conf，三份文件的内容都是一样的，都放在 /root/redis-sentinel/目录中

bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000

sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数

主节点名：哨兵内部起的名字

主节点 ip：此处使用 docker 会被自动 DNS 成对应的容器 ip

主节点端口

法定票数：当票数 >= 法定票数，才会真正认为主节点挂了

sentinel down-after-milliseconds redis-master 1000

主节点和哨兵之间通过心跳包来进行沟通，如果心跳包在指定的时间内还没有回来，就认为节点出现故障 

3）启动所有容器

docker-compose up -d

4）查看运行日志

docker-compose logs

5）观察 redis-sentinel 的配置 rewrite

bind 0.0.0.0
port 26379
sentinel myid 4d2d562860b4cdd478e56494a01e5c787246b6aa
sentinel deny-scripts-reconfig yes
# Generated by CONFIG REWRITE
dir "/data"
sentinel monitor redis-master 172.22.0.4 6379 2

sentinel down-after-milliseconds redis-master 1000
sentinel config-epoch redis-master 1
sentinel leader-epoch redis-master 1
sentinel known-replica redis-master 172.22.0.2 6379
sentinel known-replica redis-master 172.22.0.3 6379
sentinel known-sentinel redis-master 172.22.0.7 26379
f718caed536d178f5ea6d1316d09407cfae43dd2
sentinel known-sentinel redis-master 172.22.0.5 26379
2ab6de82279bb77f8397c309d36238f51273e80a
sentinel current-epoch 1

# Generated by CONFIG REWRITE 这里的内容就是自动修改的，三份文件的配置内容是存在差异的

3. 重新选举

1）主观下线：哨兵感知主节点没有心跳了，判定为主观下线

2）客观下线：多个哨兵达成一致意见，认为主节点下线

当 redis 主节点被判定为客观下线，哨兵节点就会选出一个从节点作为新的主节点，当之前的 Redis 重启之后，这个主节点会被加入到哨兵的监控中，但是只能作为从节点使用

4. 选举原理

假定当前有三个哨兵节点（sentenal1，sentenal2，sentenal3），一个主节点（redis-master）和两个从节点（redis-slave1，redis-slave2），当主节点出现故障，就会触发如下过程

1）主观下线

当 redis-master 宕机，此时 redis-master 和三个哨兵之间的心跳包就没有了，此时，三个哨兵就会把 redis-master 判定为主观下线

2）客观下线

此时三个哨兵节点就会对主节点故障这件事进行投票，当故障票数 >= 配置的房顶票数之后，此时触发客观下线

3）选举出哨兵的 leader

哨兵把剩下的 slave 中挑选一个新的 master，这个过程不需要所有哨兵参与，只需要选出一个代表，由 leader 负责进行 slave 升级到 master 的过程

假设由三个哨兵节点 s1，s2，s3

1）每个哨兵节点都会给其他所有的哨兵节点发起一个请求拉票

2）收到拉票请求的节点，会回复一个投票响应。响应的结果只有投或者不投

例如 s1 给 s2 发起投票请求，s2 就会给 s1 返回投票响应，每个哨兵只有一票，如果 s2 已经给别人投过票了，那么它就不能投给 s1了，相反，如果 s2 的票还没有投出去，s1 是第一个向 s2 拉票的，那么 s2 就会投给 s1

3）一轮投票完成之后，票数超过半数的节点，成为 leader 

4）leader 节点负责挑选一个 slave 成为新的 master，当其他 sentinel 发现新的 master 出现，就说明选举结束

4）leader 挑选出合适的 slave 成为新的 master

 挑选规则：

1）比较配置文件中的配置项（slave-priority 或者 replica-priority），谁的优先级高（数值小），就选谁

2）比较 replication offset 谁复制的数据多，选谁

3）比较 run id，谁的 id 小，选谁

当某个 slave 节点被指定为 master 之后，leader 指定该节点执行 slave no one，成为 master，leader 指定剩余的 slave 几点，都依附这个新的 master