事实证明：即使是适中的数据集，也能享受最快的性能

使用它们的人都知道，Redis 和 Memcached 等基础架构旨在为应用程序实现最高的吞吐量和最短的延迟，它们实际上是目前可用的最快的存储系统。它们从 RAM 中提取数据，并以 O(1) 复杂度执行所有简单操作（例如 SET 和 GET）。但是，当在 AWS 等云端基础设施中运行时，Redis 或 Memcached 可能会在不同的实例和平台之间受到严重的性能差异，这会显著影响应用程序的性能。作为 Redis 和 Memcached 数据集托管的云服务提供商，我们 Garantia Data 总在寻找优化性能的最佳实践，所以最近进行了基准测试，将运行在不同 AWS 实例和平台上的小到中等规模（<=12GB）的 Redis 和 Memcached 数据集进行了比较。

架构考量

在进行基准测试时，我们首先关注的是我们要比较的各种架构备选方案。用户通常依据数据集的初始大小预估选择最经济的 AWS 实例，但是，同样重要的是谨记，其他 AWS 用户可能会共享您存储数据的同一物理服务器（正如 Adrian Cockcroft 在此处所清楚说明的那样）。如果您有小到中等规模的数据集，这一点尤其正确，因为小到 m1.small 和大到 m1.large 之间的实例比 m2.2xlarge 和 m2.4.xlarge 等大实例更有可能在同一物理服务器上共享，而后者通常在专用物理服务器上运行。一旦您的“邻居”开始从您的物理服务器中消耗过多的 I/O 和 CPU 资源，他们就可能变得比较“吵闹”。此外，本着天生意义，小到中等规模的实例在处理能力上比大实例要弱。您的实例选择可能会对您的 Redis/Memcached 性能产生很大的影响，这通常使用最少数量的代码行运行每个命令。来自“吵闹的邻居”的任何轻微干扰或延迟操作（如内存访问、网络传输或上下文切换）的处理能力不足都会显著降低吞吐量，增加延迟。因此，公平地假设使用小到中等规模 AWS 实例存储 Redis 或 Memcached 数据的应用更容易出现性能下降的问题。在 AWS 上运行 Redis 或 Memcached 的另一种方法是使用服务，比如 AWS Elasticache（用于 Memcached）或我们自己的Redis Cloud或Memcached Cloud。但是，使用 Elasticache 时，用户仍然需要选择实例大小，因此可能会遭受相同的性能问题。Garantia Data 的 Redis Cloud 和 Memcached Cloud 采用了一种不同的方法：我们将所有集群节点在 m2.2xlarge 或 m2.4xlarge 实例上运行以确保最佳性能，但我们仅根据用户实际数据集的大小（按 GB 计算）向他们收费。有关我们如何设置基准测试的所有详情，包括资源、数据集和配置，请随时进入本帖结尾。

基准测试结果

让我们直接进入正题，来看一下在 AWS 上运行 Redis 和 Memcached 的替代方案在性能方面的表现如何。

吞吐量

注意：ElastiCache m1.large 实例使用 2 个 Memcached 线程，m1.xlarge 实例使用 4 个，独立 Redis 基于单线程架构如上所示，Garantia Data Memcached/Redis Cloud 的 RPS 范围在 25-100% 之间（取决于实例类型），优于 ElastiCache 或独立 Redis。

延迟

我们还发现，Memcached/Redis Cloud 集群的平均响应时间范围在 25-50% 之间，高于 ElastiCache 或独立 Redis，99% 分位数响应时间显著较低，范围在 x6-x30 之间，远低于 ElastiCache 或独立 Redis。

注意：我们的响应时间测量考虑了网络往返时间、Redis/Memcached 处理时间和 memtier_benchmark 工具解析结果所需的时间。

结论

此基准测试表明，不同的架构方法可以提高吞吐量，显著降低 Redis 和 Memcached 在云中的延迟。我们认为，通过 Redis Cloud 和 Memcached Cloud 服务的独特架构可以解释这些发现。我们 Garantia Data 已经开发出多种技术，可以在集群的每个节点上运行，并且可以保证用户之间的最小干扰，即

• 从一个节点迁移“嘈杂”数据集到另一个节点
• 重新分片“嘈杂”数据集，以提高性能并减少干扰

在后台，我们监视每一条 Redis 或 Memcached 命令，并将其响应时间不断与最佳值进行比较。此外，我们以非侵入方式动态重新分片数据集，这是一个非常具有挑战性的操作，在多个分布式元素之间涉及复杂的同步机制。这种架构允许拥有任何大小数据集（包括小到中等的规模）的用户在最强大的实例上运行，并享受最高的性能，同时按小时仅支付他们实际使用的 GB 数——因此我们的客户可以同时得到这两个世界的最佳体验。

基准测试设置

我们知道您想知道基准测试的详细细节，因此以下是我们使用的资源

• 在 m1.small、m1.large、m1.xlarge 实例上使用 ElastiCache
• 在 m1.small、m1.large、m1.xlarge 实例上使用独立 Redis
• 在 m2.4xlarge 实例上使用 Garantia Data Redis/Memcached Cloud 集群（在同一技术平台上运行）

这是我们用于生成负载的设置

• 对于 ElastiCache 和独立 Redis 测试——运行我们的 memtier_benchmark 负载生成工具（我们开发的一款高级负载生成工具，我们很快会在我们的 github 帐户中分享）的 m2.2xlarge 实例。
• 对于 Garantia Data Redis/Memcached Cloud 测试——2 个 m2.2xlarge 实例，用于运行 memtier_benchmark 工具，一个用于模拟负载和分析结果，另一个用于创建模拟嘈杂邻居的后台负载。

我们对每种配置运行 3 次测试，并使用以下参数计算平均结果

1. 100 个连接
2. 100B 对象大小
3. 50/50 GET/SET 比率（对于 Redis 和 Memcached）

我们的数据集大小包括

• 对于 m1.small 实例：0.5GB
• 对于 m1.large 实例：5GB
• 对于 m1.xlarge 实例：12GB
• 对于 Garantia Data Redis/Memcached Cloud 集群：以上任何组合