Redis主从、哨兵、 Cluster集群、分片等高可用介绍

0    117    1

Tags:

👉 本文共约17236个字,系统预计阅读时间或需65分钟。

背景

在服务开发中,单机都会存在单点故障的问题,即服务部署在一台服务器上,一旦服务器宕机服务就不可用,所以为了让服务高可用,分布式服务就出现了,将同一服务部署到多台机器上,即使其中几台服务器宕机,只要有一台服务器可用服务就可用。

redis也是一样,为了解决单机故障引入了主从模式,但主从模式存在一个问题:master节点故障后服务,需要人为的手动将slave节点切换成为maser节点后服务才恢复。redis为解决这一问题又引入了哨兵模式,哨兵模式能在master节点故障后能自动将salve节点提升成master节点,不需要人工干预操作就能恢复服务可用。

但是主从模式、哨兵模式都没有达到真正的数据sharding存储,每个redis实例中存储的都是全量数据,所以redis cluster就诞生了,实现了真正的数据分片存储。但是由于redis cluster发布得比较晚(2015年才发布正式版 ),各大厂等不及了,陆陆续续开发了自己的redis数据分片集群模式,比如:Twemproxy、Codis等。

1. Redis 主从

Redis高可用包括两个层面,一个就是数据不能丢失,或者说尽量减少丢失;另外一个就是保证Redis服务不中断

  • 对于尽量减少数据丢失,可以通过AOF和RDB保证。
  • 对于保证服务不中断的话,Redis就不能单点部署,这时候我们先看下Redis主从。

redis单节点虽然有通过RDB和AOF持久化机制能将数据持久化到硬盘上,但数据是存储在一台服务器上的,如果服务器出现硬盘故障等问题,会导致数据不可用,而且读写无法分离,读写都在同一台服务器上,请求量大时会出现I/O瓶颈。

为了避免单点故障 和 读写不分离,Redis 提供了复制(replication)功能实现master数据库中的数据更新后,会自动将更新的数据同步到其他slave数据库上。

1.1 Redsi主从概念

  • Redis主从模式,就是部署多台Redis服务器,有主库和从库,它们之间通过主从复制,以保证数据副本的一致。
  • 主从库之间采用的是读写分离的方式,其中主库负责读操作和写操作,从库则负责读操作。
  • 如果Redis主库挂了,切换其中的从库成为主库。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

如上redis主从结构特点:一个master可以有多个salve节点;salve节点可以有slave节点,从节点是级联结构。

主从模式优缺点

  • 优点: 主从结构具有读写分离,提高效率、数据备份,提供多个副本等优点。
  • 不足: 最大的不足就是主从模式不具备自动容错和恢复功能,主节点故障,集群则无法进行工作,可用性比较低,从节点升主节点需要人工手动干预。

普通的主从模式,当主数据库崩溃时,需要手动切换从数据库成为主数据库:

  • 在从数据库中使用SLAVE NO ONE命令将从数据库提升成主数据继续服务。
  • 启动之前崩溃的主数据库,然后使用SLAVEOF命令将其设置成新的主数据库的从数据库,即可同步数据。

1.2 Redis 主从同步过程

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

Redis主从同步包括三个阶段。

第一阶段:主从库间建立连接、协商同步。

  • 从库向主库发送psync 命令,告诉它要进行数据同步。
  • 主库收到 psync 命令后,响应FULLRESYNC命令(它表示第一次复制采用的是全量复制),并带上主库runID和主库目前的复制进度offset

第二阶段:主库把数据同步到从库,从库收到数据后,完成本地加载。

  • 主库执行bgsave命令,生成RDB文件,接着将文件发给从库。从库接收到RDB 文件后,会先清空当前数据库,然后加载 RDB 文件。
  • 主库把数据同步到从库的过程中,新来的写操作,会记录到replication buffer

第三阶段,主库把新写的命令,发送到从库。

  • 主库完成RDB发送后,会把replication buffer中的修改操作发给从库,从库再重新执行这些操作。这样主从库就实现同步啦。

1.3 Redis主从的一些注意点

1.3.1 主从数据不一致

因为主从复制是异步进行的,如果从库滞后执行,则会导致主从数据不一致

主从数据不一致一般有两个原因:

  • 主从库网路延迟。
  • 从库收到了主从命令,但是它正在执行阻塞性的命令(如hgetall等)。

如何解决主从数据不一致问题呢?

  1. 可以换更好的硬件配置,保证网络畅通。
  2. 监控主从库间的复制进度

1.3.2 读取过期数据

Redis删除数据有这几种策略:

  • 惰性删除:只有当访问一个key时,才会判断该key是否已过期,过期则清除。
  • 定期删除:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。
  • 主动删除:当前已用内存超过最大限定时,触发主动清理策略。

如果使用Redis版本低于3.2,读从库时,并不会判断数据是否过期,而是会返回过期数据。而3.2 版本后,Redis做了改进,如果读到的数据已经过期了,从库不会删除,却会返回空值,避免了客户端读到过期数据

因此,在主从Redis模式下,尽量使用 Redis 3.2以上的版本。

1.3.3 一主多从,全量复制时主库压力问题

如果是一主多从模式,从库很多的时候,如果每个从库都要和主库进行全量复制的话,主库的压力是很大的。因为主库fork进程生成RDB,这个fork的过程是会阻塞主线程处理正常请求的。同时,传输大的RDB文件也会占用主库的网络宽带。

可以使用主-从-从模式解决。什么是主从从模式呢?其实就是部署主从集群时,选择硬件网络配置比较好的一个从库,让它跟部分从库再建立主从关系。如图:

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

1.3.4 主从网络断了怎么办呢?

主从库完成了全量复制后,它们之间会维护一个网络长连接,用于主库后续收到写命令传输到从库,它可以避免频繁建立连接的开销。但是,如果网络断开重连后,是否还需要进行一次全量复制呢?

如果是Redis 2.8之前,从库和主库重连后,确实会再进行一次全量复制,但是这样开销就很大。而Redis 2.8之后做了优化,重连后采用增量复制方式,即把主从库网络断连期间主库收到的写命令,同步给从库。

主从库重连后,就是利用repl_backlog_buffer实现增量复制。

当主从库断开连接后,主库会把断连期间收到的写操作命令,写入replication buffer,同时也会把这些操作命令写入repl_backlog_buffer这个缓冲区。repl_backlog_buffer是一个环形缓冲区,主库会记录自己写到的位置,从库则会记录自己已经读到的位置。

2. Redis哨兵

第一种主从同步/复制的模式,当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用,这时候就需要哨兵模式登场了。

哨兵模式是从Redis的2.6版本开始提供的,但是当时这个版本的模式是不稳定的,直到Redis的2.8版本以后,这个哨兵模式才稳定下来。Redis从2.8开始正式提供了Redis哨兵机制来解决这个问题。

主从模式中,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址。显然,多数业务场景都不能接受这种故障处理方式。

哨兵模式核心还是主从复制,只不过在相对于主从模式在主节点宕机导致不可写的情况下,多了一个竞选机制:从所有的从节点竞选出新的主节点。竞选机制的实现,是依赖于在系统中启动一个sentinel进程。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍哨兵模式

如上图,哨兵本身也有单点故障的问题,所以在一个一主多从的Redis系统中,可以使用多个哨兵进行监控,哨兵不仅会监控主数据库和从数据库,哨兵之间也会相互监控。每一个哨兵都是一个独立的进程,作为进程,它会独立运行。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍多哨兵模式

2.1 哨兵作用

哨兵其实是一个运行在特殊模式下的Redis进程。它有三个作用,分别是:监控、自动选主切换(简称选主)、通知

哨兵进程在运行期间,监视所有的Redis主节点和从节点。它通过周期性给主从库发送PING命令,检测主从库是否挂了。如果从库没有在规定时间内响应哨兵的PING命令,哨兵就会把它标记为下线状态;如果主库没有在规定时间内响应哨兵的PING命令,哨兵则会判定主库下线,然后开始切换到选主任务。

所谓选主,其实就是从多个从库中,按照一定规则,选出一个当做主库。至于通知呢,就是选出主库后,哨兵把新主库的连接信息发给其他从库,让它们和新主库建立主从关系。同时,哨兵也会把新主库的连接信息通知给客户端,让它们把请求操作发到新主库上。

哨兵监控所有服务器是否正常运行:通过发送命令返回监控服务器的运行状态,处理监控主服务器、从服务器外,哨兵之间也相互监控。

故障切换:当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换master。同时那台有问题的旧主也会变为新主的从,也就是说当旧的主即使恢复时,并不会恢复原来的主身份,而是作为新主的一个从。

2.2 哨兵模式

因为Redis哨兵也是一个Redis进程,如果它自己挂了呢,那是不是就起不了监控的作用啦。我们一起来看下Redis哨兵模式

哨兵模式,就是由一个或多个哨兵实例组成的哨兵系统,它可以监视所有的Redis主节点和从节点,并在被监视的主节点进入下线状态时,自动将下线主服务器属下的某个从节点升级为新的主节点。,一个哨兵进程对Redis节点进行监控,就可能会出现问题(单点问题)。因此,一般使用多个哨兵来进行监控Redis节点,并且各个哨兵之间还会进行监控。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

其实哨兵之间是通过发布订阅机制组成集群的,同时,哨兵又通过INFO命令,获得了从库连接信息,也能和从库建立连接,从而进行监控。

2.3 哨兵如何判定主库下线

哨兵是如何判断主库是否下线的呢?我们先来了解两个基础概念哈:主观下线和客观下线

  • 哨兵进程向主库、从库发送PING命令,如果主库或者从库没有在规定的时间内响应PING命令,哨兵就把它标记为主观下线
  • 如果是主库被标记为主观下线,则正在监视这个主库的所有哨兵要以每秒一次的频率,以确认主库是否真的进入了主观下线。当有多数的哨兵(一般少数服从多数,由 Redis 管理员自行设定的一个值)在指定的时间范围内确认主库的确进入了主观下线状态,则主库会被标记为客观下线。这样做的目的就是避免对主库的误判,以减少没有必要的主从切换,减少不必要的开销。

假设我们有N个哨兵实例,如果有N/2+1个实例判断主库主观下线,此时就可以把节点标记为客观下线,就可以做主从切换了。

2.4 哨兵的工作模式

  1. 每个哨兵以每秒钟一次的频率向它所知的主库、从库以及其他哨兵实例发送一个PING命令。
  2. 如果一个实例节点距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值, 则这个实例会被哨兵标记为主观下线。
  3. 如果主库被标记为主观下线,则正在监视这个主库的所有哨兵要以每秒一次的频率确认主库的确进入了主观下线状态。
  4. 当有足够数量的哨兵(大于等于配置文件指定的值)在指定的时间范围内确认主库的确进入了主观下线状态, 则主库会被标记为客观下线
  5. 当主库被哨兵标记为客观下线时,就会进入选主模式
  6. 若没有足够数量的哨兵同意主库已经进入主观下线, 主库的主观下线状态就会被移除;若主库重新向哨兵的PING命令返回有效回复,主库的主观下线状态就会被移除。

2.5 哨兵是如何选主的?

如果明确主库已经客观下线了,哨兵就开始了选主模式。

哨兵选主包括两大过程,分别是:过滤和打分。其实就是在多个从库中,先按照一定的筛选条件,把不符合条件的从库过滤掉。然后再按照一定的规则,给剩下的从库逐个打分,将得分最高的从库选为新主库

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

  • 选主时,会判断从库的状态,如果已经下线,就直接过滤
  • 如果从库网络不好,老是超时,也会被过滤掉。看这个参数down-after-milliseconds,它表示我们认定主从库断连的最大连接超时时间。
  • 过滤掉了不适合做主库的从库后,就可以给剩下的从库打分,按这三个规则打分:从库优先级、从库复制进度以及从库ID号
  • 从库优先级最高的话,打分就越高,优先级可以通过slave-priority配置。如果优先级一样,就选与旧的主库复制进度最快的从库。如果优先级和从库进度都一样,从库ID 号小的打分高。

2.6 由哪个哨兵执行主从切换呢?

一个哨兵标记主库为主观下线后,它会征求其他哨兵的意见,确认主库是否的确进入了主观下线状态。它向其他实例哨兵发送is-master-down-by-addr命令。其他哨兵会根据自己和主库的连接情况,回应YN(Y 表示赞成,N表示反对票)。如果这个哨兵获取得足够多的赞成票数(quorum配置),主库会被标记为客观下线

标记主库客观下线的这个哨兵,紧接着向其他哨兵发送命令,再发起投票,希望它可以来执行主从切换。这个投票过程称为Leader 选举。因为最终执行主从切换的哨兵称为Leader,投票过程就是确定Leader。一个哨兵想成为Leader需要满足两个条件:

  • 需要拿到num(sentinels)/2+1的赞成票。
  • 并且拿到的票数需要大于等于哨兵配置文件中的quorum值。

举个例子,假设有3个哨兵。配置的quorum值为2。即一个一个哨兵想成为Leader至少需要拿到2张票。为了更好理解,大家可以看下

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

  • 在t1时刻,哨兵A1判断主库为客观下线,它想成为主从切换的Leader,于是先给自己投一张赞成票,然后分别向哨兵A2 和A3发起投票命令,表示想成为 Leader。
  • 在 t2 时刻,A3 判断主库为客观下线,它也想成为 Leader,所以也先给自己投一张赞成票,再分别向 A1 和 A2 发起投票命令,表示也要成为 Leader。
  • 在 t3 时刻,哨兵A1 收到了A3 的Leader投票请求。因为A1已经把票Y投给自己了,所以它不能再给其他哨兵投赞成票了,所以A1投票N给A3。
  • 在 t4时刻,哨兵A2收到A3 的Leader投票请求,因为哨兵A2之前没有投过票,它会给第一个向它发送投票请求的哨兵回复赞成票Y
  • 在 t5时刻,哨兵A2收到A1 的Leader投票请求,因为哨兵A2之前已经投过赞成票给A3了,所以它只能给A1投反对票N
  • 最后t6时刻,哨兵A1只收到自己的一票Y赞成票,而哨兵A3得到两张赞成票(A2和A3投的),因此哨兵A3成为了Leader

假设网络故障等原因,哨兵A3也没有收到两张票,那么这轮投票就不会产生Leader。哨兵集群会等待一段时间(一般是哨兵故障转移超时时间的2倍),再进行重新选举。

2.7 故障转移

假设哨兵模式架构如下,有三个哨兵,一个主库M,两个从库S1和S2。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

当哨兵检测到Redis主库M1出现故障,那么哨兵需要对集群进行故障转移。假设选出了哨兵3作为Leader。故障转移流程如下:

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

  1. 从库S1解除从节点身份,升级为新主库
  2. 从库S2成为新主库的从库
  3. 原主节点恢复也变成新主库的从节点
  4. 通知客户端应用程序新主节点的地址。

故障转移后:

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

哨兵实现原理

哨兵在启动进程时,会读取配置文件的内容,通过如下的配置找出需要监控的主数据库:

这里之所以只需要连接主节点,是因为通过主节点的info命令,获取从节点信息,从而和从节点也建立连接,同时也能通过主节点的info信息知道新增从节点的信息。

一个哨兵节点可以监控多个主节点,但是并不提倡这么做,因为当哨兵节点崩溃时,同时有多个集群切换会发生故障。哨兵启动后,会与主数据库建立两条连接。

  • 订阅主数据库sentinel:hello频道以获取同样监控该数据库的哨兵节点信息
  • 定期向主数据库发送info命令,获取主数据库本身的信息。
跟主数据库建立连接后会定时执行以下三个操作:
  • (1)每隔10s向master和 slave发送info命令。作用是获取当前数据库信息,比如发现新增从节点时,会建立连接,并加入到监控列表中,当主从数据库的角色发生变化进行信息更新。
  • (2)每隔2s向主数据里和从数据库的sentinel:hello频道发送自己的信息。作用是将自己的监控数据和哨兵分享。每个哨兵会订阅数据库的_sentinel:hello频道,当其他哨兵收到消息后,会判断该哨兵是不是新的哨兵,如果是则将其加入哨兵列表,并建立连接。
  • (3)每隔1s向所有主从节点和所有哨兵节点发送ping命令,作用是监控节点是否存活。

(3)主观下线和客观下线

哨兵节点发送ping命令时,当超过一定时间(down-after-millisecond)后,如果节点未回复,则哨兵认为主观下线。主观下线表示当前哨兵认为该节点已经下线,如果该节点为主数据库,哨兵会进一步判断是够需要对其进行故障切换,这时候就要发送命令(SENTINEL is-master-down-by-addr)询问其他哨兵节点是否认为该主节点是主观下线,当达到指定数量(quorum)时,哨兵就会认为是客观下线。

当主节点客观下线时就需要进行主从切换,主从切换的步骤为:

  • 选出领头哨兵。
  • 领头哨兵所有的slave选出优先级最高的从数据库。优先级可以通过slave-priority选项设置。
  • 如果优先级相同,则从数据库复制的命令偏移量越大(即复制同步数据越多,数据越新),越优先。
  • 如果以上条件都一样,则选择run ID较小的从数据库。

选出一个从数据库后,哨兵发送slave no one命令升级为主数据库,并发送slaveof命令将其他从节点的主数据库设置为新的主数据库。

(4)哨兵模式优缺点

1.优点

  • 哨兵模式是基于主从模式的,解决可主从模式中master故障不可以自动切换故障的问题。

2.不足-问题

  • 是一种中心化的集群实现方案:始终只有一个Redis主机来接收和处理写请求,写操作受单机瓶颈影响。
  • 集群里所有节点保存的都是全量数据,浪费内存空间,没有真正实现分布式存储。数据量过大时,主从同步严重影响master的性能。
  • Redis主机宕机后,哨兵模式正在投票选举的情况之外,因为投票选举结束之前,谁也不知道主机和从机是谁,此时Redis也会开启保护机制,禁止写操作,直到选举出了新的Redis主机。

主从模式或哨兵模式每个节点存储的数据都是全量的数据,数据量过大时,就需要对存储的数据进行分片后存储到多个redis实例上。此时就要用到Redis Sharding技术。

3.Redis Cluster集群

哨兵模式基于主从模式,实现读写分离,它还可以自动切换,系统可用性更高。但是它每个节点存储的数据是一样的,浪费内存,并且不好在线扩容。因此,Reids Cluster集群(切片集群的实现方案)应运而生,它在Redis3.0加入的,实现了Redis的分布式存储。对数据进行分片,也就是说每台Redis节点上存储不同的内容,来解决在线扩容的问题。并且,它可以保存大量数据,即分散数据到各个Redis实例,还提供复制和故障转移的功能。

比如你一个Redis实例保存15G甚至更大的数据,响应就会很慢,这是因为Redis RDB 持久化机制导致的,Redis会fork子进程完成 RDB 持久化操作,fork执行的耗时与 Redis 数据量成正相关。

这时候你很容易想到,把15G数据分散来存储就好了嘛。这就是Redis切片集群的初衷。切片集群是啥呢?来看个例子,如果你要用Redis保存15G的数据,可以用单实例Redis,或者3台Redis实例组成切片集群,对比如下:

切片集群和Redis Cluster 的区别:Redis Cluster是从Redis3.0版本开始,官方提供的一种实现切片集群的方案。

既然数据是分片分布到不同Redis实例的,那客户端到底是怎么确定想要访问的数据在哪个实例上呢?我们一起来看下Reids Cluster是怎么做的哈。

3.1 哈希槽(Hash Slot)

Redis Cluster方案采用哈希槽(Hash Slot),来处理数据和实例之间的映射关系。

一个切片集群被分为16384个slot(槽),每个进入Redis的键值对,根据key进行散列,分配到这16384插槽中的一个。使用的哈希映射也比较简单,用CRC16算法计算出一个16bit的值,再对16384取模。数据库中的每个键都属于这16384个槽的其中一个,集群中的每个节点都可以处理这16384个槽。

集群中的每个节点负责一部分的哈希槽,假设当前集群有A、B、C3个节点,每个节点上负责的哈希槽数 =16384/3,那么可能存在的一种分配:

  • 节点A负责0~5460号哈希槽
  • 节点B负责5461~10922号哈希槽
  • 节点C负责10923~16383号哈希槽

客户端给一个Redis实例发送数据读写操作时,如果这个实例上并没有相应的数据,会怎么样呢?MOVED重定向和ASK重定向了解一下哈

3.2 MOVED重定向和ASK重定向

在Redis cluster模式下,节点对请求的处理过程如下:

  1. 通过哈希槽映射,检查当前Redis key是否存在当前节点
  2. 若哈希槽不是由自身节点负责,就返回MOVED重定向
  3. 若哈希槽确实由自身负责,且key在slot中,则返回该key对应结果
  4. 若Redis key不存在此哈希槽中,检查该哈希槽是否正在迁出(MIGRATING)?
  5. 若Redis key正在迁出,返回ASK错误重定向客户端到迁移的目的服务器上
  6. 若哈希槽未迁出,检查哈希槽是否导入中?
  7. 若哈希槽导入中且有ASKING标记,则直接操作,否则返回MOVED重定向

3.2.1 Moved 重定向

客户端给一个Redis实例发送数据读写操作时,如果计算出来的槽不是在该节点上,这时候它会返回MOVED重定向错误,MOVED重定向错误中,会将哈希槽所在的新实例的IP和port端口带回去。这就是Redis Cluster的MOVED重定向机制。流程图如下:

3.2.2 ASK 重定向

Ask重定向一般发生于集群伸缩的时候。集群伸缩会导致槽迁移,当我们去源节点访问时,此时数据已经可能已经迁移到了目标节点,使用Ask重定向可以解决此种情况。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

3.3 Cluster集群节点的通讯协议:Gossip

一个Redis集群由多个节点组成,各个节点之间是怎么通信的呢?通过Gossip协议!Gossip是一种谣言传播协议,每个节点周期性地从节点列表中选择 k 个节点,将本节点存储的信息传播出去,直到所有节点信息一致,即算法收敛了。

Gossip协议基本思想:一个节点想要分享一些信息给网络中的其他的一些节点。于是,它周期性的随机选择一些节点,并把信息传递给这些节点。这些收到信息的节点接下来会做同样的事情,即把这些信息传递给其他一些随机选择的节点。一般而言,信息会周期性的传递给N个目标节点,而不只是一个。这个N被称为fanout

Redis Cluster集群通过Gossip协议进行通信,节点之前不断交换信息,交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。gossip协议包含多种消息类型,包括ping,pong,meet,fail,等等

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

  • meet消息:通知新节点加入。消息发送者通知接收者加入到当前集群,meet消息通信正常完成后,接收节点会加入到集群中并进行周期性的ping、pong消息交换。
  • ping消息:节点每秒会向集群中其他节点发送 ping 消息,消息中带有自己已知的两个节点的地址、槽、状态信息、最后一次通信时间等
  • pong消息:当接收到ping、meet消息时,作为响应消息回复给发送方确认消息正常通信。消息中同样带有自己已知的两个节点信息。
  • fail消息:当节点判定集群内另一个节点下线时,会向集群内广播一个fail消息,其他节点接收到fail消息之后把对应节点更新为下线状态。

特别的,每个节点是通过集群总线(cluster bus) 与其他的节点进行通信的。通讯时,使用特殊的端口号,即对外服务端口号加10000。例如如果某个node的端口号是6379,那么它与其它nodes通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。

3.4 故障转移

Redis集群实现了高可用,当集群内节点出现故障时,通过故障转移,以保证集群正常对外提供服务。

redis集群通过ping/pong消息,实现故障发现。这个环境包括主观下线和客观下线

主观下线: 某个节点认为另一个节点不可用,即下线状态,这个状态并不是最终的故障判定,只能代表一个节点的意见,可能存在误判情况。

主观下线

客观下线: 指标记一个节点真正的下线,集群内多个节点都认为该节点不可用,从而达成共识的结果。如果是持有槽的主节点故障,需要为该节点进行故障转移。

  • 假如节点A标记节点B为主观下线,一段时间后,节点A通过消息把节点B的状态发到其它节点,当节点C接受到消息并解析出消息体时,如果发现节点B的pfail状态时,会触发客观下线流程;
  • 当下线为主节点时,此时Redis Cluster集群为统计持有槽的主节点投票,看投票数是否达到一半,当下线报告统计数大于一半时,被标记为客观下线状态。

流程如下:

Redis主从、哨兵、 Cluster集群、分片等高可用介绍客观下线

故障恢复:故障发现后,如果下线节点的是主节点,则需要在它的从节点中选一个替换它,以保证集群的高可用。流程如下:

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

  • 资格检查:检查从节点是否具备替换故障主节点的条件。
  • 准备选举时间:资格检查通过后,更新触发故障选举时间。
  • 发起选举:到了故障选举时间,进行选举。
  • 选举投票:只有持有槽的主节点才有票,从节点收集到足够的选票(大于一半),触发替换主节点操作

3.5 加餐:为什么Redis Cluster的Hash Slot 是16384?

对于客户端请求过来的键值key,哈希槽=CRC16(key) % 16384,CRC16算法产生的哈希值是16bit的,按道理该算法是可以产生2^16=65536个值,为什么不用65536,用的是16384(2^14)呢?

大家可以看下作者的原始回答:

Redis主从、哨兵、 Cluster集群、分片等高可用介绍

Redis 每个实例节点上都保存对应有哪些slots,它是一个 unsigned char slots[REDIS_CLUSTER_SLOTS/8] 类型Redis主从、哨兵、 Cluster集群、分片等高可用介绍

  • 在redis节点发送心跳包时需要把所有的槽放到这个心跳包里,如果slots数量是 65536 ,占空间= 65536 / 8(一个字节8bit) / 1024(1024个字节1kB) =8kB ,如果使用slots数量是 16384 ,所占空间 = 16384 / 8(每个字节8bit) / 1024(1024个字节1kB) = 2kB ,可见16384个slots比 65536省 6kB内存左右,假如一个集群有100个节点,那每个实例里就省了600kB啦
  • 一般情况下Redis cluster集群主节点数量基本不可能超过1000个,超过1000会导致网络拥堵。对于节点数在1000以内的Redis cluster集群,16384个槽位其实够用了。

既然为了节省内存网络开销,为什么 slots不选择用8192(即16384/2) 呢?

8192 / 8(每个字节8bit) / 1024(1024个字节1kB) = 1kB ,只需要1KB!可以先看下Redis 把 Key 换算成所属 slots 的方法

Redis 将key换算成slots 的方法:其实就是是将crc16(key) 之后再和slots的数量进行与计算

这里为什么用0x3FFF(16383) 来计算,而不是16384呢?因为在不产生溢出的情况下 x % (2^n)等价于x & (2^n - 1)x % 16384 == x & 16383

那到底为什么不用8192呢?

crc16 出来结果,理论上出现重复的概率为 1⁄65536,但实际结果重复概率可能比这个大不少,就像crc32 结果 理论上 1/40亿 分之一,但实际有人测下来10万碰撞的概率就比较大了。假如 slots 设置成 8192, 200个实例的节点情况下,理论值是 每40个不同key请求,命中就会失效一次,假如节点数增加到400,那就是20个请求。并且1kb 并不会比 2k 省太多,性价比不是特别高,所以可能 选16384会更为通用一点

集群方案

Redis 的哨兵模式虽然已经可以实现高可用,读写分离 ,但是存在几个方面的不足:

  • 哨兵模式下每台 Redis 服务器都存储相同的数据,很浪费内存空间;数据量太大,主从同步时严重影响了master性能。
  • 哨兵模式是中心化的集群实现方案,每个从机和主机的耦合度很高,master宕机到salve选举master恢复期间服务不可用。
  • 哨兵模式始终只有一个Redis主机来接收和处理写请求,写操作还是受单机瓶颈影响,没有实现真正的分布式架构。

redis在3.0上加入了 Cluster 集群模式,实现了 Redis 的分布式存储,也就是说每台 Redis 节点上存储不同的数据。cluster模式为了解决单机Redis容量有限的问题,将数据按一定的规则分配到多台机器,内存/QPS不受限于单机,可受益于分布式集群高扩展性。

Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现),采用多主多从,每一个分区都是由一个Redis主机和多个从机组成,片区和片区之间是相互平行的。Redis Cluster集群采用了P2P的模式,完全去中心化。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍Redis Cluster

如上图,官方推荐,集群部署至少要 3 台以上的master节点,最好使用 3 主 3 从六个节点的模式。Redis Cluster集群具有如下几个特点:

  • 集群完全去中心化,采用多主多从;所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
  • 客户端与 Redis 节点直连,不需要中间代理层。客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
  • 每一个分区都是由一个Redis主机和多个从机组成,分片和分片之间是相互平行的。
  • 每一个master节点负责维护一部分槽,以及槽所映射的键值数据;集群中每个节点都有全量的槽信息,通过槽每个node都知道具体数据存储到哪个node上。

redis cluster主要是针对海量数据+高并发+高可用的场景,海量数据,如果你的数据量很大,那么建议就用redis cluster,数据量不是很大时,使用sentinel就够了。redis cluster的性能和高可用性均优于哨兵模式。

Redis Cluster采用虚拟哈希槽分区而非一致性hash算法,预先分配一些卡槽,所有的键根据哈希函数映射到这些槽内,每一个分区内的master节点负责维护一部分槽以及槽所映射的键值数据。

各大厂的Redis集群方案

Redis在3.0版本前只支持单实例模式,虽然Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能,但3.0版本等到2015年才发布正式版。各大企业等不及了,在3.0版本还没发布前为了解决Redis的存储瓶颈,纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片(sharding)存储在多个Redis实例中,每一片就是一个Redis实例。

(1)客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现,(比如:jedis已支持Redis Sharding功能,即ShardedJedis),通过Redis客户端预先定义好的路由规则(使用一致性哈希),把对Key的访问转发到不同的Redis实例中,查询数据时把返回结果汇集。这种方案的模式如图所示。

Redis主从、哨兵、 Cluster集群、分片等高可用介绍客户端分片

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!
Redis主从、哨兵、 Cluster集群、分片等高可用介绍后续精彩内容已被小麦苗无情隐藏,请输入验证码解锁本站所有文章
验证码:
请关注本站微信公众号,回复“小麦苗博客”,获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部