Redis主从、哨兵、 Cluster集群一锅端

1. Redis 主从

面试官经常会问到Redis的高可用。Redis高可用回答包括两个层面，一个就是 数据不能丢失，或者说尽量减少丢失 ;另外一个就是保证 Redis服务不中断 。

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

1.1 Redsi主从概念

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

1.2 Redis 主从同步过程

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

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

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

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

```
bgsave
RDB
RDB
```
主库把数据同步到从库的过程中，新来的写操作，会记录到 replication buffer 。

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

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

1.3 Redis主从的一些注意点

1.3.1 主从数据不一致

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

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

主从库网路延迟。
从库收到了主从命令，但是它正在执行阻塞性的命令（如 hgetall 等）。

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

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

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文件也会占用主库的网络宽带。

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

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

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

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

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

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

2. Redis哨兵

主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址。显然，多数业务场景都不能接受这种故障处理方式。Redis从2.8开始正式提供了 Redis哨兵机制 来解决这个问题。

哨兵作用
哨兵模式简介
哨兵如何判定主库下线
哨兵模式如何工作
哨兵是如何选主的
由哪个哨兵执行主从切换呢？
哨兵下的故障转移

2.1 哨兵作用

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

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

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

2.2 哨兵模式

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

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

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

2.3 哨兵如何判定主库下线

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

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

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

2.4 哨兵的工作模式

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

2.5 哨兵是如何选主的？

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

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

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

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

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

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

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

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

在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主库M1出现故障，那么哨兵需要对集群进行故障转移。假设选出了 哨兵3 作为Leader。故障转移流程如下：

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

故障转移后：

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模式下，节点对请求的处理过程如下：

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

3.2.1 Moved 重定向

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

3.2.2 ASK 重定向

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

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

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

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

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

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集群为统计持有槽的主节点投票，看投票数是否达到一半，当下线报告统计数大于一半时，被标记为 客观下线 状态。

流程如下：

客观下线

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

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

3.5 加餐：为什么Redis Cluster的Hash Slot 是16384？

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

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

Redis 每个实例节点上都保存对应有哪些slots，它是一个 unsigned char slots[REDIS_CLUSTER_SLOTS/8] 类型

65536
65536 / 8(一个字节8bit) / 1024(1024个字节1kB) =8kB
16384
16384 / 8(每个字节8bit) / 1024(1024个字节1kB) = 2kB

一般情况下Redis cluster集群主节点数量基本不可能超过1000个，超过1000会导致网络拥堵。对于节点数在1000以内的Redis cluster集群，16384个槽位其实够用了。

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

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

unsigned int keyHashSlot(char *key, int keylen) {int s, e; /* start-end indexes of { and } */for (s = 0; s < keylen; s++)if (key[s] == '{') break;/* No '{' ? Hash the whole key. This is the base case. */if (s == keylen) return crc16(key,keylen) & 0x3FFF;/* '{' found? Check if we have the corresponding '}'. */for (e = s+1; e < keylen; e++)if (key[e] == '}') break;/* No '}' or nothing betweeen {} ? Hash the whole key. */if (e == keylen || e == s+1) return crc16(key,keylen) & 0x3FFF;/* If we are here there is both a { and a } on its right. Hash* what is in the middle between { and }. */return crc16(key+s+1,e-s-1) & 0x3FFF;
}

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会更为通用一点