大多数开发人员在构建应用程序时，一般会从小规模开始，使用简单的 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 会收到通知，并根据新的拓扑结构进行调整。
而从数据库客户端的角度来看，没有任何变化。客户端将继续使用与以前相同的数据库端点，因为拓扑变化是隐藏在代理之后的内部变化。
下面我们来看两个故障转移示例
- 主分片故障转移
下面是个关于主分片故障转移的例子。
图 4：主分片自动故障转移
图 4 左侧的主分片位于节点 1，其副本位于节点 2。Proxy 会将所有客户端请求发送到主分片，主分片会时刻与其副本同步数据变化。如果出了问题怎么办？
如果主分片发生故障，Redis Enterprise 集群管理器会将副本分片升级为主分片。Proxy 现在会将接收到的请求重定向到新的主分片，让客户端照常运行。最后一步是创建新的副本分片（如图 4 右侧所示）。
- 节点故障转移
在本例中，整个节点发生故障，包括主分片和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延迟（50%的延迟）保持在亚毫秒级。在某些情况下，它的p99 延迟（99%的延迟）能达到亚毫秒级。
