一 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/
   

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

---

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

3. 新建 redis6380.conf

   include redis.conf
   pidfile /var/run/redis_6380.pid
   port 6380
   dbfilename dump6380.rdb
   appendfilename appendonly6380.aof
   replica-priority 90
   

4. 再复制出两个 conf 文件,修改其中的内容

   • 使用 redis6380.conf 复制出两个 conf 文件：redis6381.conf 与 redis6382.conf

   cp redis6380.conf reids6381.conf
   cp redis6380.conf reids6382.conf
   

   

   • 修改其中的内容

   :%s6380/6381
   

   

   

5. 启动三台 Redis
   
   

6. 设置主从关系

   • 分别使用客户端连接三台 Redis。然后通过 slaveof 命令，指定 6380的 Redis 为 Master

   slaveof 127.0.0.1 6380
   

7. 查看状态信息

   • 查看当前连接的 Redis 的状态信息

   info replication 
   

1.1.1 分级管理

• 若 Redis 主从集群中的 Slave 较多时，数据同步过程会对 Master 形成较大的性能压力。此时可以对这些 Slave 进行分级管理
  
  • 设置方式很简单，只需要让低级别 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。
  

1.2 主从复制原理

1.2.1 主从复制过程

• 当一个 Redis 节点（slave 节点）接收到类似 slaveof 127.0.0.1 6380 的指令后直至其可以从 master持续复制数据，大体经历了如下几个过程：
  

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. 复制偏移量
      
      • 复制偏移量：系统为每个要传送数据进行了编号，该编号从 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
        
   3. 复制积压缓冲区
      • 当 master 有连接的 slave 时，在 master 中就会创建并维护一个队列 backlog，默认大小为 1MB，该队列称为复制积压缓冲区。master 接收到了写操作数据不仅会写入到 master 主存，写入到 master 中为每个 slave 配置的发送缓存，而且还会写入到复制积压缓冲区。其作用就是用于保存最近操作的数据，以备“断点续传”时做数据补偿，防止数据丢失。
   4. psync 同步过程
      
      • 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 伪集群。
  

1. 复制 sentinel.conf
   • 将 Redis 安装目录中的 sentinel.conf 文件复制到 cluster 目录(自定义目录)中。该配置文件中用于存放一些 sentinel 集群中的一些公共配置

   cp sentinel.conf
   

2. 修改 sentinel.conf
   • 修改 cluster/sentinel.conf 配置文件

   1. sentinel monitor
      

      • 该配置用于指定 Sentinel 要监控的 master 是谁，并为 master 起了一个名字<master-name>。该名字在后面很多配置中都会使用。同时指定 Sentinel 集群中决定该master“客观下线状态”判断的法定 sentinel 数量<quorum>。<quorum>的另一个用途与sentinel 的 Leader 选举有关。要求中至少要有 max(quorum, sentinelNum/2+1)个 sentinel 参与，选举才能进行。
      • 这里将该配置注释掉，因为要在后面的其它配置文件中设置，如果不注释就会出现配置冲突。

   2. sentinel auth-pass
      

      • 如果 Redis 主从集群中的主机设置了访问密码，那么该属性就需要指定 master 的主机名与访问密码。以方便 sentinel 监控 master。

   3. 新建 sentinel26380.conf

      • 在 Redis 安装目录下的 cluster 目录中新建 sentinel26380.conf 文件作为 Sentinel 的配置文件
        
      • 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。然后修改其中的内容。
      
      

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 命令的软链接
     
   • 查看 Redis 安装目录中的 src 目录中的 redis-server 与 redis-sentinel 命令，发现这两个命令的大小一模一样。其实，这两个命令本质上是同一个命令
   • 只所以可以启动不同的进程，主要是因为在启动时所加载的配置文件的不同。所以在启动 Sentinel 时，需要指定 sentinel.conf 配置文件
   2. 两种启动方式

   # 方式一，使用 redis-sentinel 命令
   redis-sentinel sentinel26380.conf
   # 方式二，使用 redis-server 命令
   redis-server sentinel26380.conf --sentinel 
   

   3. 启动Sentinel
      
3. 查看 Sentinel 信息
   
4. 查看 sentinel 配置文件
   
5. 易主操作观察

   redis-cli -p 6380 shutdown
   

   • sentinel前台信息
     
   • 在客户端使用info replication观察主从集群的结构
     
   • 查看sentinel配置文件的变化
     

1.3.4 Sentinel 优化配置

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

---

1. sentinel down-after-milliseconds
   
   • 每个 Sentinel 会通过定期发送 ping 命令来判断 master、slave 及其它 Sentinel 是否存活。如果 Sentinel 在该属性指定的时间内没有收到它们的响应，那么该 Sentinel 就会主观认为该主机宕机。默认为 30 秒
2. sentinel parallel-syncs
   

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

3. sentinel failover-timeout
   

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

4. sentinel deny-scripts-reconfig

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

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

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

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

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 选择算法

1.4.5 故障转移过程

1.4.6 节点上线

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

---

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

---

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

---

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