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

Posted 2023-06-01 hongcloudtech

在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延迟！

目标吞吐量（操作/秒）	客户端连接数	分片数量	每个连接的p50延迟（毫秒）	每个连接的p99延迟（毫秒）
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

 

图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延迟！

目标吞吐量（操作/秒）	客户端连接数	分片数量	每个连接的p50延迟（毫秒）	每个连接的p99延迟（毫秒）
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

 

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

虹科案例 | 虹科高质量天线为旅游巴士提供可靠有效的车载WIFI连接

新品速递

虹科“Great White”MiMo汽车天线方案正式发布！

 

挑战

最近，The Original Tour更新了他们的标志性巴士的外观，也希望对其进行技术升级，以便在游览时为乘客提供免费WiFi，车载WiFi正在成为旅游巴士与城市公交的标准。虹科天线具有广泛的产品线，包括LTE和定向WiFi天线，简单而有效的为客户提供强大和稳定的网络连接。这对所有公交车运营商来说，这是一个重要的增值渠道。
 

我们的顾客

The Original Tour伦敦旅游是世界上第一种观光旅游形式，最早可以追溯到20世纪初，它于1951年正式成立，为来到伦敦参加节日的成千上万的游客提供 “半克朗的环城旅游”。旅游车从白金汉宫附近出发乘坐敞篷双层巴士游览伦敦，这是敞篷观光旅游的起始，今天在全世界所有主要旅游城市都可以看到这一形式的普及。The Original Tour每年仍然为成千上万的游客提供历史悠久的首都游览。
 

“HK-W24-58-CP-9能够提供出色的方向性覆盖，这表明它是一种极其有效的车载WiFi天线！”

 

产品介绍

HK-W24-58-CP-9紧凑定向面板天线

HK-W24-58-CP-9是一个覆盖2.4和5.0GHz WiFi/WLAN的定向墙面天线，各向同性的峰值增益为9dBi。该天线可以安装在墙上或桅杆上，并提供一个90度可调的安装支架，以提供最佳的安装灵活性。它是网络覆盖解决方案的理想天线，具有广泛的水平和垂直波束宽度。
 

HK-LGMM-7-27-24-58MiMo汽车天线

HK-LGMM-7-27-24-58 "大白 "是一款高性能的组合天线，涵盖2x2 MiMo LTE、2.4/5.0GHz WiFi可选带有26dB增益LNA的GPS/GNSS，可独立于地平面（适用于金属或塑料屋顶）单孔安装，坚固耐用，公共安全级设计，适用于公共交通、支付系统、实时跟踪、WIFI。

 

解决方案

通过这两根天线的组合，虹科能够为公交车乘客提供一个出色的连接解决方案，HK-LGMM-7-27-24-58为板载路由器提供4G天线功能。为车载路由器提供4G天线功能，这就使W24-58-CP-7天线能够在总线的长度上发射出强大的WiFi信号。这些天线被安置在独立的塑料板后面，每层有一个，是一个非常有效的解决方案，这使得天线可以放在靠近路由器的地方，减少所需的电缆长度，从而减少馈电损耗和安装成本。这提供了一个极其有效的乘客WiFi系统，在巴士的最末端记录了高达34mbps的下载速度，有了这些高性能的天线，The Original Tour现在可以为所有乘客提供强大而稳定的车载WiFi，鼓励顾客在车上分享他们的图片和旅游的乐趣。
 

 

总结

虹科车载WIFI天线部署方案，为旅游巴士与城市公交系统提供一套完整高效的WIFI覆盖方案，在保证快捷安装的同时，稳定的为车上乘客提供无线网络，提升客户满意度，为公交车运营商带来重要的增值渠道。