随着业务拓展， 单点 redis 无法满足 越来越高的性能要求 ，但使用 Redis OSS Cluster和Redis Sentine l来解决起问题太过复杂。此时，就需要Redis Enterprise Proxy来保持 数据库操作和维护 的简便性。

大多数开发人员在构建应用程序时， 一般 会从小规模开始，使用简单的 Redis 开源（Redis OSS）数据库。一开始，数据库的使用非常简单 ， 它只有一个 节点 ，仅仅需要应用程序连接到该端点并开始发送请求。

而当 Redis 应用程序需要更多特性 时 ，如扩展和高可用性， 麻烦就来了 。 为此，可以使用Redis OSS Cluster和Redis Sentinel来解决这些问题。不过，这需要开发人员维护数据库 的 拓扑结构并处理实际的扩展问题。 换言之，你必须编写更多代码，而在企业 级应用中 ，这 将 很快 使应用 会变得更为复杂。

Redis Enterprise 借助 Proxy摆脱了这些额外的工作 ，从而解决 了 这些复杂性问题。 无论你是从 Enterprise 直接开始，还是从 Redis OSS 迁移而来，我们设计它的目的 就 是为了让应用程序在大规模 运行 时， 仍然保持 数据库操作和维护 的简便性 。

一、 Proxy 是什么?

Redis Enterprise Proxy 是应用程序与数据库之间的中介实体， 其延迟很低，甚至可以忽略不计 。 它只将 数据库端点 提供 给数据库客户端 ，   隐藏 Redis Enterprise 集群的 内部 活动。 这样，开发人员就可以专注于应用程序 的 数据 使用情况 ，而不必担心数据库拓扑结构的频繁变化。

Proxy 采用多线程架构，可以通过使用更多可用 CPU 内核轻松扩展。它通过使用多路复用和流水线设计来应对高流量。当成千上万的客户端同时连接到 Redis Enterprise 时，代理会将所有传入请求整合到一组内部管道中，并将它们分发到相关的数据库分片 ， 使得最终的请求处理速度大大加快， 同时 实现高吞吐量和低延迟。

 

图 1：Redis Enterprise 代理在应用程序和数据库之间进行调解

二、 常见 的集群级 情况

让我们来看看导致拓扑变化的几种常见集群级情况。我们将展示如何将这些变化隐藏在 Proxy 之后，使集群向客户端提供的数据库端点 不变 。   从开发人员的角度来看，这意味着减少 了 额外的编码，以及 可顺利 从 Redis OSS 迁移 到 Redis Enterprise。

1. 扩展

只要数据库分片达到一定（预定义）大小，Redis Enterprise 就能对其进行扩展。扩展是通过启动一个新的 Redis 实例，并将原始分区一半 的 哈希槽移动到新分区来实现的。这样，数据库的吞吐量和性能就会呈线性增长。

在 Redis Enterprise 中，有两种扩展数据库的方法：

·  纵向扩展 ：在不增加集群节点的情况下，向数据库添加分片。添加分片 需要 集群有足够的容量（内存和 CPU）。

·  横向扩展 ：在创建新分片之前，向 Redis Enterprise 集群添加一个（或多个）新节点。 常用在 集群的现有物理资源不足以扩展数据库时。

2. 纵向扩展

下面是一个关于纵向扩展的例子。

 

图 2：在 Redis Enterprise 中扩展数据库。客户端继续使用相同的数据库端点

图 2 显示了将单分片数据库扩展为双分片数据库的示例。在 图片 左侧（扩展前），可以看到包含单分片的单节点。在 图片 右侧（扩展完成后），数据库被重新分片。现在，分片 1 和分片 2 位于同一节点，各自拥有一半的哈希槽。

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

这与 Redis OSS 集群不同，在 Redis   OSS 中，客户端分别连接到每个分片，因此必须了解集群拓扑结构 才能完成扩展 。

3. 横向扩展

下面是一个关于横向扩展的例子。

 

图3：使用多Proxy策略时扩展数据库

相反，如果我们在使用多 Proxy 策略时扩展数据库，会发生什么情况呢？在这种情况下，我们有多个 Proxy 在同一个端点后面运行。

(在   Redis Enterprise 中，也可以通过使用 OSS Cluster API 的形式扩展数据库。 在这种情况下，每个 Proxy 都有自己的端点）

图 3 显示了将一个双分片数据库扩展到一个四分片数据库。左侧的集群中添加了一个新节点，其中包含一个仍处于非活动状态的 Proxy。扩展完成后，分片 1 和分片 2 位于节点 1，分片 3 和分片 4 位于节点 2。这两个节点现在都包含启用的 Proxy 。

横向扩展也不会改变客户端连接数据库的方式，因为这些变化对客户端来说都是 “ 透明 ” 的 ，客户端无需关心集群内部的变化 。数据库继续像以前一样向相同的数据库端点发送请求。处理每个请求的 Proxy 会将这些请求转发给相关的分片。

4. 自动故障转移

Redis Enterprise 实现 高可用性的一个关键 在于 自动故障转移，它依赖于数据复制。当检测到 Redis Enterprise 集群内出现故障时，无论是数据库分片中断还是整个节点失效，集群都能在几秒钟内 实现 自我修复。

修复过程由集群管理器执行，通常会改变集群内的数据库拓扑结构。Proxy 会收到通知，并根据新的拓扑结构进行调整。

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

 

下面我们来看两个故障转移示例

l  主分片故障转移

下面是个关于主分片故障转移的例子。

 

图 4：主分片自动故障转移

图 4 左侧的主分片位于节点 1，其副本位于节点 2。Proxy 会将所有客户端请求发送到主分片，主分片会 时刻 与其副本同步数据变化。如果出了问题怎么办？

如果主分片发生故障，Redis Enterprise 集群管理器会将副本分片升级为主分片。Proxy 现在会将接收到的请求重定向到新的主分 片 ，让客户端照常运行。最后一步是创建新的副本分片（如图 4 右侧所示）。

l  节点故障转移

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

不过，一旦 Redis Enterprise 集群管理器完成故障转移过程，客户端就会重新连接到与之前相同的数据库端点，并照常进行操作。从开发人员和操作的角度来看，无需做任何更改，因为群集故障转移机制会将相同的端点分配给不同的代理。

 

图 5：自动节点故障切换，客户端重新连接到相同的数据库端点

图 5 展示了节点 1 出现故障时的 故障转移 流程。节点 2 的代理变为启用状态，Redis Enterprise 将副本提升为主节点。数据库现在又可用了，因此客户可以重新连接，而不会察觉到拓扑结构的变化。集群管理器还会找到一个健康的节点（节点 3），Redis Enterprise 会在其中创建一个新的副本分片。

三、用数据说话， Proxy到底有多高效？

Proxy 无疑简化了数据库客户端的工作 ， 但其实现的速度有多快？为了检验它的效率，让我们来看看一些基准数据。

为了对延迟进行基准测试，我们使用了一个单端点 Redis Enterprise Cloud 集群。我们 设计 了一个包含 20% SET（写）和 80% GET（读）命令的常见场景。

我们创建了一个内存限制为 5GB 的数据库，并选择了五个吞吐量目标： 分别为每秒 50K、100K、200K、400K 和 800K 次操作（ops/sec）。对于每种配置，Redis Enterprise Cloud 都会选择合适的云实例来使用，确保集群以最小的成本获得足够的资源。

 

图 6：p50 延迟基准测试结果

图 6的 结果 展示 了 Redis Enterprise 有多快 。在所有目标吞吐量下，该基准 测试 都能 将 p50延迟 （ 5 0% 的延迟） 保持 在 亚毫秒级。在某些情况下，它 的 p99 延迟 （ 9 9% 的延迟） 能达到亚毫秒级。

目标吞吐量 (ops/sec)	客户端连接数	分片数	p50 每连接延迟(msec)	p99 每连接延迟(msec)
50,000	2000	2	0.182	0.317
100,000	2000	4	0.258	0.588
200,000	2000	8	0.325	1.184
400,000	2000	16	0.406	2.791
800,000	2000	32	0.398	2.907