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 -1个附加从节点）。

在我们具有节点a，b，c的示例的群集中，如果节点b失败，则群集无法继续，因为我们没有办法再在5501-11000范围内提供散列槽。然而，当创建集群时（或稍后），我们为每个主服务器节点添加一个从服务器节点，以便最终集群由作为主服务器节点的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的节点服务器。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。如果你想了解更多相关内容请查看下面相关链接