内存数据库已成为基础结构的最重要的基础架构之一。 Redis是其中最受欢迎的，因为它的简单性很快就可以建立，易于使用且可扩展，以满足不断增长的业务的需求。

但是，Redis是十年前设计的，由于其简单的单线架构，对开发人员来说，缩放Redis部署可能是一种漫长而令人沮丧的体验。扩展和维护Redis簇非常复杂且耗时，如果您无法正确维护REDIS群集，则可能会丢失数据，这可能会导致用户体验问题甚至站点中断。

另外，您可以使用Dragonfly。 Dragonfly是REDIS和MEMCACHED的替代者 - 这是一个现代的内存数据库，它是基于其前辈的成功而开发的，同时提高了性能和可靠性。它的多线程体系结构允许更有效的垂直缩放，因此您可以避免水平缩放和集群管理带来的头痛，同时仍然享受缩放网站的好处。

在本文中，我们解释了蜻蜓的主要特征，并在基准测试测试中表现出对吞吐量，延迟和内存使用的测试的表现。

REDIS：易于启动和运行，复杂到缩放

redis是单线程，这意味着它一次只能做一件事情。即使机器运行的机器有多个内核，也可以利用它们并行执行多个任务。虽然REDIS可以垂直缩放（通过提高其运行硬件的内存和处理器速度），但性能的增长迅速高原 - 在单线读取过程中抛出更强大的多线程处理能力在任何更快地完成的事情中。

为了突破此限制，您唯一的选择是水平缩放 - 添加更多的redis服务器，每个服务器都运行一个单线读取的redis进程，并将它们作为集群的一部分进行管理。众所周知，REDIS簇很难设置和维护（不健康的节点很容易替换并必须手动配置，并且必须分别在每个节点上配置快照），并且它们为基础架构增加了复杂性，这意味着您最终需要需要专家DevOps员工运行和维护您的集群。

增加了保持笨拙的redis群集的挫败感，redis可能会用尽内存和崩溃，从而导致您丢失所有数据。 REDIS需要运行许多背景过程以保持健康状态，并且工作量对于其单个CPU核心的处理通常变得不合理，causing the database to crash。如果发生这种情况，您的网站可能会下降，或者可能会对用户体验产生其他严重影响。这种不稳定性意味着对您而言，请定期快照您的Redis数据库以避免丢失数据，但是不幸的是，快照过程本身也使用了大量内存，这再次使您再次处于崩溃的危险中。

。

为了解决这些资源和稳定性问题，重新使用用户倾向于大规模过度抛弃其服务器，因为担心数据丢失是通过拥有超出实际需要的群集节点，这会影响延迟，或者通过与使用机器一起配置机器比通常要求的要大得多。他们通常最终要支付所需的RAM数量的数量，只是为了涵盖快照的记忆峰值。

redis也可能受到常规latency spikes的影响。因为它是单线程，所以任何需要定期运行的背景过程都会引起延迟的巨大峰值，因为没有其他线程可以完成工作。在高潜伏期期间，吞吐量下降。如果经常发生这种情况，您的用户可能会对看起来片状的系统感到恼火。

尽管Redis仍然很受欢迎，但这些问题仍然没有解决，并继续为许多组织浪费时间和资源。我们对Redis的挫败感使我们开发了自己的倒入替代品，以解决Redis用户面临的最常见问题。

蜻蜓解决了Redis的最大问题

蜻蜓是一种替换式替代品，可以简化生产并提高性能。 IT scales vertically以支持每秒数百万的操作，并在一个实例上进行TRABYTE大小的工作负载。

与Redis单线程过程相比，蜻蜓通过其多线程处理功能使用了所有可用的硬件资源。这使其可以垂直扩展，从而导致高规格机器上更高的吞吐量，而不会压力管理集群。蜻蜓的充分利用所有可用的CPU内核的能力也使运行更便宜，因为您可以部署比redis所需的蜻蜓大小要小得多（对于可比的数据尺寸），而只是上升 - 在需要其他资源时规范服务器。

我们希望每个人都能享受更快，更可靠的内存数据库的好处，因此我们使Dragonfly获得了业务源许可证的约束，这意味着它不需要使用，并且可以提供源代码。您可以立即安装check out the code on GitHub。

蜻蜓和雷迪斯之间的基准测试比较

为了显示蜻蜓比Redis具有的可观性能优势，我们正在与您共享基准结果。为了显示最直接的比较，我们将Redis的单个实例与蜻蜓的一个实例进行了比较。

我们在AWS Graviton2 EC2 instances上进行了测试，该测试是网络优化的，并为Web应用程序提供了最佳性能。我们使用了Redis Ltd.开发的广泛使用的基准测试工具来测试吞吐量和潜伏期，以及Prometheus进行监视和可视化内存使用情况。

测试＃1：吞吐量

数据库的吞吐量通过每秒可以处理的操作数量来衡量。这是数据库性能最重要的指标之一。

我们用每个键填充了Redis和Dragonfly数据库，以模拟正在使用的数据库，然后针对Redis和Draginfly Instanes进行MEMTIER_BENCHMARC测试。

您可以从下图中看到，多线蜻蜓的吞吐量远远超过了Redis。

如何为自己重复这些测试

如果您想在自己的基础架构上测试这些性能提高，则可以遵循本指南：

• 在单独的AWS EC2实例上安装Redis版本7.0.4和Dragonfly版本0.15.0（我们使用了c6gn.16xlarge）。
• 编辑redis配置文件：
  • 受保护的模式no 这允许您从Redis服务器外部运行Memtier_benchmark命令。
  • 更改将127.0.0.1 绑定到绑定0.0.0.0 这也用于协助远程redis连接。
  • 保存“” 此禁用快照。
  • enable-debug-command是yes 此启用debug命令，您可以将其用于数据库中的虚拟数据。
• 用命令启动蜻蜓：
  • ./ dragonfly-aarch64 -proactor_threads = 64 此参数指定将分配多少个线程。
• 开始redis。

• 用1000万键填充每个数据库，以模拟正在使用的数据库。
  
  
  调试填充10000000键550

• 为每个数据库运行此memtier_benchmark命令：

  • memtier_benchmark -p 6380 -ratio = <1：0 for Get，set> - hide -Histogram -hide -Histragr -threads = <2 for redis for redis，64 for draginfly> -clients = 30 - requeSts = 200000 - - 固定 - 凝分种子-Data-size 256- expiry-range = 500-500 -S

memtier_benchmark是一种多功能工具，因此，如果您想调整测试参数以反映您自己的用法方案。

，请务必查看user manual。

测试＃2：延迟

数据库延迟是对完成操作需要多长时间的度量。当数据库具有较高的吞吐量时，这通常会影响其延迟，因为将更多数据写入数据库可能会导致延迟。考虑系统的tail latency尤其重要。尾部潜伏期的重点是花费最长时间完成的操作，而不是总体平均时间。尾巴潜伏期是针对较高百分位数的 - 例如，p99潜伏期是最长1％的请求完成的时间。

尾部潜伏期是要测量的重要指标。如果每100分之一甚至10000个操作中的每1分之一的操作速度不高，那么根据您的流量，可能会受到大量用户的影响，从而破坏对您的产品或服务的信心。服务水平协议（SLA）要求您的产品第99个百分位数的响应时间低于一定阈值，这变得越来越普遍。

蜻蜓在提供Redis吞吐量的30倍的同时，最慢的1％请求的潜伏期没有显着增加。

下面，我们绘制了我们对蜻蜓（使用64个内核）和redis的p99潜伏期测试的结果。值得注意的是，我们使用完全相同的 memtier_benchmark命令进行延迟测试与我们的吞吐量测试一样。

此图显示，尽管蜻蜓的大量吞吐量增加了，蜻蜓的p99潜伏期略高于Redis - 值得注意的是，如果我们要减少蜻蜓的吞吐量为了匹配Redis，Dragonfly的P99延迟远低于Redis。这意味着蜻蜓将为您的应用程序性能提供重大改进。

测试＃3：快照过程中的内存效率

Redis is known to perform particularly slowly当创建数据库的快照时，它的大部分内存都将重定向到快照过程。蜻蜓由于效率提高而没有遭受此问题的困扰。下面，我们的图表通过比较Redis Bgsave和Draginfly Save命令进行了什么，演示了快照时的高效蜻蜓，该命令启动了各自数据库的快照过程。

我们的结果表明：

• Dragonfly具有同一数据集的本质上较小的内存使用量。
• 蜻蜓在加载数据集和生产快照方面都更快。
• 蜻蜓的内存使用情况不会在快照过程中增长，而Redis几乎使其RAM要求翻倍。

如何为自己重复这些测试

• 在单独的AWS EC2实例上安装Redis版本7.0.4和Dragonfly版本0.15.0（我们使用了r6gd.4xlarge）。
• 编辑redis配置文件：
  • 受保护的模式no 这允许您从Redis服务器外部运行Memtier_benchmark命令。
  • 更改将127.0.0.1 绑定到绑定0.0.0.0 这也用于协助远程redis连接。
  • 启用debug-command是的，这启用了调试命令，您可以使用它在数据库中添加虚拟数据。
• 用命令启动蜻蜓：
  <>。
• 开始redis。
• 用1亿键填充每个数据库，以模拟正在使用的数据库。
  • 调试填充100000000键500
• 有关更多详细信息，请参见我们的snapshotting video演示。

REDIS与蜻蜓基准：结果摘要

正如上面的基准结果所示，蜻蜓的表现优于Redis 。蜻蜓的吞吐量比Redis高30倍，而同时，P99延迟仅增加0.2ms。

另一个高影响力的性能改进是快照过程，它在redis中消耗了大量内存 - 在蜻蜓中不会引起记忆使用中的明显峰值。

如果您正在部署新应用程序，或者希望扩展现有的REDIS部署，则蜻蜓可以在最初的内存数据库的初始实现以及持续的扩展和维护任务中节省时间和资源。 Dragonfly是Redis的一种高性能的替代品，它不会遭受资源耗尽的困扰，并且随着产品的增长准备扩展。

蜻蜓是兼容的，性能更好，毫不费力地缩放

我们建立了蜻蜓来解决Redis普遍的性能问题，正如我们的结果所表明的那样，我们已经成功了。

redis是一项惊人的技术，已被数百万开发人员使用来快速启动并运行。我们建造了蜻蜓，因此开发人员的使用方式同样易于使用，但是性能更好，并且更可靠。

使从Redis到Dragonfly的简易切换是解决Redis可扩展性和饱和问题的绝佳一步解决方案。您可以通过运行a Dockerized version of Dragonfly在几分钟内轻松入门，并使用与您使用的命令完全相同的命令来调用Redis。