Redis学习【10】之Redis主从集群(1)

太过爱你忘了你带给我的痛 2024-03-26 11:53 67阅读 0赞

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

*  一 Redis主从集群搭建
 *   *  1 伪集群搭建与配置
     *   *  1.1.1 分级管理
         *  1.1.2 容灾冷处理
     *  1.2 主从复制原理
     *   *  1.2.1 主从复制过程
         *  1.2.2 数据同步演变过程
     *  1.3 哨兵机制实现
     *   *  1.3.1 哨兵机制简介
         *  1.3.2 Redis 高可用集群搭建
         *  1.3.3 Redis 高可用集群的启动
         *  1.3.4 Sentinel 优化配置
     *  1.4 哨兵机制原理
     *   *  1.4.1 三个定时任务
         *  1.4.2 Redis 节点下线判断
         *  1.4.3 Sentinel Leader 选举
         *  1.4.4 master 选择算法
         *  1.4.5 故障转移过程
         *  1.4.6 节点上线

## 一 Redis主从集群搭建 ##

*  **为了避免 Redis 的单点故障问题，可以搭建一个 Redis 集群，将数据备份到集群中的其它节点上。若一个 Redis 节点宕机，则由集群中的其它节点顶上。**
 *  Redis 的主从集群是一个“一主多从”的读写分离集群。集群中的 Master 节点负责处理客户端的读写请求，而 Slave 节点仅能处理客户端的读请求。
 *  将集群搭建为读写分离模式，主要原因是：**对于数据库集群，写操作压力一般都较小，压力大多数来自于读操作请求。只有一个节点负责处理写操作请求即可。**

### 1 伪集群搭建与配置 ###

*  在采用单线程 IO 模型时，为了提高处理器的利用率，一般会在一个主机中安装多台 Redis，构建一个 Redis 主从伪集群。

1.  复制 redis.conf
    
     *  在 redis 安装目录中创建一个目录（如： cluster）。然后将 `redis.conf`文件复制到 cluster 目录中。（该文件后面会被其它配置文件包含，所以该文件中需要设置每个 Redis 节点相同的公共的属性）
    
        mkdir cluster/
    
        cp redis.conf cluster/

![在这里插入图片描述][1fef61fe7110454188840d1c529950ef.png]

1.  修改 redis.conf
    
     *  `masterauth`  
        ![在这里插入图片描述][8f565d70f2b546639ce8a9addb94f887.png]
     *  **搭建主从集群，每个主机都有可能会是 Master，所以不要设置密码验证属性 requirepass。如果真需要设置，一定要每个主机的密码都设置为相同的。** 此时每个配置文件中都要设置两个完全相同的属性：`requirepass 与 masterauth`。其中 `requirepass`用于指定当前主机的访问密码，而 `masterauth` 用于指定当前 slave 访问 `master` 时向 `master` 提交的访问密码，用于让 `master` 验证身份是否合法。
     *  `repl-disable-tcp-nodelay`  
        ![在这里插入图片描述][96d705f99ccf448e9dc71ab9cdd75713.png]
     *  该属性用于设置是否禁用 TCP 特性 `tcp-nodelay`
        
         *  **设置为 yes 则禁用 `tcp-nodelay`，此时`master` 与 `slave` 间的通信会产生延迟，但使用的 TCP 包数量会较少，占用的网络带宽会较小。**
         *  **如果设置为 no，则网络延迟会变小，但使用的 TCP 包数量会较多，相应占用的网络带宽会大。**

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

>  *  `tcp-nodelay`：为了充分复用网络带宽，TCP 总是希望发送尽可能大的数据块。为了达到该目的，TCP 中使用了一个名为 Nagle 的算法。
>  *  `Nagle`算法的工作原理：网络在接收到要发送的数据后，并不直接发送，而是等待着数据量足够大（由 TCP 网络特性决定）时再一次性发送出去。保证网络上传输的有效数据比例大大提升，无效数据传递量极大减少，节省网络带宽，缓解网络压力。
>  *  `tcp-nodelay` 则是 TCP 协议中 Nagle 算法的开头。

1.  新建 redis6380.conf
    
        include redis.conf
        pidfile /var/run/redis_6380.pid
        port 6380
        dbfilename dump6380.rdb
        appendfilename appendonly6380.aof
        replica-priority 90
2.  再复制出两个 conf 文件,修改其中的内容
    
     *  使用 redis6380.conf 复制出两个 conf 文件：redis6381.conf 与 redis6382.conf
    
        cp redis6380.conf reids6381.conf
        cp redis6380.conf reids6382.conf
    
    ![在这里插入图片描述][d18b4508f1404fbb8ae686a45ba8587d.png]
    
     *  修改其中的内容
    
        :%s6380/6381
    
    ![在这里插入图片描述][023c4da2c936489083281af1b9ddfdd4.png]
    
    ![在这里插入图片描述][1b465c23a4e04a808b17dbe80a35fb92.png]
3.  启动三台 Redis  
    ![在这里插入图片描述][c074935c795042829434ad419cba8fd6.png]  
    ![在这里插入图片描述][4c2563fbc0db4fe784cf6b5ad1e8976f.png]
4.  设置主从关系
    
     *  分别使用客户端连接三台 Redis。然后通过 `slaveof` 命令，指定 6380的 `Redis` 为 `Master`
    
        slaveof 127.0.0.1 6380
5.  查看状态信息
    
     *  查看当前连接的 Redis 的状态信息
    
        info replication

![在这里插入图片描述][d87544d732cf42f8a2e6e236d1eeaaf5.png]

#### 1.1.1 分级管理 ####

*  若 Redis 主从集群中的 Slave 较多时，数据同步过程会对 Master 形成较大的性能压力。此时可以对这些 Slave 进行分级管理  
    ![在这里插入图片描述][2129622a381b4a85bed92d5dea72d10b.png]
    
     *  设置方式很简单，只需要让低级别 Slave 指定其 slaveof 的主机为其上一级 Slave 即可。

#### 1.1.2 容灾冷处理 ####

*  在 `Master/Slave` 的 Redis 集群中，若 Master 出现宕机,有两种处理方式：**一种是通过手工角色调整，使 Slave 晋升为 Master 的冷处理；一种是使用哨兵模式，实现 Redis集群的高可用 HA，即热处理。**
 *  无论 Master 是否宕机，Slave 都可通过 `slaveof no one` 命令将自己由 `Slave` 晋升为 `Master`。如果其原本就有下一级的 `Slave`，那么其就直接变为这些 `Slave`的真正的 `Master` ，而原来的 `Master` 也会失去这个原来的 `Slave`。  
    ![在这里插入图片描述][b59b790695484eceaed59e11eda2c8c5.png]

### 1.2 主从复制原理 ###

#### 1.2.1 主从复制过程 ####

*  当一个 Redis 节点（slave 节点）接收到类似 `slaveof 127.0.0.1 6380` 的指令后直至其可以从 `master`持续复制数据，大体经历了如下几个过程：  
    ![在这里插入图片描述][eb54767c281c47068432208311343717.png_pic_center]

1.  保存 master 地址
    
     *  当 slave 接收到 slaveof 指令后，slave 会立即将新的 master 的地址保存下来。
2.  建立连接
    
     *  slave 中维护着一个定时任务，该定时任务会尝试着与该 master 建立 socket 连接。如果连接无法建立，则其会不断定时重试，直到连接成功或接收到 slaveof no one 指令。
3.  slave 发送 ping 命令
    
     *  连接建立成功后，slave 会发送 ping 命令进行首次通信。如果 slave 没有收到 master 的回复，则 slave 会主动断开连接，下次的定时任务会重新尝试连接。
4.  对 slave 身份验证
    
     *  如果 master 收到了 slave 的 ping 命令，并不会立即对其进行回复，而是会先进行身份验证。如果验证失败，则会发送消息拒绝连接；如果验证成功，则向 slave 发送连接成功响应。
5.  master 持久化
    
     *  首次通信成功后，slave 会向 master 发送数据同步请求。当 master 接收到请求后，会 fork  
        出一个子进程，让子进程以异步方式立即进行持久化。
6.  数据发送
    
     *  持久化完毕后 master 会再 fork 出一个子进程，让该子进程以异步方式将数据发送给slave。slave 会将接收到的数据不断写入到本地的持久化文件中。
     *  在 slave 数据同步过程中，master 的主进程仍在不断地接受着客户端的写操作，且不仅将新的数据写入到了 master 内存，同时也写入到了同步缓存。当 master 的持久化文件中的数据发送完毕后，master 会再将同步缓存中新的数据发送给 slave，由 slave 将其写入到本地持久化文件中。数据同步完成。
7.  slave 恢复内存数据
    
     *  当 slave 与 master 的数据同步完成后，slave 就会读取本地的持久化文件，将其恢复到本地内存，然后就可以对外提供读服务了
8.  持续增量复制
    
     *  在 slave 对外提供服务过程中，master 会持续不断的将新的数据以增量方式发送给 slave，以保证主从数据的一致性。

#### 1.2.2 数据同步演变过程 ####

1.  sync 同步
    
     *  \*\*Redis 2.8 版本之前，首次通信成功后，slave 会向 master 发送 sync 数据同步请求。然后master 就会将其所有数据全部发送给 slave，由 slave 保存到其本地的持久化文件中，这个过程称为全量复制。\*\*但存在一个问题：在全量复制过程中可能会出现由于网络抖动而导致复制过程中断。当网络恢复后，slave 与 master 重新连接成功，此时 slave 会重新发送 sync 请求，然后会从头开始全量复制。
     *  **由于全量复制过程非常耗时，所以期间出现网络抖动的概率很高。而中断后的从头开始不仅需要消耗大量的系统资源、网络带宽，而且可能会出现长时间无法完成全量复制的情况。**
2.  psync 同步
    
     *  Redis 2.8 版本之后，全量复制采用了 psync（Partial Sync，不完全同步）同步策略。当全量复制过程出现由于网络抖动而导致复制过程中断时，当重新连接成功后，复制过程可以“断点续传”。即从断开位置开始继续复制，而不用从头再来。大大提升了性能。  
        为了实现 psync，整个系统做了三个大的变化：
    
    1.  复制偏移量  
        ![在这里插入图片描述][f853c42c0ac546639a7f7af73650490c.png]
        
         *  复制偏移量：系统为每个要传送数据进行了编号，该编号从 0 开始，每个字节一个编号。参与复制的主从节点都会维护该复制偏移量。
         *  master 每发送过一个字节数据后就会进行累计。统计信息通过 info replication 的master\_repl\_offset 可查看到。同时，slave 会定时向 master 上报其自身已完成的复制偏移量给 master，所以 master 也会保存 slave 的复制偏移量 offset
    2.  主节点复制 ID
        
         *  当 master 启动后就会动态生成一个长度为 40 位的 16 进制字符串作为当前 master 的复制 ID，该 ID 是在进行数据同步时 slave 识别 master 使用的。通过 `info replication` 的 `master_replid` 属性可查看到该 ID  
            ![在这里插入图片描述][39f3178d79954266a55acf059b08c9dd.png]
    3.  复制积压缓冲区
        
         *  当 master 有连接的 slave 时，在 master 中就会创建并维护一个队列 backlog，默认大小为 1MB，该队列称为复制积压缓冲区。master 接收到了写操作数据不仅会写入到 master 主存，写入到 master 中为每个 slave 配置的发送缓存，而且还会写入到复制积压缓冲区。其作用就是用于保存最近操作的数据，以备“断点续传”时做数据补偿，防止数据丢失。
    4.  psync 同步过程  
        ![在这里插入图片描述][bf02b834fcc54b119a196f28d290fa2a.png]
        
         *  psync 是一个由 slave 提交的命令，其格式为 `psync <master_replid> <repl_offset>`，表示当前 slave 要从指定的 `master 中的 repl_offset+1`处开始复制。`repl_offset` 表示当前 `slave` 已经完成复制的数据的 `offset`。该命令保证了“断点续传”的实现。
         *  在第一次开始复制时，slave 并不知道 master 的动态 ID，并且一定是从头开始复制，所以其提交的 `psync` 命令为 `PSYNC ? -1`。即 `master_replid` 为问号(?)，`repl_offset` 为-1。
         *  如果复制过程中断后 slave 与 master 成功连接，则 slave 再次提交 psyn 命令。此时的 psyn命令的 repl\_offset 参数为其前面已经完成复制的数据的偏移量。
         *  其实，并不是slave提交了psyn命令后就可以立即从master处开始复制，而是需要master给出响应结果后，根据响应结果来执行。master根据 slave 提交的请求及 master 自身情况会给出不同的响应结果。响应结果有三种可能：
            
             *  FULLRESYNC <master\_replid> <repl\_offset>：告知 slave 当前 master 的动态 ID 及可以开始全量复制了，这里的 repl\_offset 一般为 0
             *  CONTINUE：告知 slave 可以按照你提交的 repl\_offset 后面位置开始“续传”了
             *  ERR：告知 slave，当前 master 的版本低于 Redis 2.8，不支持 psyn，你可以开始全量复制了
    5.  psync 存在的问题
        
         *  在 psync 数据同步过程中，若 slave 重启，在 slave 内存中保存的 master 的动态 ID 与续传 offset 都会消失，“断点续传”将无法进行，从而只能进行全量复制，导致资源浪费。
         *  在 psync 数据同步过程中，master 宕机后 slave 会发生“易主”，从而导致 slave 需要从新 master 进行全量复制，形成资源浪费。
3.  psync 同步的改进
    
     *  Redis 4.0 对 psync 进行了改进，提出了“同源增量同步”策略。
    
    1.  解决 slave 重启问题
        
         *  针对“slave 重启时 master 动态 ID 丢失问题”，改进后的 **psync 将 master 的动态 ID 直接写入到了 slave 的持久化文件中**。
         *  slave 重启后直接从本地持久化文件中读取 master 的动态 ID，然后向 master 提交获取复制偏移量的请求。master 会根据提交请求的 slave 地址，查找到保存在 master 中的复制偏移量，然后向 slave 回复 FULLRESYNC <master\_replid> <repl\_offset>，以告知 slave 其马上要开始发送的位置。然后 master 开始“断点续传”。
    2.  解决 slave 易主问题
        
         *  slave 易主后需要和新 master 进行全量复制，本质原因是新 master 不认识 slave 提交的psync 请求中“原 master 的动态 ID”。如果 slave 发送 `PSYNC <原 master_replid> <repl_offset>`命令，新master能够识别出该slave要从原master复制数据，而自己的数据也都是从该master复制来的。那么新 master 就会明白，其与该 slave“师出同门”，应该接收其“断点续传”同步请求。
         *  \*\*而新 master 中恰好保存的有“原 master 的动态 ID”。由于改进后的 psync 中每个 slave都在本地保存了当前 master 的动态 ID，所以当 slave 晋升为新的 master 后，其本地仍保存有之前 master 的动态 ID。\*\*而这一点也恰恰为解决“slave 易主”问题提供了条件。通过 master的 `info replicaton` 中的 `master_replid2` 可查看到。如果尚未发生过易主，则该值为 40 个 0。
4.  无盘操作
    
     *  Redis 6.0 对同步过程又进行了改进，提出了\*\*“无盘全量同步”与“无盘加载”策略，避免了耗时的 IO 操作\*\*。
        
         *  **无盘全量同步：master 的主进程 fork 出的子进程直接将内存中的数据发送给 slave，无需经过磁盘。**
         *  **无盘加载：slave 在接收到 master 发送来的数据后不需要将其写入到磁盘文件，而是直接写入到内存，这样 slave 就可快速完成数据恢复。**
5.  共享复制积压缓冲区
    
     *  Redis 7.0 版本对复制积压缓冲区进行了改进，**让各个 slave 的发送缓冲区共享复制积压缓冲区**。这使得复制积压缓冲区的作用，除了可以保障数据的安全性外，还作为所有 slave的发送缓冲区，充分利用了复制积压缓冲区

### 1.3 哨兵机制实现 ###

#### 1.3.1 哨兵机制简介 ####

*  对于 Master 宕机后的冷处理方式是无法实现高可用的。Redis 从 2.6 版本开始提供了高可用的解决方案—— Sentinel 哨兵机制。在集群中再引入一个节点，该节点充当 Sentinel 哨兵，用于监视 Master 的运行状态，并在 Master 宕机后自动指定一个 Slave 作为新的 Master。  
    整个过程无需人工参与，完全由哨兵自动完成。
 *  问题：**Sentinel 哨兵又成为了一个单点故障点：若哨兵发生宕机，整个集群将瘫痪。** **为了解决 Sentinel 的单点问题，又要为 Sentinel 创建一个集群，即 Sentinel 哨兵集群。一个哨兵的宕机，将不会影响到 Redis 集群的运行**
 *  Sentinel哨兵工作方式
    
     *  每个 Sentinel 都会定时会向 Master 发送心跳，如果 Master 在有效时间内向它们都进行了响应，则说明 Master 是“活着的”。如果 Sentinel 中有 quorum 个哨兵没有收到响应，那么就认为 Master 已经宕机，然后会有一个 Sentinel 做 Failover 故障转移。即将原来的某一个 Slave晋升为 Master

#### 1.3.2 Redis 高可用集群搭建 ####

*  下面搭建一个“一主二从三哨兵”的高可用伪集群，即这些角色全部安装运行在一台主机上。“一主二从”使用前面的主从集群，仅搭建一个 Sentinel 伪集群。  
    ![在这里插入图片描述][f0922a304ab147b1b5a851b72ac71f9e.png]

1.  复制 sentinel.conf
    
     *  将 Redis 安装目录中的 sentinel.conf 文件复制到 `cluster` 目录(自定义目录)中。该配置文件中用于存放一些 sentinel 集群中的一些公共配置
    
        cp sentinel.conf
2.  修改 sentinel.conf
    
     *  修改 cluster/sentinel.conf 配置文件
    
    1.  sentinel monitor  
        ![在这里插入图片描述][6daefb145b054adb884e510eb74804d3.png]
        
         *  该配置用于指定 Sentinel 要监控的 master 是谁，并为 master 起了一个名字`<master-name>`。该名字在后面很多配置中都会使用。同时指定 Sentinel 集群中决定该master“客观下线状态”判断的法定 sentinel 数量`<quorum>`。`<quorum>`的另一个用途与sentinel 的 Leader 选举有关。要求中至少要有 `max(quorum, sentinelNum/2+1)`个 sentinel 参与，选举才能进行。
         *  这里将该配置注释掉，因为要在后面的其它配置文件中设置，如果不注释就会出现配置冲突。
    2.  sentinel auth-pass  
        ![在这里插入图片描述][815284d8442d402a91399697e9c275ca.png]
        
         *  如果 Redis 主从集群中的主机设置了访问密码，那么该属性就需要指定 master 的主机名与访问密码。以方便 sentinel 监控 master。
    3.  新建 sentinel26380.conf
        
         *  在 Redis 安装目录下的 cluster 目录中新建 sentinel26380.conf 文件作为 Sentinel 的配置文件  
            ![在这里插入图片描述][fb4c3c3b150845609681455e9d3190f1.png]
         *  sentinel monitor 属性用于指定当前监控的 master 的 IP 与 Port，同时为集群中 master 指定一个名称 mymaster，以方便其它属性使用。
         *  **2 是参数 quorum 的值，quorum 有两个用途：一个是只有当 quorum 个 sentinel都认为当前 master 宕机了才能开启故障转移。另一个用途与 sentinel 的 Leader 选举有关。要求中至少要有 max(quorum, sentinelNum/2+1)个 sentinel 参与，选举才能进行**
    4.  再复制两个 conf 文件再使用sentinel26380.conf 复制出两个conf文件：sentinel26381.conf与sentinel26382.conf。然后修改其中的内容。  
        ![在这里插入图片描述][1eee3ffd509544d8a1e69bb464e337b6.png]  
        ![在这里插入图片描述][7065a3766f084a338698d3047381a8c1.png]

#### 1.3.3 Redis 高可用集群的启动 ####

1.  启动并关联 Redis 集群
    
     *  首先要启动三台 Redis，然后再通过 slaveof 关联它们
    
        redis-cli -p 6381 slaveof 127.0.0.1 6380
        redis-cli -p 6382 slaveof 127.0.0.1 6380
2.  启动 Sentinel 集群
    
    1.  启动命令
    
     *  /usr/local/bin 目录中的 redis-sentinel 命令是 redis-server 命令的软链接  
        ![在这里插入图片描述][d408d5c542c846c79cadec15a076bdce.png]
     *  查看 Redis 安装目录中的 src 目录中的 redis-server 与 redis-sentinel 命令，发现这两个命令的大小一模一样。其实，这两个命令本质上是同一个命令
     *  只所以可以启动不同的进程，主要是因为在启动时所加载的配置文件的不同。所以在启动 Sentinel 时，需要指定 sentinel.conf 配置文件
    
    1.  两种启动方式
    
        # 方式一，使用 redis-sentinel 命令
        redis-sentinel sentinel26380.conf
        # 方式二，使用 redis-server 命令
        redis-server sentinel26380.conf --sentinel
    
    1.  启动Sentinel  
        ![在这里插入图片描述][acf06609ed054ccead01b7f0cb0b5ff0.png]
3.  查看 Sentinel 信息  
    ![在这里插入图片描述][d75de2ade808465185877f8f4840405d.png]
4.  查看 sentinel 配置文件  
    ![在这里插入图片描述][91eeda6ca0c64aa88f47cb4129cfe205.png]
5.  易主操作观察
    
        redis-cli -p 6380 shutdown
    
     *  sentinel前台信息  
        ![在这里插入图片描述][aa70609a605c4f47a9ba9073d34ff3dc.png]
     *  在客户端使用`info replication`观察主从集群的结构  
        ![在这里插入图片描述][748899b7e39d42aeab016da81b587283.png]
     *  查看sentinel配置文件的变化  
        ![在这里插入图片描述][7c05ca6698344cdc9c8a29df703ea1ab.png]

#### 1.3.4 Sentinel 优化配置 ####

*  在公共的 sentinel.conf 文件中，还可以通过修改一些其它属性的值来达到对 Sentinel 的配置优化

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

1.  `sentinel down-after-milliseconds`  
    ![在这里插入图片描述][4100729c1242472fb847b18f25c2ea0e.png]
    
     *  每个 Sentinel 会通过定期发送 ping 命令来判断 master、slave 及其它 Sentinel 是否存活。如果 Sentinel 在该属性指定的时间内没有收到它们的响应，那么该 Sentinel 就会主观认为该主机宕机。默认为 30 秒
2.  `sentinel parallel-syncs`  
    ![在这里插入图片描述][59579b2d32a84e8b9436ca80f4744095.png]

*  该属性用于指定，在故障转移期间，即原的 master 出现问题，新的 master 刚晋升后，允许多少个 slave 同时从新 master 进行数据同步。默认值为 1 表示所有 slave 逐个从新 master进行数据同步。

1.  sentinel failover-timeout  
    ![在这里插入图片描述][717f4cd4fc80497facddbe3764c17e29.png]

*  指定故障转移的超时时间，默认时间为 3 分钟。该超时时间的用途：
    
     *  由于第一次故障转移失败，在同一个 `master` 上进行第二次故障转移尝试的时间为该`failover-timeout` 的两倍
     *  新 master 晋升完毕，slave 从原 master 强制转到新 master 进行数据同步的时间阈值。
     *  取消正在进行的故障转换所需的时间阈值。
     *  新 master 晋升完毕，所有 replicas 的配置文件更新为新 master 的时间阈值

1.  `sentinel deny-scripts-reconfig`![在这里插入图片描述][2e45724eb79c4420a8582f1bc7906c98.png]

*  指定是否可以通过命令 `sentinel set` 动态修改 `notification-script` 与 `client-reconfig-script` 两个脚本。默认是不能的。这两个脚本如果允许动态修改，可能会引发安全问题

1.  动态修改配置
    
     *  通过 redis-cli 连接上 Sentinel 后，通过 sentinel set 命令可动态修改配置信息

# 进入客户端进行修改
    sentinel set mymaster quorum 2

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>示例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>quorum</td> 
   <td>sentinel set mymaster quorum 2</td> 
  </tr> 
  <tr> 
   <td>down-after-milliseconds</td> 
   <td>sentinel set mymaster down-after-milliseconds 50000</td> 
  </tr> 
  <tr> 
   <td>failover-timeout</td> 
   <td>sentinel set mymaster failover-timeout 300000</td> 
  </tr> 
  <tr> 
   <td>parallel-syncs</td> 
   <td>sentinel set mymaster parallel-syncs 3</td> 
  </tr> 
  <tr> 
   <td>notification-script</td> 
   <td>sentinel set mymaster notification-script /var/redis/notify.sh</td> 
  </tr> 
  <tr> 
   <td>client-reconfig-script</td> 
   <td>sentinel set mymaster client-reconfig-script /var/redis/reconfig.sh</td> 
  </tr> 
  <tr> 
   <td>auth-pass sentinel</td> 
   <td>set mymaster auth-pass 111</td> 
  </tr> 
 </tbody> 
</table>

### 1.4 哨兵机制原理 ###

#### 1.4.1 三个定时任务 ####

*  Sentinel 维护着三个定时任务以监测 Redis 节点及其它 Sentinel 节点的状态

1.  info 任务
    
     *  每个 Sentinel 节点每 10 秒就会向 Redis 集群中的每个节点发送 info 命令，以获得最新的Redis 拓扑结构
2.  心跳任务
    
     *  每个Sentinel节点每1秒就会向所有Redis节点及其它Sentinel节点发送一条ping命令，以检测这些节点的存活状态。该任务是判断节点在线状态的重要依据。
3.  发布/订阅任务
    
     *  每个 Sentinel 节点在启动时都会向所有 Redis 节点订阅`_ _sentinel_ _:hello` 主题的信息，当 Redis 节点中该主题的信息发生了变化，就会立即通知到所有订阅者。
     *  启动后，每个 Sentinel 节点每 2 秒就会向每个 Redis 节点发布一条`_ _sentinel_ _:hello` 主题的信息，该信息是当前 Sentinel 对每个 Redis 节点在线状态的判断结果及当前 Sentinel 节点信息。
     *  当 Sentinel 节点接收到`_ _sentinel_ _:hello`主题信息后，就会读取并解析这些信息，主要完成以下三项工作：
     *  如果发现有新的 Sentinel 节点加入，则记录下新加入 Sentinel 节点信息，并与其建立连接。
     *  如果发现有 Sentinel Leader 选举的选票信息，则执行 Leader 选举过程。
     *  汇总其它 Sentinel 节点对当前 Redis 节点在线状态的判断结果，作为 Redis 节点客观下线的判断依据。

#### 1.4.2 Redis 节点下线判断 ####

*  对于每个 Redis 节点在线状态的监控是由 Sentinel 完成的

1.  主观下线
    
     *  每个 Sentinel 节点每秒就会向每个 Redis 节点发送 ping 心跳检测，如果 Sentinel 在down-after-milliseconds 时间内没有收到某 Redis 节点的回复，则 Sentinel 节点就会对该 Redis节点做出“下线状态”的判断。这个判断仅仅是当前 Sentinel 节点的“一家之言”，所以称为主观下线。
2.  客观下线
    
     *  当 Sentinel 主观下线的节点是 master 时，该 Sentinel 节点会向每个其它 Sentinel 节点发送 sentinel is-master-down-by-addr 命令，以询问其对 master 在线状态的判断结果。这些Sentinel 节点在收到命令后会向这个发问 Sentinel 节点响应 0（在线）或 1（下线）。当 Sentinel收到超过 quorum 个下线判断后，就会对 master 做出客观下线判断

#### 1.4.3 Sentinel Leader 选举 ####

*  当 Sentinel 节点对 master 做出客观下线判断后会由 Sentinel Leader 来完成后续的故障转移，即 Sentinel 集群中的节点也并非是对等节点，是存在 Leader 与 Follower 的。
 *  Sentinel 集群的 Leader 选举是通过 Raft 算法实现的
    
     *  每个选举参与者都具有当选 Leader 的资格，当其完成了“客观下线”判断后，就会立即“毛遂自荐”推选自己做 Leader，然后将自己的提案发送给所有参与者。其它参与者在收到提案后，只要自己手中的选票没有投出去，其就会立即通过该提案并将同意结果反馈给提案者，后续再过来的提案会由于该参与者没有了选票而被拒绝。当提案者收到了同意反馈数量大于等于 `max(quorum，sentinelNum/2+1)`时，该提案者当选 Leader。
     *  说明：
        
         *  在网络没有问题的前提下，基本就是谁先做出了“客观下线”判断，谁就会首先发起Sentinel Leader 的选举，谁就会得到大多数参与者的支持，谁就会当选 Leader。
         *  Sentinel Leader 选举会在次故障转移发生之前进行。
         *  故障转移结束后 Sentinel 不再维护这种 Leader-Follower 关系，即 Leader 不再存在

#### 1.4.4 master 选择算法 ####

![在这里插入图片描述][d65de70461d1453a851fdc6a53d8b73a.png]

#### 1.4.5 故障转移过程 ####

![在这里插入图片描述][367c6c3e34c74430aad67880219c72fe.png]

#### 1.4.6 节点上线 ####

*  不同的节点类型，其上线的方式也是不同的

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

1.  原 Redis 节点上线
    
     *  无论是原下线的 master 节点还是原下线的 slave 节点，只要是原 Redis 集群中的节点上线，只需启动 Redis 即可。因为每个 Sentinel 中都保存有原来其监控的所有 Redis 节点列表，Sentinel 会定时查看这些 Redis 节点是否恢复。如果查看到其已经恢复，则会命其从当前  
        master 进行数据同步。
     *  如果是原 master 上线，在新 master 晋升后 Sentinel Leader 会立即先将原 master节点更新为 slave，然后才会定时查看其是否恢复

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

1.  新 Redis 节点上线
    
     *  如果需要在 Redis 集群中添加一个新的节点，其未曾出现在 Redis 集群中，则上线操作只能手工完成。即添**加者在添加之前必须知道当前 master 是谁，然后在新节点启动后运行slaveof 命令加入集群。**

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

1.  Sentinel 节点上线
    
     *  如果要添加的是 Sentinel 节点，无论其是否曾经出现在 Sentinel 集群中，都需要手工完成。即**添加者在添加之前必须知道当前 master 是谁，然后在配置文件中修改 `sentinel monitor`属性，指定要监控的 master。然后启动 Sentinel 即可**

[1fef61fe7110454188840d1c529950ef.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/e1f42e907ef140eb8bb164fc5aca9c39.png
[8f565d70f2b546639ce8a9addb94f887.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/941801e93f12425d9605a85320be8414.png
[96d705f99ccf448e9dc71ab9cdd75713.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/07aada420c6e4573b6c8b1f0f534b8e0.png
[d18b4508f1404fbb8ae686a45ba8587d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/799508af9c6140ecbb165170dde1d709.png
[023c4da2c936489083281af1b9ddfdd4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/7ff117792a154f60a20d02f28652507a.png
[1b465c23a4e04a808b17dbe80a35fb92.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/05a21d4abcb547afb79e3e3f5c7da92d.png
[c074935c795042829434ad419cba8fd6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/c3079d6e848e4c7091d32c69ca3a4b48.png
[4c2563fbc0db4fe784cf6b5ad1e8976f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/21ac0f2446e74ae5bbfcd5da4272b1df.png
[d87544d732cf42f8a2e6e236d1eeaaf5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d5dc76ff148e4941a61348ceebca7ab6.png
[2129622a381b4a85bed92d5dea72d10b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/047d55337c91443fa6f9c04d52c9eb02.png
[b59b790695484eceaed59e11eda2c8c5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/16326d57059c483081567b2895fc8c8b.png
[eb54767c281c47068432208311343717.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/0bb8ca4edf8e4ba38c50a62e74c99460.png
[f853c42c0ac546639a7f7af73650490c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/a39e99a913cb44f783392228484aa791.png
[39f3178d79954266a55acf059b08c9dd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/669049acb5604424b9a84054b324b319.png
[bf02b834fcc54b119a196f28d290fa2a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/fbf87d9e36fc4ed9a3b86306d6920a3e.png
[f0922a304ab147b1b5a851b72ac71f9e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/e89a74554dac4e15ad937d3cb92a2f4c.png
[6daefb145b054adb884e510eb74804d3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/86d59414fb0e4060bc1a258b728288a9.png
[815284d8442d402a91399697e9c275ca.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/9b72f45ea0954450a234e3dd4fa5c5fd.png
[fb4c3c3b150845609681455e9d3190f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/cf7107b16cc6411194f4eeeec5ec720d.png
[1eee3ffd509544d8a1e69bb464e337b6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/06dedea97b724b769f17b46e37791b9d.png
[7065a3766f084a338698d3047381a8c1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/93abdf1306de4f76a1f75682ac7bf7a9.png
[d408d5c542c846c79cadec15a076bdce.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/57d019a755e34215bfc56d2a39c76c20.png
[acf06609ed054ccead01b7f0cb0b5ff0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/f44e25f81f054d65be46cb4e2a7606c2.png
[d75de2ade808465185877f8f4840405d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/73337b2aaac14b039b8874c2466995f2.png
[91eeda6ca0c64aa88f47cb4129cfe205.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/ebea181fbc044f90ac7b0f050b0752cc.png
[aa70609a605c4f47a9ba9073d34ff3dc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/e1ee9faa30004909a3b1726cef2d0cb6.png
[748899b7e39d42aeab016da81b587283.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/0f222d5e5cee4211ab55769e31886fa2.png
[7c05ca6698344cdc9c8a29df703ea1ab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/54973f813f1b483491970c0177c8048b.png
[4100729c1242472fb847b18f25c2ea0e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/43b1a5a7aa49478a8722b46b055c4f17.png
[59579b2d32a84e8b9436ca80f4744095.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/4869c0aafb6840a483dcc6c41e94bd5b.png
[717f4cd4fc80497facddbe3764c17e29.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/1277746f98e74dfb9b982a7743101ec2.png
[2e45724eb79c4420a8582f1bc7906c98.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/46ec513f03a749228b95fce0832cd617.png
[d65de70461d1453a851fdc6a53d8b73a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/85f5c67d04584de48c7b97fc31853b9f.png
[367c6c3e34c74430aad67880219c72fe.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/4b117e6322c8420ebf7e623ec2e65669.png