开发者无需操心
Redis Enterprise Proxy 的核心原则
在 Redis 企业版集群的幕后，发生了许多复杂的操作。而 Proxy 则屏蔽了所有这些活动，让数据库客户端无需感知。
大多数开发者在构建应用时都会从小规模开始，通常会选择简单的 Redis 开源版（Redis OSS）数据库，即使他们知道未来软件会成为更复杂系统的一部分。起初，使用数据库非常简单：应用连接到一个端点，并开始发送请求，仅此而已。
真正的挑战出现在应用需要扩展和高可用性时。为此，可以使用 Redis OSS Cluster 和 Redis Sentinel。但这样一来，开发者就需要维护数据库拓扑结构，并处理扩展的具体实现——换句话说，需要编写更多代码。在企业级应用中，这种复杂性会迅速升级。
Redis 企业版通过消除额外的工作，解决了这些复杂性问题。无论是直接采用企业级解决方案，还是从 Redis OSS 迁移而来，我们的设计都确保了其能够在大规模场景下高效运行，同时让应用使用数据库依然保持简单。
无感代理，高效扩展
Proxy 是 Redis 企业版一个几乎无延迟的组件，它在应用与数据库之间充当中介。它向数据库客户端暴露数据库端点，同时屏蔽 Redis 企业版集群在后台执行的各种操作。这让开发者可以专注于数据的使用，而无需担心数据库拓扑的频繁变化。
该代理采用多线程架构，可以通过利用更多可用的 CPU 核心来轻松扩展。它利用多路复用（multiplexing）和流水线（pipelining）机制来处理高并发流量。当数千个客户端同时连接到 Redis 企业版时，代理会将所有传入请求整合到一组内部流水线中，并将它们分发到相应的数据库分片。最终，这种方式能够大幅提升请求处理速度，实现高吞吐量和低延迟。
图 1：Redis Enterprise Proxy 作为应用与数据库之间的中介
常见场景分析
那么，这些技术在实际操作中意味着什么呢？让我们来看几个常见的集群级别场景，这些场景会导致拓扑结构发生变化。我们将展示这些变化如何在 Redis Enterprise Proxy 的背后保持透明，始终向用户暴露相同的数据库端点。从开发者的角度来看——也就是你，意味着更少的编码工作和从 Redis OSS 到 Redis 企业版的平滑迁移。
扩展
当数据库分片达到预定大小时，Redis 企业版可以进行扩展。扩展通过启动新的 Redis 实例，并将原始分片的一半哈希槽移至新分片来实现。这使得数据库的吞吐量和性能线性增长。
在 Redis 企业版中，扩展数据库有两种方式：
- 横向扩展（Scaling up）：在不添加节点到集群的情况下增加分片。当集群有足够的容量（内存和 CPU）时，可以进行这种扩展。
纵向扩展（Scaling out）：在创建新的分片之前，先向 Redis 企业版集群添加一个或多个新节点。这发生在集群的现有物理资源不足以支撑数据库扩展时。
横向扩展
下图显示了一个单分片数据库扩展为双分片数据库的示例。在左侧（扩展前），可以看到一个包含单一分片的节点。右侧（扩展完成后），数据库已重新分片，现在 Shard 1 和 Shard 2 位于同一个节点，每个分片持有一半的哈希槽。
横向扩展是否会改变客户端连接数据库的方式？不会。客户端仍然连接到相同的数据库端点，代理负责将每个请求转发到相应的分片。值得注意的是，这与 Redis OSS 集群不同，在 Redis OSS 中，客户端需要分别连接到每个分片，并且必须了解集群拓扑结构。
图 2：在 Redis 企业版中扩展数据库。客户端继续使用相同的数据库端点
纵向扩展
与横向扩展不同，在使用多代理（multi-proxy）策略进行纵向扩展时，多个代理会在同一个端点后运行。（需要注意的是，在 Redis 企业版中，也可以使用 OSS Cluster API 进行纵向扩展。但在这种情况下，每个代理都会拥有自己的端点。）
下图展示了一个数据库从双分片扩展为四分片的过程。在左侧（扩展前），一个新的节点被添加到集群中，其中包含一个尚未激活的代理。在扩展完成后，Shard 1 和 Shard 2 仍位于 Node 1，而 Shard 3 和 Shard 4 则分配到 Node 2，并且两个节点都运行了活跃的代理。
然而，纵向扩展不会改变客户端的连接方式，因为这些变化对客户端是透明的。客户端依旧使用相同的数据库端点，代理会自动将请求转发到正确的分片进行处理。
图 3：使用多代理策略进行纵向扩展，客户端继续使用相同的数据库端点
自动故障转移
Redis 企业版具备自动故障转移机制，基于数据复制确保高可用性。当集群检测到故障（如数据库分片宕机或整个节点失效），它可以在几秒内完成自我修复。
这个修复过程由集群管理器负责，通常涉及数据库拓扑的调整。代理会收到通知，并自动适配新的拓扑结构，但对客户端来说，一切保持不变，它们仍然连接到同一个数据库端点。
以下是两种典型的故障转移场景：
主分片故障转移
在下图左侧，Node 1 运行主分片，Node 2 运行其副本。代理会将所有请求发送到主分片，而主分片会持续同步数据到副本。
如果主分片发生故障，Redis 企业版集群管理器会自动将副本分片提升为新的主分片，代理随之调整，所有客户端请求都会被重定向到新的主分片。最后，系统会在另一台健康的节点上创建新的副本分片，以恢复数据冗余。
图 4：主分片的自动故障转移
节点故障转移
如果整个 Node 1 宕机，不仅主分片失效，代理也会随之失去连接，导致数据库客户端短暂断开。一旦 Redis 企业版完成故障转移，客户端仍然可以使用相同的数据库端点 重新连接，继续正常运行。对于开发者和运维人员而言，无需做任何额外调整，因为集群故障转移机制会自动将相同的端点指向新的代理。
下图展示了 Node 1 失效时的故障转移过程。Node 2 的代理被激活，Redis 企业版将副本分片提升为主分片。数据库恢复可用，客户端无需感知拓扑变化即可重新连接。集群管理器同时在 Node 3 创建新的副本分片。
图 5：自动节点故障转移，客户端仍连接相同的数据库端点。
毫秒级响应，Redis 企业版速度实测
Redis Enterprise Proxy 大大简化了数据库客户端的使用，但它的响应速度如何？让我们来看一些基准测试数据。
为了测试延迟，我们使用了一个单端点的 Redis Enterprise Cloud 集群，并执行了一个常见的场景，其中包含 20% 的 SET（写入）命令和 80% 的 GET（读取）命令。
测试中，我们创建了一个 5GB 内存限制的数据库，并设定了五个吞吐目标：50K、100K、200K、400K 和 800K 次操作/秒（ops/sec）。Redis Enterprise Cloud 会自动选择合适的云实例，以确保集群在尽可能低的成本下拥有足够的资源。
测试结果显示，Redis Enterprise 的响应速度极快。在所有目标吞吐量下，中位（p50）延迟均维持在毫秒级以内，某些情况下，99 分位（p99）延迟也能达到毫秒级以下。
下图展示了对等复制的运行机制：
图 6：p50 延迟基准测试结果
Redis企业版
将更多设想变为现实
