在不使用集群的情况下扩展 Redis

Redis 是一种流行的内存数据存储，以其速度和灵活性而闻名。当特定工作负载的内存和计算需求可以在单个节点内管理时，它就能高效运行。然而，超出单个节点的扩展通常会导致考虑 Redis 集群。人们普遍认为过渡到 Redis 集群很简单，现有应用程序的行为也将相同，但实际情况并非如此。虽然 Redis 集群解决了某些扩展问题，但它也带来了巨大的复杂性。本文将讨论 Redis 集群扩展的局限性，并介绍一些可以满足许多组织需求的更简单的替代方案。

什么是Redis集群？

Redis Cluster 是一种分布式实现，允许您自动在多个主 Redis 实例之间共享数据，从而实现水平扩展。在 Redis 集群设置中，键空间被分为 16384 个哈希槽（了解更多 此处），有效设置 16384 个主实例的集群大小上限。然而，实际上，建议的最大大小约为 1000 个主实例。集群中的每个主实例管理这 16,384 个哈希槽的特定子集。为了确保高可用性，每个主实例可以与一个或多个副本实例配对。这种方法涉及跨多个实例的数据分片以实现可扩展性和复制以实现冗余，是许多分布式数据存储系统中的常见模式。一个具有三个主 Redis 实例的集群，每个主实例有一个副本，如下所示：

<图>

如您所见，Redis Cluster 具有优雅的设计。但在没有深入研究实现细节的情况下，我们已经介绍了多个概念（分片、哈希槽等），只是为了有一个基本的了解。我们将在下面探讨更多挑战。

<小时/>

水平扩展的挑战

虽然 Redis 集群通常被认为只是独立 Redis 上的一个设置，但它在很多方面都有所不同。这意味着迁移到 Redis 集群充满了隐藏的挑战，即使是经验丰富的开发人员也会感到惊讶。

客户端库要求

从客户端库的角度来看，使用 Redis Cluster 需要适应不同的接口。这意味着您很可能需要使用特定于集群的客户端库 – 用于独立 Redis 的现有客户端将无法在集群中开箱即用。我们以 go-redis Redis 为例就是一个例子。当连接到独立的Redis时，可以使用以下代码片段连接到具有指定主机、密码和逻辑数据库的实例：

导入“github.com/redis/go-redis/v9”

rdb := redis.NewClient(&redis.Options{
    地址：“本地主机：6379”，
    密码: "", // 未设置密码
    DB: 0, // 使用默认逻辑数据库0（稍后详细介绍）
})

同一个包提供了特定于集群的客户端，但需要注意的是，它们是不同的结构：用于独立 Redis 的 redis.Client 和用于 Redis 的 redis.ClusterClient簇。 redis.ClusterClient 的初始化过程有所不同，如下所示。这种区别至关重要，因为 redis.ClusterClient 在内部利用多个 redis.Client 对象来管理与集群中所有节点的通信。此设置中的每个 redis.Client 维护其单独的连接池。

导入“github.com/redis/go-redis/v9”

rdb := redis.NewClusterClient(&redis.ClusterOptions{
    地址：[]字符串{
        “本地主机：7001”，
        “本地主机：7002”，
        “本地主机：7003”，
        “本地主机：7004”，
        “本地主机：7005”，
    },
})

附带说明一下，go-redis 包还提供了 redis.UniversalClient 接口来简化初始化过程，但它只是不同之上的抽象层客户类型。要使用 Redis 集群，需要开发如上所述的特定于集群的客户端来满足集群的其他要求。

多键操作

Redis 中的多键操作是指同时作用于多个键的命令或命令集。例如， MSET 命令是一个单个命令可以在单个原子操作中将多个键设置为多个值。类似地，事务或 Lua 脚本通常涉及多个键，但并非总是如此。 Redis 集群的一个关键限制是它无法处理多键操作，除非所涉及的键共享相同的主题标签，如规范 此处。您需要仔细检查应用程序中的所有多键操作，并且需要修改这些操作以避免使用多键操作或仅在同一主题标签的上下文中使用它们。

逻辑数据库

在 Redis 中，逻辑数据库本质上是同一 Redis 实例中的单独键空间。 Redis 支持多个数据库，这些数据库由数据库索引（一个简单的整数）来标识。除非另有说明，Redis 客户端在连接时通常使用默认数据库数据库0。利用逻辑数据库可以是分离不同类型数据的有效策略（例如，将会话数据与应用程序数据隔离）。可以使用SELECT命令进行切换不同逻辑数据库之间。但是，正如 SELECT 命令文档中所指定的那样，您将失去 Redis 集群的这种隔离性。因此，如果您要过渡到 Redis 集群，则需要从头开始彻底重新构建键空间架构。

设置和维护的复杂性

上面我们讨论的只是应用层面。然而，集群的影响延伸到基础设施的复杂性和运营成本。

首先，启用 Redis 集群会大大增加基础设施的复杂性以及管理基础设施的团队的运营负担。您不需要在单个 Redis 实例上监控指标和可用性，而是需要在数十个或数百个节点上进行监控。

其次，工作负载应在集群中均匀分布，同时最大限度地减少特定实例中的热点。但实际上，这种情况并不经常发生。一个常见的误解是创建集群会自动导致所有分片之间的流量统一。然而，特定的时段几乎总是能比其他时段获得更多的流量。虽然 Redis 允许您对实例进行重新分片，但它没有自动重新平衡功能。

最后但并非最不重要的一点是，实例越多，潜在的故障点就越多。虽然集群在节点出现故障时提供故障转移功能，但成倍增加的风险是真实存在的。我们假设任何单个 Redis 实例发生故障的可能性为 0.01%。在 100 次情况下，这种可能性会上升到 1-2%，这意味着更多的事故、消防演习以及可能的不眠之夜。

<小时/>

Redis 集群替代方案

鉴于 Redis 集群面临的挑战，值得考虑可以提供更简单的 Redis 扩展路径的替代方案。

应用级优化

调整应用程序对 Redis 的访问模式可以显着减少工作数据大小。通过对键、数据结构和查询进行小幅调整，您可以从现有的 Redis 部署中获得更多收益。例如，在 Abnormal Security，他们将 64 个字符的密钥字符串缩短为 32 个字符。这减少了每个键的内存占用，使它们能够容纳多 15% 的键值对。然而，应用程序级优化并不总是可行的。深入研究优化过程后，有时会感觉您是在满足数据存储的需求，而不是利用它来支持您的业务目标。

内存有限的工作负载

如果吞吐量不是问题，并且您只需要更多内存，最简单的解决方案是升级到更高内存的实例。当然，这意味着这个更强大的实例附带的额外 CPU 将处于闲置状态，不会加入其中。有时为它们付费很烦人，但至少你没有为全球变暖做出贡献。

但是，由于 Redis 是单线程的，如果您的工作负载受 CPU 限制（例如，涉及大量解析和修改 JSON 数据），那么仅仅添加更多 CPU 可能没有帮助。

数据分层到 SSD/闪存

Flash 上的 Redis< /a> 也称为数据分层，在 Redis 开源版本中不可用，是 Redis 托管解决方案中相对较新的功能。数据分层允许将 Redis 数据集中不经常访问的部分移动到附加到实例的 SSD 存储层。这为工作数据集提供了显着更多的内存容量（在某些云平台上，内存和 SSD 存储组合高达 2TB），同时将热数据集保留在低延迟主内存中。