什么是 Cluster 集群
Redis 集群是一种分布式数据库方案，集群通过分片(sharding)来进行数据管理(「分治思想」的一种实践)，并提供复制和故障转移功能。
将数据划分为 16384 的 slots，每个节点负责一部分槽位。槽位的信息存储于每个节点中。
它是去中心化的，如图所示，该集群有三个 Redis 节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。
三个节点相互连接组成一个对等的集群，它们之间通过 Gossip协议相互交互集群信息，最后每个节点都保存着其他节点的 slots 分配情况。
集群安装
一个 Redis 集群通常由多个节点(node)组成，在刚开始的时候，每个节点都是相互独立的，它们都处于一个只包含自己的集群当中，要组建一个真正可工作的集群，我们必须将各个独立的节点连接起来，构成一个包含多个节点的集群。
连接各个节点的工作可以通过 CLUSTER MEET 命令完成：CLUSTER MEET
向一个节点 node 发送 CLUSTER MEET 命令，可以让 node 节点与 ip 和 port 所指定的节点进行握手(handshake)，当握手成功时，node 节点就会将 ip 和 port 所指定的节点添加到 node 节点当前所在的集群中。
Cluster 实现原理
Redis 3.0 开始，官方提供了 Redis Cluster 方案实现了切片集群，该方案就实现了数据和实例的规则。Redis Cluster 方案采用哈希槽(Hash Slot，接下来我会直接称之为 Slot)，来处理数据和实例之间的映射关系。
将数据分成多份存在不同实例上
集群的整个数据库被分为 16384 个槽(slot)，数据库中的每个键都属于这 16384 个槽的其中一个，集群中的每个节点可以处理 0 个或最多 16384 个槽。
Key 与哈希槽映射过程可以分为两大步骤：
1、根据键值对的 key，使用 CRC16 算法，计算出一个 16 bit 的值；
2、将 16 bit 的值对 16384 执行取模，得到 0 ～ 16383 的数表示 key 对应的哈希槽。
哈希槽与 Redis 实例映射
通过 cluster create 创建，Redis 会自动将 16384 个 哈希槽平均分布在集群实例上，比如 N 个节点，每个节点上的哈希槽数 = 16384 / N 个。
可以使用 cluster addslots 命令，手动指定每个实例上的哈希槽个数。
Redis 集群节点采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变。比如一个节点发现某个节点失联了 (PFail)，它会将这条信息向整个集群广播，其它节点也就可以收到这点失联信息。
如果一个节点收到了某个节点失联的数量 (PFail Count) 已经达到了集群的大多数，就可以标记该节点为确定下线状态 (Fail)，然后向整个集群广播，强迫其它节点也接收该节点已经下线的事实，并立即对该失联节点进行主从切换。
故障转移
当一个 Slave 发现自己的主节点进入已下线状态后，从节点将开始对下线的主节点进行故障转移。
1、从下线的 Master 及节点的 Slave 节点列表选择一个节点成为新主节点。
2、新主节点会撤销所有对已下线主节点的 slot 指派，并将这些 slots 指派给自己。
3、新的主节点向集群广播一条 PONG 消息，这条 PONG 消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽。
4、新的主节点开始接收处理槽有关的命令请求，故障转移完成。
跟哨兵类似，两者都是基于 Raft 算法来实现的，流程如图所示：
客户端如何定位数据所在实例
Redis 实例会将自己的哈希槽信息通过 Gossip 协议发送给集群中其他的实例，实现了哈希槽分配信息的扩散。
这样，集群中的每个实例都有所有哈希槽与实例之间的映射关系信息。
在切片数据的时候是将 key 通过 CRC16 计算出一个值再对 16384 取模得到对应的 Slot，这个计算任务可以在客户端上执行发送请求的时候执行。
但是，定位到槽以后还需要进一步定位到该 Slot 所在 Redis 实例。
当客户端连接任何一个实例，实例就将哈希槽与实例的映射关系响应给客户端，客户端就会将哈希槽与实例映射信息缓存在本地。
当客户端请求时，会计算出键所对应的哈希槽，在通过本地缓存的哈希槽实例映射信息定位到数据所在实例上，再将请求发送给对应的实例。
重新分配哈希槽
哈希槽与实例之间的映射关系由于新增实例或者负载均衡重新分配导致改变了,集群中的实例通过 Gossip 协议互相传递消息获取最新的哈希槽分配信息，但是，客户端无法感知。
Redis Cluster 提供了重定向机制：客户端将请求发送到实例上，这个实例没有相应的数据，该 Redis 实例会告诉客户端将请求发送到其他的实例上。
Redis 如何告知客户端重定向访问新实例呢？
分为两种情况：MOVED 错误、ASK 错误。
MOVED 错误
MOVED 错误(负载均衡，数据已经迁移到其他实例上)：当客户端将一个键值对操作请求发送给某个实例，而这个键所在的槽并非由自己负责的时候，该实例会返回一个 MOVED 错误指引转向正在负责该槽的节点。
同时，客户端还会更新本地缓存，将该 slot 与 Redis 实例对应关系更新正确。
ASK 错误
如果某个 slot 的数据比较多，部分迁移到新实例，还有一部分没有迁移咋办？
如果请求的 key 在当前节点找到就直接执行命令，否则时候就需要 ASK 错误响应了，槽部分迁移未完成的情况下，如果需要访问的 key 所在 Slot 正在从从 实例 1 迁移到 实例 2，实例 1 会返回客户端一条 ASK 报错信息：客户端请求的 key 所在的哈希槽正在迁移到实例 2 上，你先给实例 2 发送一个 ASKING 命令，接着发发送操作命令。
集群可以设置多大？
Redis 官方给的 Redis Cluster 的规模上线是 1000 个实例。
到底是什么限制了集群规模呢？关键在于实例间的通信开销，Cluster 集群中的每个实例都保存所有哈希槽与实例对应关系信息(Slot 映射到节点的表)，以及自身的状态信息。
在集群之间每个实例通过 Gossip协议传播节点的数据，Gossip 协议工作原理大概如下：
1、从集群中随机选择一些实例按照一定的频率发送 PING 消息发送给挑选出来的实例，用于检测实例状态以及交换彼此的信息。PING 消息中封装了发送者自身的状态信息、部分其他实例的状态信息、Slot 与实例映射表信息。
2、实例接收到 PING 消息后，响应 PONG 消息，消息包含的信息跟 PING 消息一样。
集群之间通过 Gossip协议可以在一段时间之后每个实例都能获取其他所有实例的状态信息。
所以在有新节点加入，节点故障，Slot 映射变更都可以通过 PING，PONG 的消息传播完成集群状态在每个实例的传播同步。