redis集群选举源码分析（redis集群master选举）

本文目录一览：

• 1、Redis 哨兵模式核心原理
• 2、Redis哨兵机制原理浅析
• 3、【Redis】Redis Cluster-集群故障转移
• 4、Redis Cluster
• 5、使用 redis-cli 搭建 Redis 集群
• 6、Redis集群方案应该怎么做

Redis 哨兵模式核心原理

sentinal，中文名是哨兵

哨兵是redis集群架构中非常重要的一个组件，主要功能如下：

（1）集群监控，负责监控redis master和slave进程是否正常工作

（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员

（3）故障转移，如果master node挂掉了，会自动转移到slave node上

（4）配置中心，如果故障转移发生了，通知client客户端新的master地址

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题

（2）即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，这样就无法做到高可用了。

（1）哨兵至少需要3个实例，来保证自己的健壮性

（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性

（3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

1 哨兵集群必须部署2个以上节点

如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1

Configuration: quorum = 1

master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移。

同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移。

但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行。

2 经典的哨兵集群

Configuration: quorum = 2，majority

如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移。

同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移。

sdown和odown两种失败状态

sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机。

odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机。

sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机。

sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机。

哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往 sentinel :hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在

每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的 sentinel :hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置。

每个哨兵也会去监听自己监控的每个master+slaves对应的 sentinel :hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在。

每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步。

哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上

如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来

会考虑slave的一些信息

（1）跟master断开连接的时长

（2）slave优先级

（3）复制offset

（4）run id

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master。

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序

（1）按照slave优先级进行排序，slave priority越低，优先级就越高

（2）如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高

（3）如果上面两个条件都相同，那么选择一个run id比较小的那个slave

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换

如果quorum majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换

但是如果quorum = majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换

哨兵会对一套redis master+slave进行监控，有相应的监控的配置

执行切换的那个哨兵，会从要切换到的新master（salve-master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的

如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制

这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的

其他的哨兵都是根据版本号的大小来更新自己的master配置的

Redis哨兵机制原理浅析

上一篇文章Redis主从复制原理中简要地说明了主从复制的一个基本原理，包含全量复制、复制积压缓冲区与增量复制等内容，有兴趣的同学可以先看下。

利用主从复制，可以实现读写分离、数据备份等功能。但如果主库宕机后，需要运维人员手动地将一个从库提升为新主库，并将其他从库slaveof新主库，以此来实现故障恢复。

因此， 主从模式的一个缺点，就在于无法实现自动化地故障恢复 。Redis后来引入了哨兵机制，哨兵机制大大提升了系统的高可用性。

哨兵，就是站岗放哨的，时刻监控周围的一举一动，在第一时间发现敌情并发出及时的警报。

Redis中的哨兵（Sentinel）， 则是一个特殊的Redis实例 ，不过它并不存储数据。也就是说，哨兵在启动时，不会去加载RDB文件。

关于Redis的持久化，可以参考我的另外一篇文章 谈谈Redis的持久化——AOF日志与RDB快照

上图就是一个典型的哨兵架构，由数据节点与哨兵节点构成，通常会部署多个哨兵节点。

哨兵主要具有三个作用， 监控、选主与通知 。

监控：哨兵会利用心跳机制，周期性不断地检测主库与从库的存活性

选主：哨兵检测到主库宕机后，选择一个从库将之切换为新主库

通知：哨兵会将新主库的地址通知到所有从库，使得所有从库与旧主库slaveof新主库，也会将新主库的地址通知到客户端上

我会在下文详细讲一下监控与选主的过程

哨兵系统是通过3个定时任务，来完成对主库、从库与哨兵之间的探活。

首先我们会在配置文件中配置主库地址，这样哨兵在启动后，会以 每隔10秒 的频率向主库发送info命令，从而获得当前的主从拓扑关系，这样就拿到了所有从库的地址。

接着 每隔2秒 ，会使用pub/sub（发布订阅）机制，在主库上的 sentinel :hello的频道上发布消息，消息内容包括哨兵自己的ip、port、runid与主库的配置。

每个哨兵都会订阅该频道，在该频道上发布与消费消息，从而实现哨兵之间的互相感知。

利用启动配置与info命令可以获取到主从库地址，利用发布订阅可以感知到其余的哨兵节点。

在此基础上，哨兵会 每隔1秒 向主库、从库与其他哨兵节点发送PING命令，因此来进行互相探活。

当某个哨兵在 **down-after-milliseconds（默认是30秒） **配置的连续时间内，仍然没有收到主库的正确响应，则当前哨兵会认为主库 主观下线 ，并将其标记为sdown（subjective down）

为了避免当前哨兵对主库的误判，因此这个时候还需要参考其他哨兵的意见。

接着当前哨兵会向其他哨兵发送 sentinel is-master-down-by-addr 命令， 如果有半数以上（由quorum参数决定）的哨兵认为主库确实处于主观下线状态，则当前哨兵认为主库客观下线 ，标记为odown（objective down）

一旦某个主库被认定为客观下线时，这个时候需要进行哨兵选举，选举出一个领导者哨兵，来完成主从切换的过程。

哨兵A在向其他哨兵发送 sentinel is-master-down-by-addr 命令时，同时要求其他哨兵同意将其设置为Leader，也就是想获得其他哨兵的投票。

在每一轮选举中，每个哨兵仅有一票。投票遵循先来先到的原则，如果某个哨兵没有投给别人，就会投给哨兵A。

首先获得半数以上投票的哨兵，将被选举称为Leader。

这里的哨兵选举，采用的是Raft算法。这里不对Raft做详细的探讨，有兴趣的同学，可以参考我的另外一篇文章 22张图，带你入门分布式一致性算法Raft

该文章采用大量的图例，相信你可以从中学习到全新的知识，从而打开分布式一致性算法的大门，大伙们记得等我搞完Paxos与Zab。

过半投票机制也常用于很多算法中，例如RedLock，在半数以上的节点上加锁成功，才代表申请到了分布式锁，具体可参考这篇文章的最后 我用了上万字，走了一遍Redis实现分布式锁的坎坷之路，从单机到主从再到多实例，原来会发生这么多的问题

在Zookeeper选举中，同样也用到了过半投票机制，在这篇文章中 面试官：能给我画个Zookeeper选举的图吗？ 我从源码角度分析了Zookeeper选举的过程。

在选举到领导者哨兵后，将由该哨兵完成故障恢复工作。

故障恢复分为以下两步：

详细说一下第一步，挑选是有条件的。首先要过滤出不健康的节点，再按某种规则排序，最后取第一个从库，我们直接从源码入手：

因此，以下从库会被过滤出：

剩下的节点，就是健康的节点，此时再执行一次快速排序，排序的规则如下：

本文算是Redis哨兵的一个入门文章，主要讲了哨兵的作用，例如监控、选主和通知。

在Redis读写分离的情况下，使用哨兵可以很轻松地做到故障恢复，提升了整体的可用性。

但哨兵无法解决Redis单机写的瓶颈，这就需要引入集群模式，相应的文章也被列为明年的写作计划中。

/article

【Redis】Redis Cluster-集群故障转移

在集群定时任务 clusterCron 中，会遍历集群中的节点，对每个节点进行检查，判断节点是否下线。与节点下线相关的状态有两个，分别为 CLUSTER_NODE_PFAIL 和 CLUSTER_NODE_FAIL 。

CLUSTER_NODE_PFAIL ：当前节点认为某个节点下线时，会将节点状态改为 CLUSTER_NODE_PFAIL ，由于可能存在误判，所以需要根据集群中的其他节点共同决定是否真的将节点标记为下线状态， CLUSTER_NODE_PFAIL 可以理解为疑似下线，类似哨兵集群中的主观下线 。

CLUSTER_NODE_FAIL ：集群中有过半的节点标认为节点已下线，此时将节点置为 CLUSTER_NODE_FAIL 标记节点下线， CLUSTER_NODE_FAIL 表示节点真正处于下线状态，类似哨兵集群的客观下线 。

在集群定时任务遍历集群中的节点进行检查时，遍历到的每个节点记为 node ，当前节点记为 myself ，检查的内容主要有以下几个方面：

一、判断孤立主节点的个数

如果当前节点 myself 是从节点，正在遍历的节点 node 是主节点，并且 node 节点不处于下线状态，会判断孤立节点的个数，满足以下三个条件时，认定 node 是孤立节点，孤立节点个数增1：

二、检查连接

这一步主要检查和节点间的连接是否正常，有可能节点处于正常状态，但是连接有问题，此时需要释放连接，在下次执行定时任务时会进行重连，释放连接需要同时满足以下几个条件：

三、疑似下线判断

ping_delay 记录了当前时间距离向 node 节点发送PING消息的时间， data_delayd 记录了 node 节点向当前节点最近一次发送消息的时间，从ping_delay和data_delay中取较大的那个作为延迟时间。

如果延迟时间大于超时时间，判断 node 是否已经处于 CLUSTER_NODE_PFAIL 或者 CLUSTER_NODE_FAIL 状态，如果都不处于，将节点状态置为 CLUSTER_NODE_PFAIL ，认为节点疑似下线。

上述检查完成之后， 会判断当前节点是否是从节点，如果不处于 CLUSTER_MODULE_FLAG_NO_FAILOVER 状态，调用 clusterHandleSlaveFailover 处理故障转移，不过需要注意此时只是将节点置为疑似下线，并不满足故障转移条件，需要等待节点被置为FAIL下线状态之后，再次执行集群定时任务进入到 clusterHandleSlaveFailover 函数中才可以开始处理故障转移。

当前节点认为某个node下线时，会将node状态置为 CLUSTER_NODE_PFAIL 疑似下线状态，在定时向集群中的节点交换信息也就是发送PING消息时，消息体中记录了node的下线状态，其他节点在处理收到的PING消息时， 会将认为node节点下线的那个节点加入到node的下线链表fail_reports中，并调用 markNodeAsFailingIfNeeded 函数判断是否有必要将节点置为下线FAIL状态 ：

markNodeAsFailingIfNeeded

markNodeAsFailingIfNeeded用于判断是否有必要将某个节点标记为FAIL状态：

clusterHandleSlaveFailover

由上面的内容可知，节点客观下线时会被置为 CLUSTER_NODE_FAIL 状态，下次执行集群定时任务时，在故障转移处理函数 clusterHandleSlaveFailover 中，就可以根据状态来检查是否需要执行故障转移。

不过在看 clusterHandleSlaveFailover 函数之前，先看一下 clusterState 中和选举以及故障切换相关的变量定义：

clusterHandleSlaveFailover函数中的一些变量

data_age ： 记录从节点最近一次与主节点进行数据同步的时间 。如果与主节点处于连接状态，用当前时间减去最近一次与master节点交互的时间，否则使用当前时间减去与master主从复制中断的时间。

auth_age ： 当前时间减去发起选举的时间 ，也就是距离发起选举过去了多久，用于判断选举超时、是否重新发起选举使用。

needed_quorum ： quorum的数量，为集群中节点的数量的一半再加1 。

auth_timeout ： 等待投票超时时间。

auth_retry_time ： 等待重新发起选举进行投票的时间，也就是重试时间 。

一、故障转移条件检查

首先进行了一些条件检查，用于判断是否有必要执行故障转移，如果 处于以下几个条件之一，将会跳出函数，结束故障转移处理 ：

二、主从复制进度校验

cluster_slave_validity_factor 设置了故障切换最大主从复制延迟时间因子，如果不为0需要校验主从复制延迟时间是否符合要求。

如果主从复制延迟时间 data_age 大于 mater向从节点发送PING消息的周期 + 超时时间 * 故障切换主从复制延迟时间因子 并且不是手动执行故障切换，表示主从复制延迟过大，不能进行故障切换终止执行。

三、是否需要重新发起选举

如果距离上次发起选举的时间大于超时重试时间，表示可以重新发起投票。

四、延迟发起选举

五、发起投票

如果满足执行故障的条件，接下来需从节点想集群中的其他节点广播消息，发起投票，不过只有主节点才有投票权。 failover_auth_sent 为0表示还未发起投票，此时开始发起投票：

六、执行故障切换

当某个节点获取到了集群中大多数节点的投票，即可进行故障切换，这里先不关注，在后面的章节会讲。

clusterGetSlaveRank用于计算当前节点的等级，遍历所属主节点的所有从节点，根据主从复制进度 repl_offset 计算， repl_offset 值越大表示复制主节点的数据越多，所以等级越高，对应的 rank 值就越低。

从节点在发起选举使用了 rank 的值作为延迟时间，值越低延迟时间越小，意味着选举优先级也就越高。

当从节点认为主节点故障需要发起投票，重新选举主节点时，在集群中广播了 CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST 消息，对应的处理在 clusterProcessPacket 函数中，里面会调用 clusterSendFailoverAuthIfNeeded 函数进行投票：

clusterSendFailoverAuthIfNeeded

clusterSendFailoverAuthIfNeeded函数用于进行投票，处理逻辑如下：

以上条件校验通过， 表示当前节点可以投票给发送请求的节点，此时更新 lastVoteEpoch ，记录最近一次投票的纪元（轮次），更新投票时间 node-slaveof-voted_time ，然后向发起请求的节点回复 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 消息。

主节点对发起投票请求节点的回复消息 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 同样在消息处理函数 clusterProcessPacket 中，会对发送回复消息的节点进行验证：

同时满足以上三个条件时， 表示发送者对当前节点进行了投票，更新当前节点记录的收到投票的个数， failover_auth_count 加1，此时有可能获取了大多数节点的投票，先调用 clusterDoBeforeSleep 设置一个 CLUSTER_TODO_HANDLE_FAILOVER 标记，在周期执行的时间事件中会调用对状态进行判断决定是否执行故障转移。

从节点收到投票后，会添加 CLUSTER_TODO_HANDLE_FAILOVER 标记，接下来看下对 CLUSTER_TODO_HANDLE_FAILOVER 状态的处理。

在 beforeSleep 函数（server.c文件中），如果开启了集群，会调用 clusterBeforeSleep 函数，里面就包含了对 CLUSTER_TODO_HANDLE_FAILOVER 状态的处理：

beforeSleep 函数是在Redis事件循环 aeMain 方法中被调用的，详细内容可参考 事件驱动框架源码分析 文章。

clusterBeforeSleep

在clusterBeforeSleep函数中，如果节点带有 CLUSTER_TODO_HANDLE_FAILOVER 标记，会调用 clusterHandleSlaveFailover 函数进行处理：

clusterHandleSlaveFailover 函数在上面我们已经见到过，这次我们来关注集群的故障转移处理。

如果当前节点获取了大多数的投票，也就是 failover_auth_count （得到的投票数量）大于等于 needed_quorum ， needed_quorum 数量为集群中节点个数的一半+1，即可执行故障转移，接下来会调用 clusterFailoverReplaceYourMaster 函数完成故障转移。

clusterFailoverReplaceYourMaster

如果从节点收到了集群中过半的投票，就可以成为新的master节点，并接手下线的master节点的slot，具体的处理在clusterFailoverReplaceYourMaster函数中，主要处理逻辑如下：

总结

Redis Cluster

Redis Cluster 集群分区方案采用去中心化的方式，包括：sharding（分区）、replication（复制）、failover（故障转移）

Redis Cluster 由多个Redis节点组构成，是一个P2P（point to point）无中心节点的集群架构，依靠Gossip协议传播集群

Gossip协议是一个通信协议，一种传播消息的方式。

起源于：病毒传播

Gossip协议基本思想：

一个节点周期性(每秒)随机选择一些节点，并把信息传递给这些节点。

这些收到信息的节点接下来会做同样的事情，即把这些信息传递给其他一些随机选择的节点。

信息会周期性的传递给N个目标节点。这个N被称为 fanout （扇出）

gossip协议包含多种消息，包括meet、ping、pong、fail、publish等等

通过gossip协议，cluster可以提供集群间状态同步更新、选举自助failover等重要的集群功能。

redis-cluster把所有的物理节点映射到[0-16383]个 slot 上,基本上采用平均分配和连续分配的方式。

比如上图中有5个节点，这样在 Redis Cluster 创建时，slot槽可按下表分配

cluster 负责维护节点和slot槽的对应关系 value------slot--------节点

当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把

结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点

数量大致均等的将哈希槽映射到不同的节点。

比如：

set name zhangsan

hash("name")采用crc16算法，得到值：1324203551%16384=15903

根据上表15903在13088-16383之间，所以name被存储在Redis5节点。

slot槽必须在节点上连续分配，如果出现不连续的情况，则RedisCluster不能工作。

redis版本说明

redis.5.0.5

服务器说明

启动 7001、7002、7003、7011、7012、7013

配置启动脚本

三主三从

客户端连接集群

-c 以集群方式连接

扩容节点数据必须为空

启动 7004、7014

将 7004、7014 添加到集群

只能删除数据为空的节点

集群中的每个节点都会定期地（每秒）向集群中的其他节点发送PIN

如果在一定时间内(cluster-node-timeout)，发送ping的节点A没有收到某节点B的pong回应，则A将B

标识为pfail。

A在后续发送ping时，会带上B的pfail信息， 通知给其他节点。

如果B被标记为pfail的个数大于集群主节点个数的一半（N/2 + 1）时，B会被标记为fail，A向整个集群

广播，该节点已经下线

其他节点收到广播，标记B为fail。

采用 raft 协议

每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数

据越多）的从节点，选举时间越靠前，优先进行选举。

slave 通过向其他master发送FAILVOER_AUTH_REQUEST 消息发起竞选，

master 收到后回复FAILOVER_AUTH_ACK 消息告知是否同意。

slave 发送FAILOVER_AUTH_REQUEST 前会将currentEpoch 自增，并将最新的Epoch 带入到

FAILOVER_AUTH_REQUEST 消息中，如果自己未投过票，则回复同意，否则回复拒绝。

所有的 Master 开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 +

1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。

RedisCluster失效的判定 ：

1、集群中半数以上的主节点都宕机（无法投票）

2、宕机的主节点的从节点也宕机了（slot槽分配不连续）

当slave 收到过半的master 同意时，会成为新的master。此时会以最新的Epoch 通过PONG 消息广播

自己成为master，让Cluster 的其他节点尽快的更新拓扑结构(node.conf)。

自动切换

就是上面讲的从节点选举

手动切换

人工故障切换是预期的操作，而非发生了真正的故障，目的是以一种安全的方式(数据无丢失)将当前

master节点和其中一个slave节点(执行cluster-failover的节点)交换角色

1、向从节点发送cluster failover 命令（slaveof no one）

2、从节点告知其主节点要进行手动切换（CLUSTERMSG_TYPE_MFSTART）

3、主节点会阻塞所有客户端命令的执行（10s）

4、从节点从主节点的ping包中获得主节点的复制偏移量

5、从节点复制达到偏移量，发起选举、统计选票、赢得选举、升级为主节点并更新配置

6、切换完成后，原主节点向所有客户端发送moved指令重定向到新的主节点

以上是在主节点在线情况下。

如果主节点下线了，则采用cluster failover force或cluster failover takeover 进行强制切换。

我们知道在一主一从的情况下，如果主从同时挂了，那整个集群就挂了。

为了避免这种情况我们可以做一主多从，但这样成本就增加了。

Redis提供了一种方法叫副本漂移，这种方法既能提高集群的可靠性又不用增加太多的从机。

Master1宕机，则Slaver11提升为新的Master1

集群检测到新的Master1是单点的（无从机）

集群从拥有最多的从机的节点组（Master3）中，选择节点名称字母顺序最小的从机（Slaver31）漂移

到单点的主从节点组(Master1)。

具体流程如下（以上图为例）：

1、将Slaver31的从机记录从Master3中删除

2、将Slaver31的的主机改为Master1

3、在Master1中添加Slaver31为从节点

4、将Slaver31的复制源改为Master1

5、通过ping包将信息同步到集群的其他节点

使用 redis-cli 搭建 Redis 集群

参考： Redis 集群教程

redis.conf 文件中包含很多信息，如：端口号、持久化方式、持久化的文件等等。

使用写入了不同端口号的配置文件就可以启动多个 Redis 实例。

下面是一个最少选项的集群的配置文件:

文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为 nodes.conf 。节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时， 强烈建议使用六个节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。

首先， 让我们进入一个新目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目录中运行一个 Redis 实例： 命令如下:

在文件夹 7000 至 7005 中， 各创建一个 redis.conf 文件， 文件的内容可以使用上面的示例配置文件， 但记得将配置中的 port 和 cluster-conf-file 中的端口号数字 从 7000 改为与文件夹名字相同的号码。不同的集群节点要使用不同的 cluster-conf-file 。

配置文件的路径是可以自定义的。创建完毕后分别启动一个实例。

网上看到的教程，包括参考的官方文档里的文章，大多是使用以下方式创建集群。

这个命令在这里用于创建一个新的集群, 选项–replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

之后跟着的其他参数则是这个集群实例的地址列表，3 个 master 3 个 slave redis-trib 会打印出一份预想中的配置给你看，如果你觉得没问题的话，就可以输入 yes，redis-trib 就会将这份配置应用到集群当中，让各个节点开始互相通讯，最后可以得到如下信息：

这表示集群中的 16384 个槽都有至少一个主节点在处理，集群运作正常。

但是在 Redis 的 github 仓库 中看到，该文件已经不建议使用。

我在 手把手教你实现 Docker 部署 Redis 集群 的评论中看到， 现在 redis-cli --cluster 命令已经可以创建集群，分配槽，分配主从服务器了 ，于是使用以下命令了解到相关的命令。

可以看到，命令的组成形式和旧方式是一致的。

可以看到执行命令后，redis 客户端做了以下工作：

输入 yes 后，redis 客户端做了以下工作：

集群搭建完毕。

因为 Redis Cluster 默认要求所有的槽位被覆盖，可以通过修改 cluster-require-full-coverage yes 配置来改变该行为。

CLUSTERDOWN The cluster is down in redis 这里的回答中提到：我们可以使用 N 个Master 和 N+1 个 Slave，正常情况下多余的一个实例作为随机一个 Master 的 Slave，一旦有实例宕机，可以迅速顶替，以保证每个主节点总是有至少一个从节点保持数据同步。

ps：搜索命令行的输出时，才看到 深入理解Redis系列之集群环境搭建 这篇文章，有时候搜索的关键词不合适容易走弯路啊……

Redis集群方案应该怎么做

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？

首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。

其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。

方案

1.Redis官方集群方案 Redis Cluster

Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。

Redis

Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似前面讲的pre

sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简

单，就是CRC16后16384取模。

Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个

slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实

现中，还处于半自动状态，需要人工介入。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

为

了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失

效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis

Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

Redis

Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster

bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是

16379。nodes之间的通信采用特殊的二进制协议。

对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个

node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这

有点儿像浏览器页面的302 redirect跳转。

Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

2.Redis Sharding集群

Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。

多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。

Redis

Sharding可以说是Redis

Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定

的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。Sharding架构如图：

庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

Jedis的Redis Sharding实现具有如下特点：

采

用一致性哈希算法(consistent

hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类

似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

2.

为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟

化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点

时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。

3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。

Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。

当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。

作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。有没有其它手段改善这种情况？

Redis

作者给出了一个比较讨巧的办法--presharding，即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部

署多个，让他们都参与sharding，当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。数据同步后，修改

sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。

presharding

是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变，所以也

就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。

并不是只有增

删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到，为不影响Redis性能，尽量不开启

AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。

这样，我们的架构模式变

成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主

备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。则Sharding架构演变成：

Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。

高访问量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。通常情况下，应用访问Redis读操作量和写操作量差异很大，读常常是写的数倍，这时我们可以将读写分离，而且读提供更多的实例数。

可以利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Sentinel监控下，还可以保障节点故障的自动监测。

3.利用代理中间件实现大规模Redis集群

上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。

客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。其不足之处在于：

由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。

服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。

连接不能共享，当应用规模增大时，资源浪费制约优化。

服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。

不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。

能不能结合二者优势？即能使服务端各实例彼此独立，支持线性可伸缩，同时sharding又能集中处理，方便统一管理？本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。

twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。

参照Redis Sharding架构，增加代理中间件的Redis集群架构如下：

twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可避免单点压力或故障。

twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发，工程网址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis

twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。

由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。

当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，实测结果大约降低了20%左右。