Redis 企业代理的第一条规则：开发者不需要了解 Redis 企业代理

Redis 企业集群幕后发生了很多事情。代理会将所有这些活动屏蔽在数据库客户端之外。

大多数开发者在构建应用程序时会从小处着手，使用简单的 Redis 开源 (Redis OSS) 数据库，即使他们知道该软件将成为复杂系统的一部分。在开始阶段，使用数据库非常简单。它只有一个端点，应用程序连接到该端点并开始发送请求。仅此而已。

当 Redis 应用程序需要更多功能，例如扩展和高可用性时，挑战就开始了。您可以为此目的使用Redis OSS 集群和Redis 哨兵。但是，它要求开发者维护数据库拓扑并处理扩展的实际问题。换句话说，您必须编写更多代码。在企业级，这会很快变得复杂。

Redis 企业通过消除额外工作来解决这些复杂性问题。无论您是从企业级开始还是从 Redis OSS 迁移，我们都设计它在大型规模上脱颖而出，同时保持对应用程序使用数据库的简单性。

在本文中，我们重点介绍 Redis 企业代理。我们展示了常见的 Redis 集群场景示例，演示了代理如何缓解拓扑更改。最后，我们分享了展示代理效率的基准测试数据。

代理是谁？

Redis 企业代理是一个具有可忽略的延迟的实体，它在应用程序和数据库之间充当媒介。它将数据库端点暴露给数据库客户端，同时掩盖 Redis 企业集群执行的幕后活动。这允许开发者专注于应用程序如何使用数据，而不是担心数据库拓扑的频繁更改。

代理采用多线程架构。它可以通过使用更多可用的核心轻松扩展。它旨在通过使用多路复用和管道来应对高流量。当数千个客户端同时连接到 Redis 企业时，代理会将所有传入的请求合并成一组内部管道，并将它们分配到相关的数据库分片。最终结果：请求处理速度更快，允许以低延迟实现高吞吐量。

从实际意义上讲，这意味着什么？让我们看一下几个常见的集群级场景，这些场景会导致拓扑更改。我们展示了这些更改如何在代理后面隐藏起来，代理会继续像以前一样向用户暴露相同的数据库端点。从开发者的角度（您的角度）来看，这意味着更少的编码和从 Redis OSS 到 Redis 企业的平滑迁移。

每当数据库分片达到某个（预定义的）大小，Redis 企业就可以扩展它。扩展是通过启动一个新的 Redis 实例并将一半的哈希槽从原始分片移动到新分片来完成的。这允许数据库的吞吐量和性能线性增长。

在 Redis 企业中扩展数据库有两种方法

图 2 显示了将单个分片数据库–向上扩展到两个分片数据库的示例。在左侧（扩展之前），您可以看到包含单个分片的单个节点。在右侧（扩展完成后），数据库被重新分片。现在分片 1 和分片 2 位于同一个节点中，每个节点都包含一半的哈希槽。

向上扩展是否会改变客户端连接到数据库的方式？不会。客户端继续像以前一样向相同的数据库端点发送请求，让代理负责将每个请求转发到相应的分片。

请注意，这与 Redis OSS 集群不同，在 Redis OSS 集群中，客户端单独连接到每个分片，因此必须了解集群拓扑。

相反，考虑在使用多代理策略时扩展数据库会发生什么。在这种情况下，我们在同一个端点后面运行多个代理。

（请注意，使用 Redis 企业，您也可以在使用OSS 集群 API时扩展数据库。但是，在这种情况下，每个代理都有自己的端点。）

图 3 显示了将两个分片数据库横向扩展到四个分片数据库的示例。在左侧添加了一个新的节点到集群中，其中包含一个尚未激活的代理。横向扩展完成后，分片 1 和分片 2 位于节点 1 中，分片 3 和分片 4 位于节点 2 中。现在两个节点都包含活动代理。

但是，横向扩展不会改变客户端连接到数据库的方式，因为所有这些更改对客户端都是透明的。数据库继续像以前一样向相同的数据库端点发送请求。处理每个请求的代理会将这些请求转发到相关分片。

Redis 企业高可用性的一个关键方面是自动故障转移，它依赖于数据复制。当在 Redis 企业集群中检测到故障时 - 无论是数据库分片中断还是整个节点故障 - 集群都设计为在几秒钟内自我修复。

修复过程由集群管理器执行，通常需要对集群内部的数据库拓扑进行更改。代理会收到通知并根据新的拓扑进行调整。

从数据库客户端的角度来看，没有任何变化。客户端继续使用以前相同的数据库端点，因为拓扑更改是内部的，并且隐藏在代理后面。

让我们看一下两个故障转移示例。

在图 4 的左侧，是节点 1 中的一个主分片，它的副本位于节点 2 中。代理会将所有客户端请求发送到主分片，主分片会不断将其数据更改与副本同步。到目前为止，一切都很好。但是当事情出错时会发生什么？

如果主分片发生故障，Redis 企业集群管理器会将副本分片提升为主分片。代理现在将传入的请求重定向到新的主分片，让客户端像往常一样继续。最后一步是创建一个新的副本分片（如图 4 的右侧所示）。

在此示例中，整个节点发生故障，包括主分片和代理。数据库客户端断开连接。

但是，一旦 Redis 企业集群管理器完成故障转移过程，客户端就会重新连接到以前相同的数据库端点，并像往常一样继续。从开发者和运维的角度来看，无需进行任何更改，因为集群故障转移机制将同一个端点分配给不同的代理。

图 5 说明了节点 1 发生故障时的过程。节点 2 的代理变为活动状态，Redis 企业将副本提升为主。数据库现在再次可用，因此客户端可以重新连接，而无需知道此拓扑更改。集群管理器还会找到一个健康的节点（节点 3），Redis 企业会在其中创建一个新的副本分片。

代理确实简化了数据库客户端的操作。但这发生得有多快？为了检查其效率，让我们看一下一些基准测试数据。

为了对延迟进行基准测试，我们使用了一个单端点 Redis 企业云集群。我们执行了一个包含 20% SET（写入）和 80% GET（读取）命令混合的常见场景。

我们创建了一个内存限制为 5GB 的数据库，并选择了五个吞吐量目标：每秒 50K、100K、200K、400K 和 800K 次操作 (ops/sec)。对于每种配置，Redis 企业云都会选择合适的云实例，确保集群在最小成本下拥有足够的资源。

以下结果展示了 Redis Enterprise 的速度之快。基准测试在所有目标吞吐量下保持亚毫秒的中位数 (p50) 延迟。在某些情况下，它可以实现亚毫秒的 p99 延迟。