Redis集群

鹦鹉哥
502 阅读16分钟

高可用之哨兵模式

image-20240131151459361.png

Redis-sentinel 本身是一个独立运行的进程，一般sentinel集群节点数至少三个且奇数个，它能监控多个master-slave集群，sentinel节点发现master宕机后能进行自动切换。Sentinel可以监视任意多个主服务器以及主服务器属下的从服务器，并在被监视的主服务器下线时，自动执行故障转移操作。这里需注意sentinel也有single-point-of-failure问题。大致罗列下哨兵用途：

监控：持续监控 master 、slave 是否健康，是否处于预期工作状态。 主从动态切换：当 Master 运行故障，哨兵启动自动故障恢复流程：从 slave 中选择一台作为新 master。 通知机制：竞选出新的master之后，通知客户端与新 master 建立连接；slave 从新的 master 中 replicaof，保障主从数据的一致性。

监控能力

哨兵模式启用的时候，会同步启用叫做Sentinel的进程。sentinel程会向所有的master 和 slaves 以及其他sentinel进程发送心跳包（1s一次），看看是否正常返回响应。

  • 如果slave 没有在规定的时间内响应 sentinel 的 PING 命令 ， sentinel 会认为该实例已经挂了，将它标记为：下线状态；
  • 同理，如果master 没有在规定时间响应 sentinel 的 PING 命令，也会被判定为 offline 状态，只是会多做一步自动切换 master 的流程。

PING 命令的回复有两种情况：

  • 有效回复：返回 +PONG、-LOADING、-MASTERDOWN 任何一种；
  • 无效回复：有效回复之外的回复，或者指定时间内返回任何回复。

但是可能存在一些误判的情况，比如说网络拥塞、master实例假死、请求延迟，导致实例在某个短暂时间段不可用，后续又快速恢复了。 如果这时候被主动下线了，其实整个系统的可用性反而遭到了退化。而且误判之后的一系列操作，master竞选、消息通知，slave 与新 master 同步数据，都会消耗大量资源。所以，误判要不得。 为了保证判断的可靠性，对下线的标识做了区分：一种是主观下线，一种是客观下线。

  • 主观下线

哨兵利用 PING 命令来监测 master、 slave 实例节点的生命状态。如果是无效回复，哨兵就把这个实例节点标记为主观下线 。如果是slave，一般是有多从概念，直接下线即可，但如果是master，就要小心了。一个sentinel容易误判，那就多个sentinel进投票裁决。哨兵机制就是这样的，采用多个实例组成sentinel集群模式进行部署，即哨兵集群。多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。 同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

  • 客观下线

master 是否要下线不能是单个sentinel能够决定的，上面说了会有个sentinel集群 ，所以这个集群就发挥作用了，大家一起投票，超过一半的sentinel 都判断了 主观下线 ，这时候就把 master 标记为客观下线，认为它是真的不行了。 当 master 被判定为客观下线后，就算正式没有master了，当务之急就是赶紧竞选出一个新的master。

  • 如何区别主、客观下线

主观下线是sentinel自己认为节点下线，这时候节点并不是真正的下线；而客观下线是达到一定数量的哨兵（比如超过一半）都认为节点offline了，这时候会进一步触发离线、重新竞选主等一系列操作。 这里的一定数量是一个法定数量（Quorum），是由哨兵监控配置决定的，解释一下该配置：

sentinel monitor     # 举例如下： sentinel monitor mymaster 127.0.0.1 6379 2

这条配置项用于告知哨兵需要监听的主节点：

  • sentinel monitor：代表监控。
  • mymaster：代表主节点的名称，可以自定义。
  • 192.168.11.128：代表监控的主节点 ip，6379 代表端口。
  • 2：法定数量，代表只有两个或两个以上的哨兵认为主节点不可用的时候，才会把 master 设置为客观下线状态，然后进行下线操作。

客观下线的标准就是，当有 N 个哨兵实例时，要有 N/2 + 1 个实例判断 master 为主观下线 ，才能最终判定 master 为 客观下线 ，其实就是过半机制。

主从状态切换

从多个slave中选举出一个新的master，需要通过筛选 + 综合评估 方式进行选举： 筛选

  • 过滤掉不健康的（下线或者断线），没有回复哨兵ping响应的从节点。
  • 评估实例过往的网络连接状况

down-after-milliseconds，如果一定周期内（如24h）从库和主库经常断连，而且超出了一定的阈值（如 10 次），则该slave不予考虑。 这样，就保留下比较健康的实例了。 综合评估 筛选掉不健康的实例之后，就可以对于剩下健康的实例按顺序进行综合评估了。

  • slave 优先级，通过 slave-priority 配置项（redis.conf），可以给不同的从库设置不同优先级，优先级高的优先成为master。
  • 选择数据偏移量差距最小的，即slave_repl_offset与 master_repl_offset进度差距，其实就是比较 slave 与 原master 复制进度差距。
  • slave runID，在优先级和复制进度都相同的情况下，选用runID最好的，runID越小说明创建时间越早，优先选为master。先来后到原则。

等这几个条件都评估完，就会选择出最适合slave，把他推举为新的master。

image-20240131152220619.png

信息通知

等推选出最新的master之后，后续所有的写操作都会进入这个master中。所以需要尽快通知到所有的slave，让他们重新 replacaof 到 master上，重新建立runID和slave_repl_offset ，来保证数据的正常传输和主从一致性。如下图所示： image.png

关于哨兵集群

单个哨兵对redis实例的离线判断可能会有误判，所以会有一个sentinel集群的概念，超过一定比例的sentinel（比如 > 1/2）的判断为主观下线，才能形成实质的客观下线。

集群中的哨兵如何实现通信

使用redis的发布订阅能力实现哨兵间通信和 slave 发现。 哨兵之间可以相互通信，主要归功于 Redis 的发布订阅机制。哨兵与 master 建立通信之后，可以利用 master 提供发布订阅机制发布自己的IP、port等信息 master 有一个 sentinel:hello 的专用通道，用于哨兵之间发布和订阅消息。哨兵们都可以通过该通道发布自己的Name、IP、Port消息，同时订阅其他哨兵发布的Name、IP、Port消息。互相发现之后建立起了连接，后续的消息通信就可以直接进行了。

image-20240131152405059.png

哨兵如何与slave实现连接

  • sentinel向master发送 INFO 命令
  • master返回与之关联的slave 列表
  • sentinel 根据 master 返回的 slave 列表，逐个与 salve 建立连接，并且根据这个连接持续监控

哨兵如何与客户端进行事件通知

依旧是通过发布订阅机制，发布不同事件，让客户端在这里订阅消息。客户端可以订阅哨兵的消息，哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。

总结

哨兵主要任务 Redis 哨兵机制是实现 Redis 不间断服务的高可用手段之一。主从架构集群的数据同步，是数据可靠的基础保障；主库宕机，自动执行主从切换是服务不间断的关键支撑。 Redis 哨兵机制实现了主从库的自动切换：

  • 监控 master 与 slave 运行状态，判断是否客观下线；
  • master 客观下线后，选择一个 slave 切换成 master；
  • 通知 slave 和客户端新 master 信息。

哨兵集群原理 为了避免单个哨兵故障后无法进行主从切换，以及为了减少误判率，又引入了哨兵集群；哨兵集群又需要有一些机制来支撑它的正常运行：

  • 基于发布订阅机制实现哨兵集群之间的通信；
  • 基于 INFO 命令获取 slave 列表，帮助哨兵与 slave 建立连接；
  • 通过哨兵的发布订阅，实现了与客户端和哨兵之间的事件通知。

主从切换，并不是随意选择一个哨兵就可以执行，而是通过投票仲裁，选择一个 Leader，由这个 Leader 负责主从切换。

Redis脑裂问题

脑裂是指因为网络原因，导致master节点、slave节点 和 sentinel集群处于不用的网络分区，此时因为sentinel集群无法感知到master的存在，所以将slave节点提升为master节点，此时存在两个不同的master节点就像一个大脑分裂成了两个。 集群脑裂问题中，如果客户端还在基于原来的master节点继续写入数据那么新的master节点将无法同步这些数据，当网络问题解决后sentinel集群将原先的master节点降为slave节点，此时再从新的master中同步数据将造成大量的数据丢失。 Redis处理方案是redis的配置文件中存在两个参数

min-replicas-to-write 3  表示连接到master的最少slave数量
min-replicas-max-lag 10  表示slave连接到master的最大延迟时间

如果连接到master的slave数量 < 第一个参数 且 ping的延迟时间 <= 第二个参数那么master就会拒绝写请求，配置了这两个参数后如果发生了集群脑裂则原先的master节点接收到客户端的写入请求会拒绝就可以减少数据同步之后的数据丢失。

Redis Cluster

image-20240131152739341.png

redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。 Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点（官方推荐不超过1000个节点）。rdis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。

image-20240131152836794.png

Redis Cluster将所有数据划分为16384个slots(槽位)，每个节点负责其中一部分。槽位存储于每个节点中。当Redis Cluster的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个key时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。 常见的分区规则

  1. 节点取余：hash(key) % N
  2. 一致性哈希：一致性哈希环
  3. 虚拟槽哈希：CRC16[key] & 16383

RedisCluster采用了虚拟槽分区方式，具体的实现方式如下：

  1. 采用去中心化的思想，它使用虚拟槽solt分区覆盖到所有节点上，取数据一样的流程，节点之间使用轻量协议通信Gossip来减少带宽占用所以性能很高。
  2. 自动实现负载均衡与高可用，自动实现failover并且支持动态扩展。
  3. 每个Master也需要配置主从，并且内部也是采用哨兵模式，如果有半数节点发现某个异常节点会共同决定更改异常节点的状态。
  4. 如果集群中的master没有slave节点，则master挂掉后整个集群就会进入fail状态，因为集群的slot映射不完整。如果集群超过半数以上的master挂掉，集群都会进入fail状态。
  5. 官方推荐 集群部署至少要3台以上的master节点。

跳转重定位

当客户端向一个错误的节点发出了指令，该节点会发现指令的key所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有key将使用新的槽位映射表。

gossipt协议

gossipt协议包含多种消息，包括ping,pong,meet,fail等等。 meet:某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信； ping:每个节点都会频繁给其他节点发送ping,其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据（类似自己感知到的集群节点增加和移除，hash slot信息 等)。 pong:对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新。 fail:某个节点判断另一个节点fail之后，就发送fai给其他节点，通知其他节点，指定的节点宕机了。 gossipt协议的优缺点：

  • 优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；
  • 缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。

gossip通信的0000端口 每个节点都有一个专门用于节点间g0s$p通信的端口，就是自己提供服务的端口+10000，比如7001，那么用于节点间通信的就是17001端口。每个节点每隔一段时间都会往另外 几个节点发送ping消息，同时其他几点接收到ping消息之后返回pong消息。

网络抖动

真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。 为解决这种问题，Redis Cluster提供了一种选项cluster-noce-timeout，表示当某个节点持续timeout的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换（数据的重新复制）。

Redis集群选举原理分析

当slave发现自己的master变为FAlL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点。 其过程如下：

  1. slave发现自己的master变为FAlL；
  2. 将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息；
  3. 其他节点收到该信息，只有masterl响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack，且只响应第一个发送给他的slave；
  4. 尝试failover的slavel收集master返回的FAILOVER_AUTH_ACK；
  5. slavel收到超过半数master的ack后变成新Master，如果收到的票数相同，则重新进行选举；
  6. slave广播Pong消息通知其他集群节点。

从节点并不是在主节点一进入FAIL状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票。 延迟计算公式： DELAY = 500ms + random(0-500ms)+SLAVE_RANK 1000ms SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举（理论上）。

Redis集群对批量操作命令的支持

对于类似mset、mget这样的多个key的原生批量操作命令，redis集群只支持所有key落在同一slot的情况，如果有多个key一定要用mset命令在redis集群上操作，则可以在key的前面加上{XXX}，这样参数数据分片hash计算的只会是大括号里的值，确保不同的key能落到同一slot里去，示例如下：

mset {user1):1:pame zhuge {user1):1:age 18

假设name和age计算的hash slot值不一样，但是这条命令在集群下执行，redis只会用大括号里的user1做hash slot计算，所以算出来的slot值肯定相同，最后都能落在同一slot。

集群脑裂数据丢失问题

rdis集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。 规避方法：

min-slaves-to-write = 1 表示写数据成功最少同步的slave数量

当客户端发送写请求来时，不设置时，master写入成功立即响应给客户端，设置后，master设置成功也需要至少1个slave节点成功才会给客户端返回响应。 注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要具体场景权衡选择。

avatar
文章
阅读
粉丝