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


(相关资料图)

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

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

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

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

虹科Redis企业版软件(RedisEnterprise)是企业级的数据库软件,也是一款实时数据平台,为全球超过8500家知名企业提供实时数据服务。具有线性可扩展性、高可用性、持久性、备份和恢复、地理分布、分层内存访问、多租户、安全性等8大核心功能、拥有RediSearch、RedisJSON等7大【Redis企业版特有模块】,可以任何规模在云、本地和混合部署中运行现代应用程序,提供无服务器、多模型的数据库解决方案。Redis企业版的核心优势是采用Redisonflash分层存储技术【内存+闪存+磁盘】的存储方式,其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企业版软件(RedisEnterprise)是企业级的数据库软件,也是一款实时数据平台,为全球超过8500家知名企业提供实时数据服务。具有线性可扩展性、高可用性、持久性、备份和恢复、地理分布、分层内存访问、多租户、安全性等8大核心功能、拥有RediSearch、RedisJSON等7大【Redis企业版特有模块】,可以任何规模在云、本地和混合部署中运行现代应用程序,提供无服务器、多模型的数据库解决方案。Redis企业版的核心优势是采用Redisonflash分层存储技术【内存+闪存+磁盘】的存储方式,其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延迟基准测试结果。

关键词: