Redis Cluster 101
Redis Cluster提供了一种运行Redis安装的方法，在该安装中，数据会在多个Redis节点之间自动分片。
Redis Cluster在分区期间还提供了一定程度的可用性，这实际上就是在某些节点出现故障或无法通信时继续操作的能力。但是，如果发生较大故障（例如，大多数主服务器不可用时），群集将停止运行。
因此，实际上，Redis Cluster能带来什么？
- 自动在多个节点之间拆分数据集的能力。
- 当一部分节点出现故障或无法与其余群集通信时，可以继续操作。
Redis Cluster TCP ports
每个Redis群集节点都需要打开两个TCP连接。用于服务客户端的常规Redis TCP端口，例如6379，再加上将数据端口加10000所获得的端口，因此在示例中为16379。
第二个高端口用于群集总线，即使用二进制协议的节点到节点通信通道。节点将群集总线用于故障检测，配置更新，故障转移授权等。客户端永远不要尝试与群集总线端口进行通信，而应始终与普通的Redis命令端口进行通信，但是请确保您同时打开防火墙中的两个端口，否则Redis群集节点将无法进行通信。
命令端口和集群总线端口偏移是固定的，并且始终为10000。
请注意，对于每个节点，要使Redis群集正常工作，您需要：
- 普通客户端通信端口（通常为6379）用于与客户端通信，以向需要访问群集的所有客户端以及所有其他群集节点（使用客户端端口进行密钥迁移）开放。
- 群集总线端口（客户端端口+ 10000）必须可以从所有其他群集节点访问。
如果您没有同时打开两个TCP端口，则您的群集将无法正常工作。
集群总线使用不同的二进制协议进行节点到节点的数据交换，它更适合于使用很少的带宽和处理时间在节点之间交换信息。
Redis Cluster and Docker
当前，Redis Cluster不支持NATted环境以及在重新映射IP地址或TCP端口的常规环境中。
Docker使用一种称为端口映射的技术：与该程序认为正在使用的端口相比，在Docker容器内运行的程序可能会使用不同的端口公开。为了在同一服务器上同时使用同一端口运行多个容器，这很有用。
为了使Docker与Redis Cluster兼容，您需要使用Docker的主机联网模式。请检查Docker文档中的--net = host选项以获取更多信息。
Redis Cluster data sharding
Redis Cluster不使用一致的哈希，而是使用一种不同形式的分片，其中每个键从概念上讲都是我们称为哈希槽的一部分。
Redis集群中有16384个哈希槽，要计算给定密钥的哈希槽，我们只需对密钥的CRC16取模16384。
Redis群集中的每个节点都负责哈希槽的子集，因此，例如，您可能有一个包含3个节点的群集，其中：
- 节点A包含从0到5500的哈希槽。
- 节点B包含从5501到11000的哈希槽。
- 节点C包含从11001到16383的哈希槽。
这样可以轻松添加和删除集群中的节点。例如，如果我想添加一个新的节点D，则需要将一些哈希槽从节点A，B，C移到D。类似地，如果我想从群集中删除节点A，则只需移动A所服务的哈希槽到B和C。当节点A为空时，我可以将其从群集中完全删除。
因为将哈希槽从一个节点移动到另一个节点不需要停止操作，所以添加和删除节点或更改节点持有的哈希槽的百分比不需要任何停机时间。
只要单个命令执行（或整个事务或Lua脚本执行）中涉及的所有键都属于同一个哈希槽，Redis Cluster就支持多种键操作。用户可以通过使用称为哈希标签的概念来强制多个密钥成为同一哈希槽的一部分。
哈希标签记录在Redis Cluster规范中，但是要点是，如果密钥的{}括号之间有一个子字符串，则仅对字符串中的内容进行哈希处理，例如，此{foo}键和另一个{foo} key保证在同一哈希槽中，并且可以在以多个key作为参数的命令中一起使用。
Redis Cluster master-slave model
为了在主节点子集出现故障或无法与大多数节点通信时保持可用，Redis Cluster使用主从模型，其中每个哈希槽具有从1（主节点本身）到N个副本（N -1个其他从属节点）。
在具有节点A，B，C的示例集群中，如果节点B失败，则集群将无法继续，因为我们不再有办法为5501-11000范围内的哈希槽提供服务。
但是，在创建集群（或稍后）时，我们向每个主节点添加一个从属节点，以便最终集群由作为主节点的A，B，C和作为从属节点的A1，B1，C1组成。这样，如果节点B发生故障，系统就可以继续。
节点B1复制B，并且B失败，群集将把节点B1提升为新的主节点，并将继续正常运行。
但是，请注意，如果节点B和B1同时发生故障，则Redis Cluster无法继续运行。
Redis Cluster consistency guarantees（集群一致性保证）
Redis Cluster无法保证强一致性。实际上，这意味着在某些情况下，Redis Cluster可能会丢失系统认可给客户端的写入。
Redis Cluster可能丢失写入的第一个原因是因为它使用异步复制。这意味着在写入期间会发生以下情况：
- 您的客户写信给主B。
- 主B向您的客户答复“确定”。
- 主机B将写操作传播到其从机B1，B2和B3。
如您所见，B在回复客户端之前不会等待B1，B2，B3的确认，因为这会对Redis造成极高的延迟影响，因此，如果您的客户端写了一些东西，B会确认写，但是在崩溃之前崩溃由于能够将写操作发送到其从属设备，因此一个从属设备（未接收到写操作）可以升级为主设备，从而永远丢失写操作。
这与配置为每秒将数据刷新到磁盘的大多数数据库所发生的情况非常相似，因此由于过去使用不涉及分布式系统的传统数据库系统的经验，您已经可以对此进行推理。同样，您可以通过强制数据库在答复客户端之前将数据刷新到磁盘来提高一致性，但这通常会导致性能过低。在Redis Cluster的情况下，这相当于同步复制。
基本上，要在性能和一致性之间进行权衡。
Redis Cluster在绝对需要时支持通过WAIT命令实现的同步写入。这使丢失写入的可能性大大降低。但是，请注意，即使使用同步复制，Redis Cluster也无法实现强一致性：在更复杂的故障情况下，总是有可能将无法接收写入的从设备选为主服务器。
还有另一种值得注意的情况，Redis Cluster将丢失写操作，这种情况发生在网络分区期间，在该分区中，客户端与少数实例（至少包括主实例）隔离。
以我们的6个节点集群为例，该集群由A，B，C，A1，B1，C1组成，具有3个主节点和3个从节点。还有一个客户，我们将其称为Z1。
发生分区后，可能在分区的一侧有A，C，A1，B1，C1，而在另一侧有B和Z1。
Z1仍然能够写入B，它将接受其写入。如果分区在很短的时间内恢复正常，则群集将继续正常运行。但是，如果分区持续的时间足以使B1升级为该分区的多数端的主服务器，那么Z1在此期间发送给B的写入将丢失。
请注意，Z1将能够发送给B的写入量有一个最大的窗口：如果已经有足够的时间让分区的多数派选举出一个从属主机，则少数派的每个主节点都将停止。接受写。
此时间量是Redis Cluster的一个非常重要的配置指令，称为节点超时。
节点超时过去之后，将主节点视为发生故障，并且可以用其副本之一替换该主节点。类似地，在没有主节点能够感知其他大多数主节点的节点超时之后，它进入错误状态并停止接受写操作。
Redis Cluster configuration parameters(集群配置)
我们将创建一个示例集群部署。在继续之前，让我们介绍Redis Cluster在redis.conf文件中引入的配置参数。当您继续阅读时，有些会很明显，有些会更清晰。
cluster-enabled <yes/no>:yes在特定Redis实例中启用Redis Cluster支持。否则，该实例将像往常一样作为独立实例启动。
cluster-config-file <filename>: 请注意，尽管有此选项的名称，但它不是用户可编辑的配置文件，而是Redis Cluster节点每次发生更改时都会自动保留集群配置（基本上是状态）的文件，以便能够在启动时重新阅读。该文件列出了诸如集群中其他节点之类的东西，它们的状态，持久变量等等。通常，由于收到某些消息，此文件将被重写并刷新到磁盘上。
cluster-node-timeout <milliseconds>:Redis群集节点不可用的最长时间（不视为失败）。如果主节点无法访问的时间超过指定的时间量，则其主节点将对其进行故障转移。此参数控制Redis Cluster中的其他重要事项。值得注意的是，在指定的时间内无法到达大多数主节点的每个节点都将停止接受查询。
cluster-slave-validity-factor <factor>:如果设置为零，则从站将始终认为自己有效，因此将始终尝试对主机进行故障转移，而不管主机和从站之间的链接保持断开状态的时间长短。如果该值为正，则将最大断开时间计算为节点超时值乘以此选项提供的因子，如果该节点是从节点，则如果主链路断开了更多连接，它将不会尝试启动故障转移。超过指定的时间。例如，如果节点超时设置为5秒，而有效性因子设置为10，则从服务器与主服务器断开连接超过50秒将不会尝试对其主服务器进行故障转移。请注意，如果没有从属服务器可以对其进行故障转移，则任何不为零的值都可能导致Redis Cluster在主服务器发生故障后不可用。在这种情况下，只有当原始主服务器重新加入群集后，群集才会恢复可用。
cluster-migration-barrier <count>:一个主站将保持连接的最小数量的从站，以便另一个从站迁移到不再受任何从站覆盖的主站。有关更多信息，请参见本教程中有关副本迁移的相应部分。
cluster-require-full-coverage <yes/no>: 如果将其设置为“yes”（默认情况下为yes），则在任何节点未覆盖一定比例的密钥空间的情况下，群集将停止接受写入。如果该选项设置为no，即使仅可以处理有关密钥子集的请求，群集仍将提供查询。
cluster-allow-reads-when-down <yes/no>: 如果将其设置为no（默认情况下为no），则当Redis群集中的节点被标记为失败时，或者当节点无法达到法定主机数量时，或者当无法完全覆盖时，Redis群集中的节点将停止为所有流量提供服务。遇见。这样可以防止从不知道群集更改的节点读取可能不一致的数据。可以将此选项设置为yes，以允许在失败状态期间从节点进行读取，这对于希望优先考虑读取可用性但仍希望防止写入不一致的应用程序很有用。当仅使用一个或两个分片的Redis Cluster时，也可以使用它，因为它允许节点在主服务器发生故障但无法进行自动故障转移时继续为写入提供服务。