Redis cluster集群的介绍

1.前言

redis集群模式主要有2种:

主从集群、散布式集群。

前者主要是为了高可用或是读写分离，后者为了更好的存储数据，负载均衡。

redis集群提供了以下两个好处

1、将数据自动切分(split)到多个节点

2、当集群中的某一个节点故障时，redis还可以继续处理客户真个要求。

一个 redis 集群包括 16384 个哈希槽（hash slot），数据库中的每一个数据都属于这16384个哈希槽中的一个。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪一个槽。集群中的每个节点负责处理一部份哈希槽。

集群中的主从复制

集群中的每一个节点都有1个至N个复制品，其中一个为主节点，其余的为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点，继续工作。这样集群就不会由于一个主节点的下线而没法正常工作

注意：

1、如果某一个主节点和他所有的从节点都下线的话，redis集群就会停止工作了。redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已被履行过的写命令

2、使用异步复制（asynchronous replication）是redis 集群可能会丢失写命令的其中一个缘由，有时候由于网络缘由，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据就会丢失。

2. 主从切换原理

Redis的主从原理与MySQL类似，都是设置两台机器，一主一从。也就是常说的热备与冷备。设置主从的同时，设置两个哨兵进程，用来检测主节点会不会宕机。若发现主节点宕机，立马从从节点内选取出适合的节点 作为新的主节点。这点与VIP(虚拟IP技术有点类似)。

3.Redis群集TCP端口

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

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

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

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

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

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

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

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

4.Redis集群和Docker

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

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

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

5.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 作为参数的命令中一起使用。

6.Redis集群之主从模型

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

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

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

7.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 (节点超时)。

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

8.redis容错机制

每一个redis提供了节点之间相互发送ping命令，用于测试每一个节点的健康状态，集群中连接正常的节点收到其他接节点发送的ping命令时，会返回一个pong字符串

Redis投票机制：如果一个节点A给B发送ping没有得到pong返回，那末A就会通知其他节点再次给B发送ping，如果集群中超过一半的节点给B发送ping都没有得到返回，那末B就被坐实game over了，所以为了不单点故障，一般都会为redis的每一个节点提供了备份节点，B节点挂掉以后立马启动B的节点服务器。

总结

本篇文章到此结束，如果您有相关技术方面疑问可以联系我们技术人员远程解决，感谢大家支持本站！

本文来源：https://www.yuntue.com/post/153887.html | 云服务器网，转载请注明出处！