虹科干货 | 虹科Redis企业版数据库的延迟如此之小，proxy功不可没！

在Redis企业版集群的后台发生了许多事件，proxy（代理）隐藏了数据库客户端的所有活动。

大多数开发人员在构建应用程序时都会从小规模开始，使用简单的Redis开源（Redis OSS）数据库。在初期阶段，使用数据库非常直接，只需连接到单一的端点并发送请求。

然而，当Redis应用程序的需求变得更加复杂时，例如扩展和高可用性，挑战就开始了。开发人员可以使用Redis OSS Cluster和Redis Sentinel来实现这些目标。但是这需要开发人员维护数据库拓扑结构并处理扩展的实际问题。换句话说，他们必须编写更多的代码，而在企业级环境中，代码可能会迅速变得更加复杂。

虹科Redis企业版数据库软件（简称虹科Redis企业版）通过消除这些复杂性问题来解决这个挑战。无论是从企业级环境开始还是从Redis OSS迁移而来，Redis企业版数据库的设计都在大规模环境下表现得很出色，同时能够保持应用程序对数据库的简单使用。

本文介绍了Redis企业版代理，并展示了该代理在常见Redis集群场景中如何减轻拓扑结构变化的影响。在文章最后，我们还会分享证明代理效率的基准数据。

虹科Redis企业版软件（Redis Enterprise）是企业级的数据库软件，也是一款实时数据平台，为全球超过8500家知名企业提供实时数据服务。具有线性可扩展性、高可用性、持久性、备份和恢复、地理分布、分层内存访问、多租户、安全性等8大核心功能、拥有RediSearch、RedisJSON等7大【Redis企业版特有模块】，可以任何规模在云、本地和混合部署中运行现代应用程序，提供无服务器、多模型的数据库解决方案。Redis企业版的核心优势是采用Redis on flash分层存储技术即【内存+闪存+磁盘】的存储方式，其Active-Active地理分布式架构允许跨地理位置同时进行数据读写操作、拥有亚毫秒延迟和极高吞吐量。

什么是虹科Redis企业版Proxy？

虹科Redis企业版Proxy（代理）是一个几乎无延迟的实体，它在应用程序和数据库之间进行调解。它向数据库客户端公开数据库端点，同时屏蔽Redis企业版集群执行的后台活动。这使开发人员可以专注于应用程序如何使用数据，而不用担心数据库拓扑的频繁变化。

虹科Redis企业版软件（RS）通过代理进程提供高性能数据访问，该代理进程管理和优化对 RS集群内分片的访问。每个节点都包含一个代理进程。每个代理都可以是主动的并接收传入流量，也可以是被动的并等待故障转移。

虹科Redis企业版Proxy（代理）采用多线程架构，可以通过使用更多可用内核轻松扩展，并使用多路复用和流水线处理高流量。当成千上万的客户端同时连接到虹科Redis企业版时，代理会将所有传入请求整合到一组内部管道中，并将它们分发到相关的数据库分片。最终产生的结果：请求处理速度更快，允许高吞吐量和低延迟。

这在实践中意味着什么呢？接下来我们就来看一下导致拓扑结构变化的几个常见集群级场景。我们将展示这种变化是如何隐藏在代理后面的，它与之前一样保持向用户暴露相同的数据库端点。从开发者的角度来看，这意味着更少的编码和从Redis开源版（Redis OSS）到Redis企业版的顺利迁移。

虹科Redis企业版的线性扩展

只要数据库分片达到某个（预定义的）大小时，虹科Redis企业版就可以对其进行扩展。扩展是通过启动一个新的Redis实例并将一半的哈希槽从原始分片移动到新分片来完成的。这使得数据库的吞吐量和性能线性增加。

在虹科Redis企业版中扩展数据库有两种方法：

l 纵向扩展：在不向集群添加节点的情况下向数据库添加分片。当集群有足够的容量（内存和CPU）来添加分片时，就会发生这种情况。

l 横向扩展：在创建新分片之前向虹科Redis企业版集群添加一个（或多个）新节点。当集群的现有物理资源不足以扩展数据库时，就会发生这种情况。

1.纵向扩展

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

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

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

图2：在虹科Redis企业版中扩展数据库，客户端继续使用相同的数据库端点

2.横向扩展

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

（请注意，使用虹科Redis企业版，您还可以在使用OSS Cluster API的同时扩展数据库。在这种情况下，每个代理都有自己的端点。）

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

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

虹科Redis企业版的自动故障转移

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

修复过程由集群管理器执行，通常需要在集群内部更改数据库拓扑。根据新的拓扑结构通知和调整代理。从数据库客户端的角度看，没有任何变化。客户端继续使用与以前相同的数据库端点，因为拓扑更改是内部的并且隐藏在代理之后。

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

1.主分片故障转移示例

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

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

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

2.节点故障转移示例

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

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

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

图5：自动节点故障转移，其中客户端重新连接到同一数据库端点

虹科Redis企业版的基准测试

代理无疑为数据库客户端简化了很多操作。但它发生的速度有多快？为了检查其效率，让我们来看一些基准数据。

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

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

以下结果证明了虹科Redis企业版的速度有多快。该基准保持所有目标吞吐量的亚毫秒中值(p50)延迟。在某些情况下，它可以达到亚毫秒级的p99延迟！

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

Redis相信简单的力量，这也是为什么Redis企业版是从Redis OSS迁移到企业级时的最佳选择！

关注我们，点击收藏转发在看！虹科是Redis企业版数据库的中国区战略合作伙伴。我们持续关注各行业当下急切需求，专注于为企业解答疑问，制定专属服务，提供一站式数据库和商业智能解决方案。

在Redis企业版集群的后台发生了许多事件，proxy（代理）隐藏了数据库客户端的所有活动。

大多数开发人员在构建应用程序时都会从小规模开始，使用简单的Redis开源（Redis OSS）数据库。在初期阶段，使用数据库非常直接，只需连接到单一的端点并发送请求。

然而，当Redis应用程序的需求变得更加复杂时，例如扩展和高可用性，挑战就开始了。开发人员可以使用Redis OSS Cluster和Redis Sentinel来实现这些目标。但是这需要开发人员维护数据库拓扑结构并处理扩展的实际问题。换句话说，他们必须编写更多的代码，而在企业级环境中，代码可能会迅速变得更加复杂。

虹科Redis企业版数据库软件（简称虹科Redis企业版）通过消除这些复杂性问题来解决这个挑战。无论是从企业级环境开始还是从Redis OSS迁移而来，Redis企业版数据库的设计都在大规模环境下表现得很出色，同时能够保持应用程序对数据库的简单使用。

本文介绍了Redis企业版代理，并展示了该代理在常见Redis集群场景中如何减轻拓扑结构变化的影响。在文章最后，我们还会分享证明代理效率的基准数据。

虹科Redis企业版软件（Redis Enterprise）是企业级的数据库软件，也是一款实时数据平台，为全球超过8500家知名企业提供实时数据服务。具有线性可扩展性、高可用性、持久性、备份和恢复、地理分布、分层内存访问、多租户、安全性等8大核心功能、拥有RediSearch、RedisJSON等7大【Redis企业版特有模块】，可以任何规模在云、本地和混合部署中运行现代应用程序，提供无服务器、多模型的数据库解决方案。Redis企业版的核心优势是采用Redis on flash分层存储技术即【内存+闪存+磁盘】的存储方式，其Active-Active地理分布式架构允许跨地理位置同时进行数据读写操作、拥有亚毫秒延迟和极高吞吐量。

什么是虹科Redis企业版Proxy？

虹科Redis企业版Proxy（代理）是一个几乎无延迟的实体，它在应用程序和数据库之间进行调解。它向数据库客户端公开数据库端点，同时屏蔽Redis企业版集群执行的后台活动。这使开发人员可以专注于应用程序如何使用数据，而不用担心数据库拓扑的频繁变化。

虹科Redis企业版软件（RS）通过代理进程提供高性能数据访问，该代理进程管理和优化对 RS集群内分片的访问。每个节点都包含一个代理进程。每个代理都可以是主动的并接收传入流量，也可以是被动的并等待故障转移。

虹科Redis企业版Proxy（代理）采用多线程架构，可以通过使用更多可用内核轻松扩展，并使用多路复用和流水线处理高流量。当成千上万的客户端同时连接到虹科Redis企业版时，代理会将所有传入请求整合到一组内部管道中，并将它们分发到相关的数据库分片。最终产生的结果：请求处理速度更快，允许高吞吐量和低延迟。

图1：虹科Redis企业版代理在应用程序和数据库之间充当中介

这在实践中意味着什么呢？接下来我们就来看一下导致拓扑结构变化的几个常见集群级场景。我们将展示这种变化是如何隐藏在代理后面的，它与之前一样保持向用户暴露相同的数据库端点。从开发者的角度来看，这意味着更少的编码和从Redis开源版（Redis OSS）到Redis企业版的顺利迁移。

虹科Redis企业版的线性扩展

只要数据库分片达到某个（预定义的）大小时，虹科Redis企业版就可以对其进行扩展。扩展是通过启动一个新的Redis实例并将一半的哈希槽从原始分片移动到新分片来完成的。这使得数据库的吞吐量和性能线性增加。

在虹科Redis企业版中扩展数据库有两种方法：

l 纵向扩展：在不向集群添加节点的情况下向数据库添加分片。当集群有足够的容量（内存和CPU）来添加分片时，就会发生这种情况。

l 横向扩展：在创建新分片之前向虹科Redis企业版集群添加一个（或多个）新节点。当集群的现有物理资源不足以扩展数据库时，就会发生这种情况。

1.纵向扩展

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

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

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

图2：在虹科Redis企业版中扩展数据库，客户端继续使用相同的数据库端点

2.横向扩展

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

（请注意，使用虹科Redis企业版，您还可以在使用OSS Cluster API的同时扩展数据库。在这种情况下，每个代理都有自己的端点。）

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

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

图3：使用多代理策略横向扩展数据库，客户端继续使用相同的数据库端点

虹科Redis企业版的自动故障转移

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

修复过程由集群管理器执行，通常需要在集群内部更改数据库拓扑。根据新的拓扑结构通知和调整代理。从数据库客户端的角度看，没有任何变化。客户端继续使用与以前相同的数据库端点，因为拓扑更改是内部的并且隐藏在代理之后。

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

1.主分片故障转移示例

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

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

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

2.节点故障转移示例

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

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

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

图5：自动节点故障转移，其中客户端重新连接到同一数据库端点

虹科Redis企业版的基准测试

代理无疑为数据库客户端简化了很多操作。但它发生的速度有多快？为了检查其效率，让我们来看一些基准数据。

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

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

以下结果证明了虹科Redis企业版的速度有多快。该基准保持所有目标吞吐量的亚毫秒中值(p50)延迟。在某些情况下，它可以达到亚毫秒级的p99延迟！

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