Redis重要知识点总结四-Sentinel(哨兵)、Cluster集群

哨兵(解决人工将从节点晋升为主节点)

Redis的主从复制模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址,对于很多应用场景这
种故障处理的方式是无法接受的。可喜的是Redis从2.8开始正式 提供了Redis Sentinel(哨兵)架构来解决这个问题

1、基本概念

Redis重要知识点总结四-Sentinel(哨兵)、Cluster集群_第1张图片
Redis Sentinel是Redis的高可用实现方案,在实际的生产环境中,对提高整个系统的高可用性是非常有帮助

2、从结点两个作用(分担读压力、作为主节点后备)

Redis的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作用:

  • 第一,作为主节点的一个备份,一旦主节点出了故障不可达的情况,从节点可以作为后备“顶”上来,并且保证数据尽量不丢失(主从复制是最终一致性)。
  • 第二,从节点可以扩展主节点的读能力,一 旦主节点不能支撑住大并发量的读操作,从节点可以在一定程度上帮助主节点分担读压力。

3、Redis Sentinel的高可用性

Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的,不需要人工来介入,所以这套方案很有效地解决Redis的高可用问题。

Redis重要知识点总结四-Sentinel(哨兵)、Cluster集群_第2张图片

整个故障转移的处理逻辑有下面四个步骤:

  • 主节点出现故障,此时两个从节点与主节点失去连接,主从复制失败。
  • 每个Sentinel节点通过定期监控发现主节点出现了故障。
  • 多个Sentinel节点对主节点的故障达成一致,选举出一个sentinel节点作为领导者负责故障转移。
  • Sentinel领导者节点执行了故障转移,整个过程都是自动化完成的。

通过上面介绍的Redis Sentinel逻辑架构以及故障转移的处理,可以看出Redis Sentinel具有一下几个功能:

  • 1、监控:Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。
  • 2、通知:Sentinel节点会将故障转移的结果通知给应用方。
  • 3、主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。
  • 4、配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节点集合,从中获取主节点信息。

Redis Sentinel包含了若干了Sentinel节点,这样做也带来了两个好处:

  • 1、对于节点的故障判断是由多个Sentinel节点共同完成,这样可以有效地防止误判。
  • 2、Sentinel节点集合是由若干个Sentinel节点组成的,这样即使个别Sentinel节点不可用,整个Sentinel节点集合依然是健壮的。

命令

sentinel monitor

代表要判定主节点最终不可达所需要的 票数,一般设置为Sentinel节点的一半加一。

Sentinel节点自动发现了从节点、其余Sentinel节点。

sentinel down-after-milliseconds

sentinel down-after-milliseconds
每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过了down-after-milliseconds配置的时间且没有有效的回复,则判定节点不可达,(单位为毫秒)就是超时时间。这个配置是对节点失败判定的重要依据。

sentinel failover-timeout

sentinel failover-timeout
failover-timeout通常被解释成故障转移超时时间,但实际上它作用于故障转移的各个阶段:
1、选出合适从节点。
2、晋升选出的从节点为主节点。
3、命令其余从节点复制新的主节点。
4、等待原主节点恢复后命令它去复制新的主节点。

四、客户端连接(不是直接连master,如果主结点故障,则无法获取新的主节点)

通过前面的学习,相信读者对Redis Sentinel有了一定的了解,本节将介绍应用方如何正确地连接Redis Sentinel。有人会说这有什么难的,已经知道了主节点的ip地址和端口,用对应编程语言的客户端连接主节点不就可以了吗?但试想一下,如果这样使用客户端,客户端连接Redis Sentinel和主从复制的Redis又有什么区别呢,如果主节点挂掉了,虽然Redis Sentinel可以完 成故障转移,但是客户端无法获取这个变化,那
么使用Redis Sentinel的意义就不大了,所以各个语言的客户端需要对Redis Sentinel进行显式的支持。

Sentinel节点集合具备了监控、通知、自动故障转移、配置提供者若干功能,也就是说实际上最了解主节点信息的就是Sentinel节点集合,而各个 主节点可以通过进行标识的,所以,无论是哪种编程语言的客户端,如果需要正确地连接Redis Sentinel,必须有Sentinel节点集合和masterName两个参数。

Redis Sentinel的基本实现原理,具体包含以下几个方面:

  • 1、Redis Sentinel的三个定时任务
  • 2、主观下线和客观下线
  • 3、Sentinel领导者选举
  • 4、故障转移

定时任务

1、每隔1秒,每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测,来确认这些节点当前是否可达。
2、每隔2秒,每个Sentinel节点会向Redis数据节点的__sentinel__:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息(如图9-27所示),同时每个Sentinel节点也会订阅该频道,来了解其他Sentinel节点以及它们对主节点的判断,所以这个定时任务可以完成以下两个工作:
3、每隔10秒,每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。

领导者Sentinel节点选举

  • 1、每个在线的Sentinel节点都有资格成为领导者,当它确认主节点主观下线时候,会向其他Sentinel节点发送sentinel is-master-down-by-addr命令,要求将自己设置为领导者。
  • 2、收到命令的Sentinel节点,如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令,将同意该请求,否则拒绝。
  • 3、如果该Sentinel节点发现自己的票数已经大于等于max(quorum,num(sentinels)/2+1),那么它将成为领导者。
  • 4、如果此过程没有选举出领导者,将进入下一次选举。

Cluster集群

1、数据分布

分布式数据库首先要解决把整个数据集按照分区规则映射到多个节点的问题,即把数据集划分到多个节点上,每个节点负责整体数据的一个子集。

需要重点关注的是数据分区规则。常见的分区规则有哈希分区和顺序分区两种。

Redis重要知识点总结四-Sentinel(哨兵)、Cluster集群_第3张图片

节点取余哈希

使用特定的数据,如Redis的键或用户ID,再根据节点数量N使用公式:hash(key)%N计算出哈希值,用来决定数据映射到哪一个节点上。这种方案存在一个问题:当节点数量变化时,如扩容或收缩节点,数据节点映射关系需要重新计算,会导致数据的重新迁移。
Redis重要知识点总结四-Sentinel(哨兵)、Cluster集群_第4张图片

一致性哈希

一致性哈希分区(Distributed Hash Table)实现思路是为系统中每个节点分配一个token,范围一般在0~2^32,这些token构成一个哈希环。数据读写执行节点查找操作时,先根据key计算hash值,然后顺时针找到第一个大于 等于该哈希值的token节点,

集群功能限制

1)key批量操作支持有限。如mset、mget,目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于执行mget、mget等操
作可能存在于多个节点上因此不被支持。
2)key事务操作支持有限。同理只支持多key在同一节点上的事务操作,当多个key分布在不同的节点上时无法使用事务功能。
3)key作为数据分区的最小粒度,因此不能将一个大的键值对象如hash、list等映射到不同的节点。
4)不支持多数据库空间。单机下的Redis以支持16个数据库,集群模式下只能使用一个数据库空间,即db0。
5)复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。

虚拟槽分区

redis cluster引入槽的概念,一定要与一致性hash的槽区分!这里每一个槽映射一个数据集。

虚拟槽分区巧妙地使用了哈希空间,使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中,整数定义为槽(slot)。
这个范围一般远远大于节点数,比如Redis Cluster槽范围是0~16383。槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是
为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽。

当前集群有5个节点,每个节点平均大约负责3276个槽。由于用高质量的哈希算法,每个槽所映射的数据通常比较均匀,将数据平均划分到5个节点进行数据分区。Redis Cluster就是采用虚拟槽分区,下面就介绍Redis数 据分区方法。

搭建集群

介绍完Redis集群分区规则之后,我们开始搭建Redis集群。搭建集群工作需要以下三个步骤:
1)准备节点。
2)节点握手。
3)分配槽。

你可能感兴趣的:(Redis)