Redis集群-cluster

Redis的Cluster集群搭建

 

是否使用过Redis集群，集群的原理是什么？

Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。

 

一、Redis群集

Redis集群提供了一种运行Redis设备的方式，并且数据可以在多个Redis节点间自动分配的。Redis集群在分区期间也能提供一定程度的可用性，实际上，就是说当某些节点发生故障或无法通信时，集群能够继续运行。 但是，如果发生较大故障（例如，大多数主站服务器不可用时），群集会停止运行。

 

那么从实际角度而言，您使用Redis Cluster能获得什么呢？

1、在多个节点之间自动分割数据集的能力。

2、在节点子集遇到故障或无法与集群其余部分通信时继续运行的能力。

 

二、Redis群集TCP端口

 

每个Redis群集的节点都需要打开两个TCP连接，由于这两个连接就需要两个端口，分别是用于为客户端提供服务的常规Redis TCP命令端口（例如6379）以及通过将10000和命令端口相加（10000+6379）而获得的端口，就是集群端口（例如16379）。

 

第二个大号端口用于群集总线，即使用二进制协议的节点到节点通信通道。 节点使用群集总线进行故障检测，配置更新，故障转移授权等。 客户端不应尝试与群集总线端口通信，为了保证Redis命令端口的正常使用，请确保在防火墙中打开这两个端口，否则Redis群集节点将无法通信。

 

命令端口和集群总线端口偏移量是固定的，始终为10000。

 

请注意，为了让Redis群集正常工作，您需要为每个节点：

 

1、用于与客户端进行通信的普通客户端通信端口（通常为6379）对所有需要到达群集的客户端以及所有其他群集节点（使用客户端端口进行密钥迁移）都是开放的。

2、集群总线端口（客户端端口+ 10000）必须可从所有其他集群节点访问。

 

如果您不打开这两个TCP端口，则您的群集将无法正常工作。

 

集群总线使用不同的二进制协议进行节点到节点的数据交换，这更适合于使用很少的带宽和处理时间在节点之间交换信息。

     

三、Redis集群和Docker

 

目前，Redis群集不支持NAT地址环境，并且在IP地址或TCP端口被重新映射的一般环境中。

 

Docker使用一种叫做端口映射的技术：Docker容器中运行的程序可能会暴露在与程序认为使用的端口不同的端口上。 这对于在同一服务器中同时使用相同端口运行多个容器很有用。

为了使Docker与Redis Cluster兼容，您需要使用Docker的主机联网模式。 请查看Docker文档中的--net = host选项以获取更多信息。

 

四、Redis集群数据分片

Redis集群分片原理

Redis集群没有使用一致的散列，而是一种不同的分片形式，其中每个 key 在概念上都是我们称之为散列槽的部分。

 

Redis集群中有16384个散列槽，为了计算给定 key 的散列槽，我们简单地取16384模的CRC16。

Redis集群中的每个节点负责哈希槽的一个子集，例如，您可能有一个具有3个节点的集群，其中：

1、节点A包含从0到5500的散列槽。

2、节点B包含从5501到11000的散列槽。

3、节点C包含从11001到16383的散列槽。

 

这允许轻松地添加和删除集群中的节点。例如，如果我想添加一个新节点D，我需要将节点A，B，C中的一些散列槽移动到D。同样，如果我想从集群中删除节点A，我可以只移动由A使用的散列槽到B和C，当节点A将为空时，我可以将它从群集中彻底删除。

 

因为将散列槽从一个节点移动到另一个节点不需要停机操作，添加和移除节点或更改节点占用的散列槽的百分比也不需要任何停机时间。

 

只要涉及单个命令执行（或整个事务或Lua脚本执行）的所有 key 都属于同一散列插槽，Redis群集就支持多个 key 操作。用户可以使用称为散列标签的概念强制多个 key 成为同一个散列槽的一部分。

 

Hash标记记录在Redis集群规范文档中，但要点是如果在关键字{}括号内有一个子字符串，那么只有该花括号“{}”内部的内容被散列，例如 this{foo}key 和 another{foo}key 保证在同一散列槽中，并且可以在具有多个 key 作为参数的命令中一起使用。

 

五、Redis集群之主从模型

 

为了在主服务器节点的子集失败或不能与大多数节点通信时保持可用，Redis集群使用主从模型，其中每个散列槽从1（主服务器本身）到N个副本（N -1个附加从节点）。

 

在我们具有节点A，B，C的示例的群集中，如果节点B失败，则群集无法继续，因为我们没有办法再在5501-11000范围内提供散列槽。然而，当创建集群时（或稍后），我们为每个主服务器节点添加一个从服务器节点，以便最终集群由作为主服务器节点的A，B，C以及作为从服务器节点的A1，B1，C1组成，如果节点B发生故障，系统能够继续运行。节点B1复制B，并且B失败，则集群将促使节点B1作为新的主服务器节点并且将继续正确地操作。

 

但请注意，如果节点B和B1在同一时间发生故障，则Redis群集无法继续运行。

 

六、Redis集群一致性保证

 

Redis 集群无法保证很强的一致性。实际上，这意味着在某些情况下，Redis 集群可能会丢失系统向客户确认的写入。

 

　Redis集群可能会丢失写入的第一个原因是因为它使用异步复制。这意味着在写入期间会发生以下事情：

 

1、你的客户端写给主服务器节点 B

2、主服务器节点B向您的客户端回复确认。

3、主服务器节点B将写入传播到它的从服务器B1，B2和B3。

 

正如你可以看到主服务器节点 B 在回复客户端之前不等待B1，B2，B3的确认，因为这会对Redis造成严重的延迟损失，所以如果你的客户端写入了某些东西，主服务器节点 B 确认写入，就在将写入发送给它的从服务器节点存储之前系统崩溃了，其中一个从站（没有收到写入）可以提升为主站，永远丢失写入。

 

这与大多数配置为每秒将数据刷新到磁盘的数据库所发生的情况非常相似，因为过去的经验与传统数据库系统有关，不会涉及分布式系统，因此您已经能够推断这种情况。同样，通过强制数据库在回复客户端之前刷新磁盘上的数据，这样可以提高一致性，但这通常会导致性能极低。这与Redis Cluster中的同步复制相当。

 

基本上，性能和一致性之间需要权衡。

 

Redis集群在绝对需要时也支持同步写入，通过WAIT命令实现，这使得丢失写入的可能性大大降低，但请注意，即使使用同步复制，Redis集群也不可能实现完全的一致性：总是有可能会发生故常，在无法接受写入的从设备被选为主设备的时候 。

 

还有另一个值得注意的情况，Redis集群也将丢失数据的写入，这种情况发生在网络分区的时候，客户端与包含至少一个主服务器的少数实例隔离。

 

以A，B，C，A1，B1，C1三个主站和三个从站组成的6个节点集群为例。还有一个客户，我们会调用Z1。

分区发生后，可能在分区的一侧有A，C，A1，B1，C1，另一侧有B和Z1。

Z1仍然能够写入B，它也会接受Z1的写入。如果分区在很短的时间内恢复，则群集将正常继续。但是，如果分区使用比较长的时间将B1提升为多数侧分区的主设备，则Z1发送给B的写入操作将丢失。

请注意，Z1能够发送给B的写入量有一个最大窗口（maximum window）：如果分区多数侧有足够的时间选择一个从设备作为主设备，那么少数侧的每个主节点将停止接受写操作。

 

这个时间值是Redis集群非常重要的配置指令，称为 node timeout (节点超时)。

 

在节点超时过后，主节点被认为是失效的，并且可以被其副本之一替换。类似地，节点超时过后，主节点无法感知大多数其他主节点，它进入错误状态并停止接受写入。