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

前言 
大家好，我是捡田螺的小男孩。今天跟小伙伴们一起学习Redis的主从、哨兵、Redis Cluster集群。

• Redis主从
• Redis哨兵
• 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 文件后，会先清空当前数据库，然后加载 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文件也会占用主库的网络宽带。

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

 
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 哨兵的工作模式

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

文章转自公众号：小白debug