【Redis】10.哨兵模式与分片集群

水深无声 2024-04-01 15:50 61阅读 0赞

#### 文章目录 ####

*  1. Redis哨兵模式
 *   *  1.1 搭建哨兵集群
     *  1.2 选举规则与故障转移
     *  1.3 RedisTemplate的哨兵模式
 *  2. Redis分片集群
 *   *  2.1 搭建分片集群
     *  2.2 散列插槽
     *  2.3 集群伸缩
     *  2.4 故障转移
     *   *  2.4.1 自动故障转移
         *  2.4.2 手动故障转移
     *  2.5 RedisTemplate访问分片集群

## 1. Redis哨兵模式 ##

> 在主从集群模式下，salve节点宕机后可以找master节点同步数据，但是倘若master节点宕机后怎么办？

**Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复**。哨兵的结构和作用如下：

*  **监控**：Sentinel 会不断检查您的master和slave是否按预期工作。
    
     *  **Sentinel基于心跳机制监测服务状态**，每隔1秒向集群的每个实例发送ping命令：
        
         *  **主观下线**：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例**主观下线**。
         *  **客观下线**：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例**客观下线**。quorum值最好超过Sentinel实例数量的一半。
         *  ![image-20221107153849437][]
 *  **自动故障恢复**：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。
    
     *  当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
 *  **通知**：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。

![image-20221107153607526][]

**并且单个哨兵对Redis服务器进行监控，可能会出现问题，因此可以使用多个哨兵进行监控。各个哨兵之间还会互相监控，这样就形成了多哨兵模式**

--------------------

### 1.1 搭建哨兵集群 ###

这里准备使用三个节点作为Sentinel集群，用来监管之前的Redis主从集群。

三个sentinel实例信息如下：

准备一个sentinel.conf的配置文件

port 27001
    sentinel announce-ip 192.168.150.101
    sentinel monitor mymaster 192.168.150.101 7001 2
    sentinel down-after-milliseconds mymaster 5000
    sentinel failover-timeout mymaster 60000
    dir "/tmp/s1"

*  `port 27001`：是当前sentinel实例的端口
 *  `sentinel monitor mymaster 192.168.150.101 7001 2`：指定主节点信息
    
     *  `mymaster`：主节点名称，自定义，任意写
     *  `192.168.150.101 7001`：主节点的ip和端口
     *  `2`：选举master时的quorum值

另外两个sentinel也需要准备这个配置文件，只是需要把端口号改了。

然后启动三个redis实例

# 第1个
    redis-sentinel s1/sentinel.conf
    # 第2个
    redis-sentinel s2/sentinel.conf
    # 第3个
    redis-sentinel s3/sentinel.conf

**这样哨兵集群的搭建完成了。**

> **哨兵启动后只指定了master的地址，要想知道整个集群中完整的拓扑关系怎么做呢？**

哨兵每隔10s就会向每个master节点发送`info`命令，`info`命令返回的信息中，包含了主从拓扑关系，其中包括每个slave的地址和端口号。有了这些信息后，哨兵就会记住这些节点的拓扑信息，在后续发生故障时，选择合适的slave节点进行故障恢复。

> **那么哨兵之间是怎样通信的呢？**

哨兵之间是通过Redis提供的发布（pub）/订阅（sub）机制完成的。哨兵节点不会直接与其他哨兵节点建立连接，**而是首先会和主库建立起连接**，然后向一个名为"*sentinel*:hello"频道发送自己的信息（IP 和端口），其他订阅了该频道的哨兵节点就会获取到该哨兵节点信息，从而哨兵节点之间互知。

--------------------

### 1.2 选举规则与故障转移 ###

一旦master故障，sentinel就需要在多个salve中选择一个作为新的master，选择规则如下：

1.  首先**判断salve节点与master断开时间长短**，如果超过指定值（down-after-milliseconds \* 10）则会排除该slave节点
2.  然后**判断slave节点的slave-priority值**，越小优先级越高，如果是0则永不参与选举
3.  如果slave-prority一样，则**判断slave节点的offset值，越大说明数据越新**，优先级越高
4.  最后是**判断slave节点的运行id大小**，越小优先级越高。

简而言之，就是**slave-priority配置 > 数据完整性 > runid较小者进行选择**

选举出新的master之后，就要**开始进行故障转移了**，步骤如下：

1.  sentinel**给备选的slave1节点发送slaveof no one命令**，让该节点成为master
2.  sentinel**给所有其它slave发送slaveof 192.168.150.101 7002 命令**，让这些slave成为新master的从节点，开始从新的master上同步数据。
3.  最后，**sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点**

![image-20221107160000419][]

--------------------

### 1.3 RedisTemplate的哨兵模式 ###

在Java中使用哨兵模式，需要以下步骤：

1.  在pom文件中引入redis的starter依赖：
    
        
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
2.  然后在配置文件application.yml中指定sentinel相关信息：
    
        spring:  
        	redis:    
        		sentinel:      
        			master: mymaster # 指定master名称      
        			nodes: # 指定redis-sentinel集群信息        
        				- 192.168.150.101:27001       
        				- 192.168.150.101:27002       
        				- 192.168.150.101:27003
3.  配置主从读写配置
    
        @Bean
        public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
              
            return clientConfigurationBuilder -> 		clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
        }

\*\*这里的ReadFrom是配置Redis的读取策略，是一个枚举，\*\*包括下面选择：

*  MASTER：从主节点读取
 *  MASTER\_PREFERRED：优先从master节点读取，master不可用才读取replica
 *  REPLICA：从slave（replica）节点读取
 *  REPLICA \_PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master

**这样配置完之后，客户端就能感知到主节点发生改变了。**

> **那么，主节点发生变化的时候，客户端是如何感知的呢？**

这是基于redis提供的发布（pub）/订阅（sub）机制完成的，客户端可以从哨兵订阅消息，故障转移后，客户端会收到订阅消息。

--------------------

## 2. Redis分片集群 ##

主从哨兵模式可以更好解决高可用、高并发读的问题。但是面对**高并发写与海量数据存储**的问题，这种模式依然存在问题

因此，分片集群模式的出现，就能解决上述出现的问题。

**分片集群特征：**

*  集群中有多个master，每个master保存不同数据
 *  每个master都可以有多个slave节点
 *  **master之间通过ping监测彼此健康状态**
 *  客户端请求可以访问集群任意节点，最终都会被转发到正确节点

--------------------

### 2.1 搭建分片集群 ###

这里就搭建3个master节点，每个master包含一个salve节点。

![image-20210702164116027][]

信息如下：

<table> 
 <thead> 
  <tr> 
   <th align="center">IP</th> 
   <th align="center">PORT</th> 
   <th align="center">角色</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">192.168.150.101</td> 
   <td align="center">7001</td> 
   <td align="center">master</td> 
  </tr> 
  <tr> 
   <td align="center">192.168.150.101</td> 
   <td align="center">7002</td> 
   <td align="center">master</td> 
  </tr> 
  <tr> 
   <td align="center">192.168.150.101</td> 
   <td align="center">7003</td> 
   <td align="center">master</td> 
  </tr> 
  <tr> 
   <td align="center">192.168.150.101</td> 
   <td align="center">8001</td> 
   <td align="center">slave</td> 
  </tr> 
  <tr> 
   <td align="center">192.168.150.101</td> 
   <td align="center">8002</td> 
   <td align="center">slave</td> 
  </tr> 
  <tr> 
   <td align="center">192.168.150.101</td> 
   <td align="center">8003</td> 
   <td align="center">slave</td> 
  </tr> 
 </tbody> 
</table>

准备一个redis.conf文件

port 6379
    # 开启集群功能
    cluster-enabled yes
    # 集群的配置文件名称，不需要我们创建，由redis自己维护
    cluster-config-file /tmp/6379/nodes.conf
    # 节点心跳失败的超时时间
    cluster-node-timeout 5000
    # 持久化文件存放目录
    dir /tmp/6379
    # 绑定地址
    bind 0.0.0.0
    # 让redis后台运行
    daemonize yes
    # 注册的实例ip
    replica-announce-ip 192.168.150.101
    # 保护模式，不需要密码就可以进去
    protected-mode no
    # 数据库数量
    databases 1
    # 日志
    logfile /tmp/6379/run.log

每个实例都修改成自己的端口号，然后启动实例。

![image-20210702174255799][]

虽然服务启动了，但是目前每个服务之间都是独立的，没有任何关联。

在Redis5.0以后，集群管理已经集成到redis-cli中

redis-cli --cluster create --cluster-replicas 1 192.168.150.101:7001 192.168.150.101:7002 192.168.150.101:7003 192.168.150.101:8001 192.168.150.101:8002 192.168.150.101:8003

命令说明：

*  `redis-cli --cluster`或者`./redis-trib.rb`：代表集群操作命令
 *  `create`：代表是创建集群
 *  `--replicas 1`或者`--cluster-replicas 1` ：指定集群中每个master的副本个数为1，此时`节点总数 ÷ (replicas + 1)` 得到的就是master的数量。因此节点列表中的前n个就是master，其它节点都是slave节点，随机分配到不同master

这样集群的搭建完成了。

--------------------

### 2.2 散列插槽 ###

在Redis的分片集群中，Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：

![image-20210725155820320][]

\*\*数据key不是与节点绑定，而是与插槽绑定。\*\*redis会根据key的有效部分计算插槽值，分两种情况：

*  key中包含"\{\}"，且“\{\}”中至少包含1个字符，“\{\}”中的部分是有效部分
 *  key中不包含“\{\}”，整个key都是有效部分
 *

例如：key是num，那么就根据num计算，如果是\{itcast\}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

![image-20210725155850200][]

如图，在7001这个节点执行set a 1时，对a做hash运算，对16384取余，得到的结果是15495，因此要存储到103节点。

到了7003后，执行`get num`时，对num做hash运算，对16384取余，得到的结果是2765，因此需要切换到7001节点

> **如何将同一类数据固定的保存在同一个Redis实例？**

这一类数据使用相同的有效部分，例如key都以\{typeId\}为前缀

--------------------

### 2.3 集群伸缩 ###

redis-cli --cluster还提供了添加节点的命令。

![image-20210725160448139][]

新建一个redis节点7004，执行下面命令

redis-cli --cluster add-node  192.168.150.101:7004 192.168.150.101:7001

通过命令查看集群状态：

redis-cli -p 7001 cluster nodes

如图，7004加入了集群，并且默认是一个master节点：

![image-20210725161007099][]

但是此时7004的插槽数为0，任何数据都不可以存储在7004中。

因此，就需要进行转移插槽的操作了

假如想要将num存储在7004节点，就要先看看num的插槽是多少了

![image-20210725161241793][]

如上图所示，num的插槽为2765.

我们可以将0~3000的插槽从7001转移到7004，命令格式如下：

![image-20210725161401925][]

建立连接：

![image-20210725161506241][]

![image-20210725161540841][]

这里就是问要移动多少个插槽，这里我想移动3000个

![image-20210725161637152][]

这里问的是那个node来接收这些插槽？？

显然是7004节点，可以查看节点的id

![image-20210725161731738][]

![image-20210725161817642][]

这里询问，你的插槽是从哪里移动过来的？

*  all：代表全部，也就是三个节点各转移一部分
 *  具体的id：目标节点的id
 *  done：没有了

这里可以选择从7001获取，所以填写7001的id

![image-20210725162030478][]

填完后，点击done，这样插槽转移就准备好了：

最后输入yes，就可以了

再次查看，可以看见插槽分配成功了

![image-20210725162224058][]

--------------------

### 2.4 故障转移 ###

对于宕机的master进行故障转移，有以下两种方式：

*  自动故障转移
 *  手动故障转移

--------------------

#### 2.4.1 自动故障转移 ####

自动故障转移的话，当一个redis宕机

首先先是疑似宕机

![image-20210725162319490][]

然后确认下线，自动升级一个salve为新的master

![image-20210725162408979][]

当7002再次启动，就会变为一个slave节点了：

![image-20210727160803386][]

--------------------

#### 2.4.2 手动故障转移 ####

**利用cluster failover命令可以手动让集群中的某个master宕机**，切换到**执行cluster failover命令的这个slave节点**，实现无感知的数据迁移。其流程如下：

![image-20210725162441407][]

这种failover命令可以指定三种模式：

*  缺省：默认的流程，如图1~6歩
 *  force：省略了对offset的一致性校验
 *  takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见

--------------------

### 2.5 RedisTemplate访问分片集群 ###

RedisTemplate底层同样基于lettuce实现了分片集群的支持，而使用的步骤与哨兵模式基本一致：

1）引入redis的starter依赖

2）配置分片集群地址

3）配置读写分离

与哨兵模式相比，其中只有分片集群的配置方式略有差异，如下：

spring:
      redis:
        cluster:
          nodes:
            - 192.168.150.101:7001
            - 192.168.150.101:7002
            - 192.168.150.101:7003
            - 192.168.150.101:8001
            - 192.168.150.101:8002
            - 192.168.150.101:8003

--------------------

> 参考：
> 
>  *  [黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目][Redis_redis_redis]
>  *  [Redis哨兵面试题（高频面试题）- Java程序鱼][Redis_- Java]

--------------------

[image-20221107153849437]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/67ffce840bfa4a95bcfad140670c2d55.png
[image-20221107153607526]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/af442819b59f4075bdd806e6714a7189.png
[image-20221107160000419]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/673a3a3a1ff34d0b85cb756cb17f41d3.png
[image-20210702164116027]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/99357ffab36a4105bd7fc06caa3d3cca.png
[image-20210702174255799]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f18b16907a05448bb59327303ddd0e6a.png
[image-20210725155820320]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/c346f1012acb4db0be515d14e8b9e147.png
[image-20210725155850200]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e7846896a8a84642a66e6e1ee5ee02ce.png
[image-20210725160448139]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/8f6de45907514de1b96bdd0d06005840.png
[image-20210725161007099]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3abef4d9a21842ba8fba13ac65258807.png
[image-20210725161241793]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/eceaa9acb3994f57839502d944049a54.png
[image-20210725161401925]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/63f87dd8487c45848e1d094d52068857.png
[image-20210725161506241]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/78a5dfd823a74456abe736dfad1892c7.png
[image-20210725161540841]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/70ff8285f9514cc1a29c1bdc30d83eff.png
[image-20210725161637152]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/9b9f0a0200234d33926433de2cbb9bc5.png
[image-20210725161731738]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/121144b1052f4dc8a41b70500f2d98f7.png
[image-20210725161817642]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/df206a0f8ef941459fab8484199f0cae.png
[image-20210725162030478]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/467acce73a154ec480a2e781ed46ff80.png
[image-20210725162224058]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/db92a4ac10474434921a946a84f836ad.png
[image-20210725162319490]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f848c03225f6474e87b0d55b02c291d4.png
[image-20210725162408979]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/fffc1a7e694f44188fe6e05894ce0fec.png
[image-20210727160803386]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3d548fd292464ed89edd2570eefd47ab.png
[image-20210725162441407]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b504c7d1fe65436d8167ab0e39797a55.png
[Redis_redis_redis]: https://www.bilibili.com/video/BV1cr4y1671t
[Redis_- Java]: https://blog.csdn.net/qq_35620342/article/details/119596176