Redis：集群教程 - 版本历史

Eijux：/* Redis集群：数据分片 */

2021-11-04T05:19:11Z

Redis集群：数据分片

←上一版本		2021年11月4日 (四) 13:19的版本
第42行：		第42行：

	=== Redis集群：数据分片 ===		=== Redis集群：数据分片 ===
	Redis Cluster ~~不使用[~~[http://wiki.eijux.com/%E5%85%B3%E4%BA%8E%EF%BC%9A%E4%B8%80%E8%87%B4%E6%80%A7%E5%93%88%E5%B8%8C%E7%AE%97%E6%B3%95 ~~一致哈希（consistency~~ hashing）]~~]，而是一种不同形式的分片，其中每个键在概念上都是我们所称的~~'''散列槽'''的一部分。		Redis Cluster 不使用“[http://wiki.eijux.com/%E5%85%B3%E4%BA%8E%EF%BC%9A%E4%B8%80%E8%87%B4%E6%80%A7%E5%93%88%E5%B8%8C%E7%AE%97%E6%B3%95 一致性哈希（consistency hashing）]”，而是一种不同形式的分片，其中每个键在概念上都是我们所称的'''散列槽'''的一部分。

	Redis 集群中有 '''16384'''（2 ^ 14）个哈希槽，使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。		Redis 集群中有 '''16384'''（2 ^ 14）个哈希槽，使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。

Eijux：/* 升级群集中的节点 */

2021-11-04T03:46:52Z

升级群集中的节点

←上一版本		2021年11月4日 (四) 11:46的版本
第467行：		第467行：

	=== 升级群集中的节点 ===		=== 升级群集中的节点 ===
			升级副本节点很容易，因为您只需要停止节点并使用更新版本的Redis重新启动它。如果存在使用副本节点进行扩展读取的客户端，当给定副本不可用，它们应该能够重新连接到其他副本。

			升级masters有点复杂，建议的程序是：
			# 使用 '''CLUSTER FAILOVER''' 触发主服务器到其副本之一的手动故障转移。
			# 等待 master 变成副本。
			# 最后像复制副本一样升级节点。
			# 如果您希望 master 成为您刚刚升级的节点，请触发新的手动故障转移，以便将升级后的节点恢复为 master。


			=== 迁移到Redis集群 ===
			愿意迁移到 Redis 群集的用户可能只有一个主节点，或者可能已经在使用预先存在的分片设置，其中 keys 在 N 个节点之间分割，使用一些内部算法或由其客户端库或 Redis 代理实现的分片算法。

			在这两种情况下，都可以轻松迁移到 Redis Cluster，但最重要的细节是应用程序是否使用多个键操作，以及如何使用。

			有三种不同的情况：
			# 不使用多键操作，或事务，或涉及多键的 Lua 脚本。键是独立访问的（即使通过事务或 Lua 脚本将多个命令分组，大约相同的键，一起访问）。
			# 使用多键操作、事务或涉及多个键的 Lua 脚本，但仅使用具有相同哈希标签的键，这意味着一起使用的键都有一个“{...}”恰好相同的子字符串。
			#: 例如，在同一个哈希标签的上下文中定义了以下多键操作：“SUNION {user:1000}.foo {user:1000}.bar”。
			# 涉及多个键的多键操作、事务或 Lua 脚本，与没有显式或相同哈希标签的键名一起使用：


			* 第三情况不是由 Redis Cluster 处理的：需要修改应用程序，以便不使用多键操作或仅在同一哈希标记的上下文中使用它们。
			* 案例1 和案例2 已经涵盖，因此我们将重点关注这两个案例，它们以相同的方式处理，因此在文档中不会进行区分。


			假设您将预先存在的数据集拆分为 N 个 master，其中 N=1 如果您没有预先存在的分片，则需要执行以下步骤才能将您的数据集迁移到 Redis Cluster：
			# 停止你的客户段。目前无法自动实时迁移到Redis群集。您可以在应用程序/环境的上下文中协调实时迁移。
			# 使用 BGREWRITEAOF 命令为所有 N 个 master 生成一个 append only 文件，并等待 AOF 文件完全生成。
			# 将 AOF 文件从 aof-1 保存到 aof-N 某处。此时，您可以根据需要停止旧实例（这很有用，因为在非虚拟化部署中您经常需要重复使用相同的计算机）。
			# 创建一个由 N 个 master 和 0 个副本组成的 Redis Cluster。稍后将添加副本。确保您的所有节点都使用 AOF 文件进行持久化。
			# 停止所有集群节点，将它们的 AOF 文件替换为您预先存在的仅附加文件，第一个节点为 aof-1，第二个节点为 aof-2，最多为 aof-N。
			# 使用新的 AOF 文件重新启动 Redis 集群节点。他们会抱怨说，根据他们的配置，有些 keys 不应该存在。
			# 使用 '''redis-cli --cluster fix''' 命令来修复集群，以便根据每个节点是否具有权威性的哈希槽来迁移 keys。
			# 最后使用 '''redis-cli --cluster check''' 以确保您的群集正常。
			# 重新启动修改为使用 Redis 集群感知客户端库的客户端。


			有另一种方法可以将数据从外部实例导入到 Redis 集群，即使用 '''redis-cli --cluster import''' 命令。
			: 该命令将正在运行的实例的所有键（从源实例中删除键）移动到指定的预先存在的 Redis 集群。
			* 但是请注意，如果您使用 Redis 2.8 实例作为源实例，则操作可能会很慢，因为 2.8 没有实现迁移连接缓存，因此您可能希望在执行此类操作之前使用 Redis 3.x 版本重新启动源实例。

Eijux：/* 副本迁移 */

2021-11-04T03:08:46Z

副本迁移

←上一版本		2021年11月4日 (四) 11:08的版本
第443行：		第443行：

	=== 副本迁移 ===		=== 副本迁移 ===
			在 Redis Cluster 中，只要使用以下命令，就可以随时重新配置一个副本对不同的主机进行复制：
			'''<syntaxhighlight lang="bash" highlight="">
			redis 127.0.0.1:7006> cluster replicate <master-node-id>
			</syntaxhighlight>'''


			但是，在一种特殊情况下，您希望在没有系统管理员的帮助下，副本从一个主机从一个主机移动到另一个主的情况。副本的自动重新配置称为'''副本迁移'''，并且能够提高 Redis 集群的可靠性。

			您可能希望在特定条件下让集群副本从一个主节点移动到另一个主节点的原因是，通常 Redis 集群的抗故障能力与附加到给定主节点的副本数量一样。

			例如，如果主节点和它的副本同时失败，其中每个主节点都有一个副本的集群无法继续操作，这仅仅是因为没有其他实例拥有主节点所服务的哈希槽的副本。然而，虽然网络分裂可能同时隔离多个节点，但许多其他类型的故障，如单个节点本地的硬件或软件故障，是一类非常显着的故障，不太可能同时发生时间，所以有可能在你的集群中，每个主节点都有一个副本，副本在凌晨 4 点被杀死，而主节点在早上 6 点被杀死。这仍然会导致集群无法再运行。

			为了提高系统的可靠性，我们可以选择向每个主服务器添加额外的副本，但这很昂贵。副本迁移允许向少数主服务器添加更多副本。因此，您有 10 个 master，每个 master 有 1 个副本，总共有 20 个实例。但是，例如，您添加了 3 个以上的实例作为某些 master 的副本，因此某些 master 将拥有多个副本。

			对于副本迁移，如果一个 master 没有副本，那么来自具有多个副本的 master 的副本将迁移到孤立的master。所以当你的副本在我们上面的例子中在凌晨 4 点宕机后，另一个副本将取代它，当主节点在凌晨 5 点也失败时，仍然可以选择一个副本，以便集群可以继续操作。


			那么，简而言之，您应该了解的关于副本迁移的知识是什么？
			* 集群将尝试从在给定时刻拥有最多副本的主节点迁移副本。
			* '''要从副本迁移中受益，您只需向集群中的单个主服务器添加更多副本，无论哪个主服务器都无关紧要。'''
			* 有一个配置参数控制副本迁移功能，称为'''cluster-migration-barrier'''：您可以在 Redis Cluster 提供的示例 redis.conf 文件中阅读有关它的更多信息。


			=== 升级群集中的节点 ===

Eijux：/* 测试故障转移 */

2021-11-04T02:37:14Z

测试故障转移

显示更改

Eijux：/* Redis集群：一致性保证 */

2021-11-04T01:45:35Z

Redis集群：一致性保证

←上一版本		2021年11月4日 (四) 09:45的版本
第86行：		第86行：
	:# 主 B 将写入传播到其副本 B1、B2 和 B3。		:# 主 B 将写入传播到其副本 B1、B2 和 B3。
	: 如您所见，B 在回复客户端之前不会等待来自 B1、B2、B3 的确认，因为这对 Redis 来说是一个令人望而却步的延迟惩罚，因此如果您的客户端写入某些内容，B 会确认写入，但如果在将写入发送到其副本之前崩溃，其中一个副本（未收到写入）可以提升为主，那么写入的内容将永远丢失。		: 如您所见，B 在回复客户端之前不会等待来自 B1、B2、B3 的确认，因为这对 Redis 来说是一个令人望而却步的延迟惩罚，因此如果您的客户端写入某些内容，B 会确认写入，但如果在将写入发送到其副本之前崩溃，其中一个副本（未收到写入）可以提升为主，那么写入的内容将永远丢失。
			:* 然而，这种情况不太可能发生，因为Redis几乎同时向客户机发送回复和复制到副本的命令，因此丢失数据的窗口很小。但是，很难触发的事实并不意味着不可能触发，因此这不会改变 Redis cluster 提供的一致性保证。

	~~这与大多数配置为“每秒将数据刷新到磁盘”的数据库发生的情况非常相似~~		这与大多数配置为“每秒将数据刷新到磁盘”的数据库发生的情况非常相似。

	您可以通过强制数据库在回复客户端之前将数据刷新到磁盘来提高一致性，但这通常会导致效率过低。在 Redis Cluster 的情况下，这相当于同步复制。		您可以通过强制数据库在回复客户端之前将数据刷新到磁盘来提高一致性，但这通常会导致效率过低。在 Redis Cluster 的情况下，这相当于同步复制。

Eijux：/* 测试故障转移 */

2021-11-04T01:43:09Z

测试故障转移

←上一版本		2021年11月4日 (四) 09:43的版本
第296行：		第296行：

	=== 测试故障转移 ===		=== 测试故障转移 ===
			为了触发故障转移，我们可以做的最简单的事情（这也是分布式系统中可能发生的语义上最简单的故障）是使单个进程崩溃，在我们的例子中是使单个主进程崩溃。

			# 我们可以通过以下命令识别 maser 并使其崩溃：
			#: <syntaxhighlight lang="bash" highlight="">
			$ redis-cli -p 7000 cluster nodes \| grep master
			3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385482984082 0 connected 5960-10921
			2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 master - 0 1385482983582 0 connected 11423-16383
			97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922-11422
			</syntaxhighlight>
			#: 如上 7000、7001 和 7002 是 maser。让我们使用 '''DEBUG SEGFAULT''' 命令使节点 7002 崩溃：
			#: <syntaxhighlight lang="bash" highlight="">
			$ redis-cli -p 7002 debug segfault
			Error: Server closed the connection
			</syntaxhighlight>

Eijux：/* 创建并使用Redis群集 */

2021-11-04T01:39:45Z

创建并使用Redis群集

显示更改

Eijux：/* Redis集群配置参数 */

2021-11-03T23:54:08Z

Redis集群配置参数

←上一版本		2021年11月4日 (四) 07:54的版本
第107行：		第107行：

	== Redis集群配置参数 ==		== Redis集群配置参数 ==
			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>'''：
			*# 如果设置为 0，副本将始终认为自己有效，因此无论主服务器和副本之间的链接保持断开连接的时间长短，将始终尝试故障转移主服务器。
			*# 如果值为正，则将节点超时值乘以此选项提供的因子，作为最大断开时间，并且如果节点是副本，在主链接断开的时间超过指定的时间，它不会尝试启动故障转移。
			*: 例如，如果节点超时设置为 5 秒且有效性因子设置为 10，则与主服务器断开连接超过 50 秒的副本将不会尝试对其主服务器进行故障转移。
			** 请注意，如果没有用于故障转移的副本，则任何非零值都可能导致 Redis 集群在主节点故障后不可用。在这种情况下，只有当原始主节点重新加入集群时，集群才会恢复可用。
			* '''cluster-migration-barrier <count>'''：一个 master 将保持连接的最小副本数，以便另一个副本迁移到不再被任何副本覆盖的 master。【？】
			* '''cluster-require-full-coverage <yes/no>'''：
			*# 如果将其设置为 yes（默认），如果任何节点都没有覆盖一定百分比的 key space，则集群将停止接受写入。
			*# 如果该选项设置为 no，即使只能处理关于 key 子集的请求，集群仍将提供查询服务。
			* '''cluster-allow-reads-when-down <yes/no>'''：
			*# 如果设置为 no（默认），当集群被标记为失败时，Redis 集群中的节点将停止服务所有流量，无论是当节点数量无法达到主机的 quorum配置，还是没有达到全覆盖。
			# 这可以防止从不知道集群中的变化的节点读取可能不一致的数据。
			*# 可以将此选项设置为 yes 以允许在失败状态期间从节点读取，这对于希望优先考虑读取可用性但仍希望防止不一致写入的应用程序非常有用。
			# 它也可以用于使用只有一个或两个分片的 Redis Cluster 时，因为它允许节点在主节点发生故障但无法自动故障转移时继续提供写入服务。

			== 创建并使用Redis群集 ==

Eijux：建立内容为“category:Redis == 关于 == 参考：[https://redis.io/topics/cluster-tutorial https://redis.io/topics/cluster-tutorial] 以下包含了有关如何设…”的新页面

2021-11-03T23:31:03Z

建立内容为“category:Redis == 关于 == 参考：[https://redis.io/topics/cluster-tutorial https://redis.io/topics/cluster-tutorial] 以下包含了有关如何设…”的新页面

新页面

[[category:Redis]]

== 关于 ==
参考：[https://redis.io/topics/cluster-tutorial https://redis.io/topics/cluster-tutorial]

以下包含了有关如何设置集群、测试和操作集群的说明，而不涉及Redis 集群规范中涵盖的细节。

== Redis 集群 ==
Redis Cluster 提供了一种运行 Redis 安装的方法，其中'''数据在多个 Redis 节点之间自动分片'''。

Redis Cluster 还在'''分区期间'''提供了'''一定程度的可用性'''，这实际上是在某些节点出现故障或无法通信时继续操作的能力。但是，如果发生较大的故障（例如，当大多数主节点不可用时），集群将停止运行。

那么在实践中，您从 Redis Cluster 中得到了什么？
# 在多个节点之间自动拆分数据集的能力。
# 当部分节点出现故障或无法与集群的其余部分通信时继续操作的能力。

=== Redis 集群：TCP 端口 ===
每个 Redis Cluster 节点都需要打开两个 TCP 连接：
# 用于为客户端提供服务的普通 Redis TCP 端口（如：6379）；
# 以及名为“集群总线端口”（Cluster Bus Port）的第二个端口。
#* 集群总线端口：将数据端口+10000（如：16379）添加10000；或使用集群端口配置覆盖。

第二个高端口用于集群总线，即使用二进制协议的节点到节点通信通道。节点使用集群总线进行故障检测、配置更新、故障转移授权等。

客户端永远不要尝试与集群总线端口通信，而应始终与正常的 Redis 命令端口通信，但请确保'''在防火墙中打开这两个端口'''，否则 Redis 集群节点将无法通信。

请注意，要使 Redis 集群正常工作，您需要为每个节点：
# 用于与客户端通信的普通客户端通信端口（通常为6379）将向需要到达群集的所有客户端以及所有其他群集节点（使用客户端端口进行密钥迁移）开放。
# 集群总线端口必须可以从所有其他群集节点访问。
* 如果您不同时打开两个 TCP 端口，您的集群将无法按预期工作。

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

=== Redis集群和 Docker ===
目前，Redis Cluster 不支持 NATED 环境，也不支持 IP 地址或 TCP 端口重新映射的一般环境。

Docker 使用了一种称为'''端口映射'''的技术：运行在 Docker 容器中的程序可能会使用不同的端口公开，而该端口与程序认为正在使用的端口不同。这对于在同一服务器上同时使用相同端口运行多个容器非常有用。

为了使 Docker 与 Redis 群集兼容，您需要使用 Docker 的'''主机网络模式'''。
* 有关更多信息，请查看 Docker 文档中的“--net=host”选项。

=== Redis集群：数据分片 ===
Redis Cluster 不使用[[http://wiki.eijux.com/%E5%85%B3%E4%BA%8E%EF%BC%9A%E4%B8%80%E8%87%B4%E6%80%A7%E5%93%88%E5%B8%8C%E7%AE%97%E6%B3%95 一致哈希（consistency hashing）]]，而是一种不同形式的分片，其中每个键在概念上都是我们所称的'''散列槽'''的一部分。

Redis 集群中有 '''16384'''（2 ^ 14）个哈希槽，使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。

Redis 集群中的'''每个节点负责哈希槽的子集'''。
: 因此，例如，您可能有一个包含3个节点的集群，其中：
:# 节点 A 包含从 0 到 5500 的哈希槽。
:# 节点 B 包含从 5501 到 11000 的哈希槽。
:# 节点 C 包含从 11001 到 16383 的哈希槽。

这允许在集群中轻松地添加和删除节点。
: 例如，如果我想添加一个新节点 D，我需要将一些哈希槽从节点 A、B、C 移动到 D。类似地，如果我想从集群中删除节点 A，我可以只将由 A 提供服务的哈希槽移动到 B 和 C。当节点 A 为空时，我可以将其完全从集群中删除。
* 由于将哈希槽从一个节点移动到另一个节点不需要停止操作，因此添加和删除节点，或更改节点持有的哈希槽的百分比，不需要任何停机时间。

'''Redis Cluster 支持多个键操作，只要单个命令执行'''（或整个事务，或 Lua 脚本执行）'''中涉及的所有键都属于同一个哈希槽'''。

用户可以使用名为'''哈希标记（hash tags）'''的概念强制多个键成为同一哈希槽的一部分。

哈希标记记录在 Redis 集群规范中，其要点：如果在一个键的“'''{}'''”括号之间有一个子字符串，则'''只对字符串括号“{}”内的内容进行哈希处理'''。
: 例如“''this{foo}key''”和“''another{foo}key''”保证位于同一个哈希槽中，并且可以在具有多个键作为参数的命令中一起使用。

=== Redis集群：主从模型 ===
为了在主节点子集出现故障或无法与大多数节点通信时保持可用，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 群集将无法继续运行。

=== Redis集群：一致性保证 ===
'''Redis Cluster 无法保证强一致性（strong consistency）'''。实际上，这意味着在某些情况下，Redis Cluster 可能会丢失系统已向客户端确认的写入。

Redis Cluster 会丢失写入的第一个原因是因为它使用'''异步复制'''。

: 这意味着在写入期间会发生以下情况：
:# 您的客户端写入主 B。
:# 主 B 向您的客户端回复 OK。
:# 主 B 将写入传播到其副本 B1、B2 和 B3。
: 如您所见，B 在回复客户端之前不会等待来自 B1、B2、B3 的确认，因为这对 Redis 来说是一个令人望而却步的延迟惩罚，因此如果您的客户端写入某些内容，B 会确认写入，但如果在将写入发送到其副本之前崩溃，其中一个副本（未收到写入）可以提升为主，那么写入的内容将永远丢失。

这与大多数配置为“每秒将数据刷新到磁盘”的数据库发生的情况非常相似

您可以通过强制数据库在回复客户端之前将数据刷新到磁盘来提高一致性，但这通常会导致效率过低。在 Redis Cluster 的情况下，这相当于同步复制。

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

Redis 集群在绝对需要时支持同步写入，通过 '''WAIT''' 命令实现。这使得丢失写入的可能性大大降低。但是，请注意，即使使用同步复制，Redis Cluster 也没有实现强一致性：在更复杂的故障场景下，始终有可能将无法接收写入的副本选为 master。

还有一个值得注意的场景是 Redis 集群将丢失写入，这发生在'''网络分裂'''期间，客户端与少数实例（至少包括一个主实例）隔离。

: 以我们的 6 个节点集群为例，它由 A、B、C、A1、B1、C1 组成，有 3 个主节点和 3 个副本节点。还有一个客户端，我们将其称为 Z1。
: 分区发生后，可能在分区的一侧有 A、C、A1、B1、C1，而在另一侧有 B 和 Z1。
: Z1 仍然能够写入 B，B 将接受其写入。如果分区在很短的时间内恢复，集群将继续正常运行。但是，如果分区持续足够的时间让 B1 在分区的多数侧提升为 master，则 Z1 同时发送给 B 的写入将丢失。
:* 请注意，Z1 能够发送到 B 的写入量有一个最大窗口：如果分区的多数侧已经有足够的时间来选举一个副本作为主节点，则少数侧的每个主节点都将停止接受写入。

这个时间量是 Redis Cluster 的一个非常重要的配置指令，称为'''节点超时'''。
: 节点超时后，主节点被视为发生故障，并且可以由其副本之一替换。类似地，在节点超时后，主节点无法感知大多数其他主节点，它会进入错误状态并停止接受写入。

== Redis集群配置参数 ==

Redis：集群教程 - 版本历史

Eijux：​/* Redis集群：数据分片 */

Eijux：​/* 升级群集中的节点 */

Eijux：​/* 副本迁移 */

Eijux：​/* 测试故障转移 */

Eijux：​/* Redis集群：一致性保证 */

Eijux：​/* 测试故障转移 */

Eijux：​/* 创建并使用Redis群集 */

Eijux：​/* Redis集群配置参数 */

Eijux：​建立内容为“category:Redis == 关于 == 参考：[https://redis.io/topics/cluster-tutorial https://redis.io/topics/cluster-tutorial] 以下包含了有关如何设…”的新页面

Eijux：/* Redis集群：数据分片 */

Eijux：/* 升级群集中的节点 */

Eijux：/* 副本迁移 */

Eijux：/* 测试故障转移 */

Eijux：/* Redis集群：一致性保证 */

Eijux：/* 测试故障转移 */

Eijux：/* 创建并使用Redis群集 */

Eijux：/* Redis集群配置参数 */

Eijux：建立内容为“category:Redis == 关于 == 参考：[https://redis.io/topics/cluster-tutorial https://redis.io/topics/cluster-tutorial] 以下包含了有关如何设…”的新页面