Redis Cluster 提供了一种支持数据在多个 Redis 节点上自动进行分片的部署方式。 Redis Cluster 主要是为了实现以下这些目标（按在设计中的重要性排序）：
- 在多达 1000 个节点的时候仍能保持高性能及线性的可扩展性。没有代理，使用异步复制，并且不对值执行合并操作。
- 可接受的写入安全：与多数派节点相连的客户端所做的写入操作，系统尝试全部都保存下来（以最大努力的方式）。不过极小概率下容忍小部分写入会丢失。
- 可用性：分区情况下在多数派这边，当绝大多数的主节点是可达的，并且对于每一个不可达的主节点都至少有一个它的从节点可达的情况下，Redis Cluster 仍能提供服务。
通信协议
在 Redis 集群中，节点负责存储数据、记录集群的状态（包括 slots 信息）。集群节点同样能自动发现其他节点，检测出异常节点， 并且在需要的时候在从节点中推选出主节点。
为了执行这些任务，所有的集群节点都通过 TCP 连接和一个被称作 “Redis Cluster Bus” 的二进制协议进行通信。 每一个节点都通过集群总线与集群上的其余每个节点连接起来。节点们使用 Gossip 协议来传播集群的信息，使用 Gossip 协议的最大的好处是：即使集群节点的数量增加，每个节点的负载也不会增加很多，几乎是恒定的。这就允许 Redis Cluster 集群管理的节点规模能横向扩展到数千个。
Redis Cluster 中的每个节点都维护一份自己视角下的当前整个集群的状态，主要包括：
- 当前集群状态
- 集群中各节点所负责的 slots 信息，及其 migrate 状态
- 集群中各节点的 master-slave 状态
- 集群中各节点的存活状态及怀疑 Fail 状态
也就是说上面的信息，就是集群中Node相互八卦传播流言蜚语的内容主题，而且比较全面，既有自己的更有别人的，这么一来大家都相互传，最终信息就全面而且一致了。
消息类型
Redis Cluster 的节点之间会相互发送多种消息，较为重要的如下所示：
- MEET：通过 CLUSTER MEET 命令，已有集群的节点会向新的节点发送邀请，加入现有集群，然后新节点就会开始与其他节点进行通信。
- PING：节点按照配置的时间间隔向集群中其他节点发送 PING 消息，消息中带有自己的状态，还有自己维护的集群元数据，和部分其他节点的元数据，用于检测其他节点是否异常。
- PONG: 用于回应 PING 和 MEET 的消息，结构和 PING 消息类似。一个节点也可以通过向集群广播自己的PONG 消息来让集群中的其他节点立即刷新关于这个节点的认识，例如当一次故障转移操作成功执行之后，新的主节点会向集群广播一条 PONG 消息，以此来让集群中的其他节点立即知道这个节点已经变成了主节点。
- FAIL: 节点 PING 不通某节点后，会向集群所有节点广播该节点挂掉的消息，其他节点收到消息后标记已下线。
数据分片
哈希算法
关于数据分片方案最容易想到的的就是哈希算法，即对 key 计算一个 hash 值，然后对 master 节点个数取模，可以让 key 均匀分布到集群的各个节点上。
但这种模式其实存在较大的隐患，如上图所示，当一个节点故障后，将会导致整个集群的缓存失效。例如开始的算法为 hash(key) % 3，当一个节点故障后变为 hash(key) % 2，导致整个集群的大多数 key 都会因为取模变化而失效，从而导致缓存失效。当这种情况发生在缓存系统上时，整个系统的运行都有可能崩溃。
一致性哈希算法
既然普通的哈希算法存在上述的问题，于是就有人提出了一致性哈希算法，算法不再是对 master 节点数量来取模，而是固定对 2^32 取模，也就是值的范围在 [0, 2^32 -1] 。一致性哈希将其范围抽象成了一个圆环，使用CRC16 算法计算出来的哈希值会落到圆环上的某个地方。
同时 Redis 实例也分布在圆环上，计算出的值在圆环上按照顺时针的顺序找到第一个 Redis 实例即是服务实例，通过这样完成对 key 的节点分配。
如图所示，对于 key A 来说将找到 Node 3 节点，而对 key B 来说将找到 Node 2节点。
即便是当有节点发生故障，如图当 Node 3 发生故障时候，key A 将顺序找到 Node 2 进行服务。Node 3 的故障只导致了 Node 1 ~ Node 3 中间的 key 发生了转移，相较与普通哈希算法，对整个集群的影响已经大大减少了。
一致性哈希算法，也存在一些问题。如上图所示，当集群中节点较少时候，很容易产生节点在环上分布不均匀的情况，这样势必导致每个节点的负载不一致。节点分布的不均衡，非常容易导致系统的不稳定性或者资源的浪费。
于是又引入了虚拟节点的概念，为系统内的节点增加虚拟节点，虚拟节点与真实节点的功能一致，只是为了变相增加集群内节点的数量，从而使得节点能均匀的分步到 hash 环上。
Hash Slots
Redis Cluster 没有使用一致性哈希算法, 而是引入了哈希槽的概念。
Redis Cluster 中有 16384(2^14) 个哈希槽，每个 key 通过 CRC16 计算后对 16384 取模来决定放置哪个槽，然后决定服务节点。集群的每个节点负责一部分哈希槽，举个例子，比如当前集群有3个节点，那么可以这么分配哈希槽：
- 节点 A 包含 0 到 5500 号哈希槽
- 节点 B 包含 5501 到 11000 号哈希槽
- 节点 C 包含 11001 到 16383号哈希槽
这种结构很容易添加或删除节点。 比如我们想新添加个节点 D，我需要从节点 A，B，C 中移动部分哈希槽到节点 D 上。如果我想移除节点 A，需要将 A 中的哈希槽移到 B 和 C 节点上，然后将没有任何哈希槽的 A 节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加、删除或者改变某个节点的哈希槽的数量都不会造成集群不可用。