Redis 集群介绍

Redis 集群是一个提供在多个 Redis 节点间共享数据的程序集。
Redis 集群通过分区来提高程序的可用性，在实际环境中当某个节点宕机或者无法访问的情况下继续处理命令。

Redis 集群的优势（相比单台 Redis 服务）：

• 自动分割数据到不同的节点上。
• 整个集群的部分节点失败或者不可访问的情况下能够继续处理命令，提高程序的可用性。

Redis 集群的数据分片

Redis 集群没有使用一致性 hash，而是引入了哈希槽的概念。
Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽。集群的每个节点各负责一部分哈希槽。
例如，当前集群有 3 个节点，则：

• 节点 A 包含 0 到 5500 号哈希槽
• 节点 B 包含 5501 到 11000 号哈希槽
• 节点 C 包含 11001 到 16384 号哈希槽

这种结构很容易添加或者删除节点。比如要新添加一个节点 D ，则需要从节点 A、B、C 中移动部分哈希槽到 D 上。如果要移除节点 A ，则需要将 A 中的哈希槽移动到 B 和 C 节点上，然后将没有任何哈希槽的 A 节点从集群中移除。

由于从一个节点移动哈希槽到另一个节点并不会停止服务，所以无论添加、删除或者改变某个节点哈希槽的数量都不会造成集群不可用的状态。

Redis 集群的主从复制模型

为了使在部分节点宕机或者大部分节点无法提供服务的情况下，集群仍然可用，因此集群使用了主从复制模型，即，每个节点都会有 N-1 个复制从节点。

在上述示例中，具有 A、B、C 三个节点的集群，在没有复制模型的情况下，如果节点 B 宕机，那么整个集群会因为缺少 5501-11000 这个范围内的哈希槽而不可用。

然而，如果在集群创建的时候（或者是创建后，节点发生故障前），为每个节点添加一个从节点 A1、B1、C1，那么整个集群中就有 3 个 master 节点和 3 个 slave 节点组成。这样在节点 B 宕机后，集群便会选举 B1 为新的主节点继续服务，保证整个集群稳健的对外提供服务。

当然，如果 B 和 B1 都宕机后，集群也是不可用的。所以，实质上单单主从复制模型而言，也是降低集群发生故障造成集群不可用的概率。

Redis 数据一致性

Redis 并不能保证数据的强一致性。这意味着在实际中，集群在特定条件下可能会丢失写操作。主要由以下两个原因造成。
第一个原因是因为集群使用了异步复制。集群的“写”操作流程为：

• 客户端向主节点 A 写入一条命令；
• 主节点 A 向客户端回复命令执行结果；
• 主节点将“写”操作复制给它的从节点 A1、A2 等。

之所以使用异步复制，是因为同步复制会大大降低主节点处理命令的速度。这也是在性能和数据一致性之间做出权衡。

另一个原因则是在集群中会出现网络分区。当出现网络分区，并且一个客户端与至少一个主节点在内的少数实例被孤立，就会出现数据不一致的情况。

举个栗子，假设一个集群包含 A、B、C、A1、B1、C1 六个节点，其中 A、B、C 为主节点，A1、B1、C1 为 A、B、C 的从节点。同时，有一个客户端 Z1，此时出现网络分区，集群分为两方，大的一方包含节点 A、C、A1、B1、C1，小的一方包含节点 B 和客户端 Z1。
此时，Z1 仍然能够向主节点 B 写入数据，但当网络分区时间较长，致使大的一方将 B1 选举为新的maser，那么 Z1 写入 B 中的数据便丢失了。

需要注意的是，在网络分区期间，客户端 Z1 向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是 Redis 集群的一个重要配置项。