共计 3907 个字符，预计需要花费 10 分钟才能阅读完成。
这篇文章主要为大家展示了“Redis 中 cluster 集群的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“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 的节点服务器。
以上是“Redis 中 cluster 集群的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
