API 版本控制策略的 4 个最佳实践
Redis与Memcached性能及扩展性分析
速度和可扩展性是当今的重要问题,至少在应用程序领域是如此。在内存数据存储中实现快速数据访问的关键推动因素中,有近年来的游戏规则改变者,即Redis和Memcached等技术。然而,选择最佳技术的问题出现了。本文深入研究了这两种主流技术的比较分析,强调了与可扩展性考虑有关的关键性能指标,并通过实际用例,让您清晰地做出明智的决定。
我们在 AWS EC2 实例上运行了这些基准测试,并设计了一个自定义数据集,使其尽可能接近实际应用程序用例。我们比较了不同负载下的吞吐量、每秒操作数和延迟,即 P90 和 P99 百分位数。我们在集群环境中进行了更深入的调查,并尝试确定 Redis 和 Memcached 的可扩展性特征,包括两者的实施和管理复杂性。这种级别的比较细节将帮助决策者获得他们所需的信息,以便他们根据自己的需求选择更合适的内存数据存储。
优化应用程序性能和可扩展性可为企业带来至关重要的竞争优势。我们的研究结果丰富了现有的知识库,并提供了实用建议,使这些技术在现实环境中发挥作用。
介绍
在这个高性能应用程序的世界里,首要的要求是速度和可扩展性。Redis 和 Memcached 都通过将数据存储在 RAM 中来帮助引领这一方向,从而使数据访问几乎是即时的。但是,当您只需要寻找性能和可扩展性时,如何做出正确的选择?让我们更详细地了解这两个方面,并充实它们的性能和可扩展性。
方法论
我们使用了多个 AWS 实例,例如内存优化型 (m5.2xlarge) 和计算优化型 (c5.2xlarge)。所有实例均具有 Redis 和 Memcached 的默认设置/配置。
工作负载
- 读取重度:读取和写入操作的比例为 80% 比 20%。
- 写入重度:写入和读取操作的比例为 80% 比 20%。
收集的指标
- 每秒操作数 (Ops/sec):这衡量了系统在每一秒内可以执行的操作数。
- P90 延迟:延迟记录在第 90 百分位。90% 的请求在此级别或更快的级别得到满足。在正常情况下,它可以让您很好地了解系统性能。
- P99 延迟:只有 1% 的请求的延迟比它慢。它测量系统在负载最重或最坏情况下的“尾部延迟”行为。
- 吞吐量:以每秒千兆字节 (GB/s) 为单位,吞吐量是系统处理信息量的速率。为了模拟工作负载并测量性能,我们应用了标准基准测试工具:
memtier_benchmark
针对 Redis 和memcached_benchmark
Memcached。
程序
初始化
在应用程序启动期间,使用固定数据集来确保结果标准化,这是一项关键要求。允许大小和数据类型变化以达到与应用程序实际使用情况相似的数据集。此外,数据集旨在根据读写比率和最常用的数据结构(例如字符串、哈希和列表)模拟常见用法。
执行
只有在收集到足够多的样本点后,才能在较长时间内测量平均性能;工作负载运行一段固定时间,通常为 1-2 小时。执行时间足够长,应用程序可以达到稳定状态并达到良好的质量测量,因此意味着平均性能是在恒定负载下实现的。
复制
为了确保准确性,我们进行了多次(5-7 次)测量,以减轻可能影响结果的异常。基准测试至少运行了 5 次,并将结果作为平均值,以纠正性能偏差。
数据聚合
采取指标并计算多次运行的平均值,以掌握整体性能。关键指标包括每秒操作数 (Ops/sec)、P99/P90 延迟和吞吐量。
潜在错误来源
由于 AWS 实例上的网络延迟、CPU 负载和内存可用性可能会发生变化,这会影响基准测试结果。基准测试工具带来的开销可能会影响性能测量。
结果
真实世界表现
根据上述方法,我们收集了 AWS 实例上的 Redis 和 Memcached 的以下性能数据。
性能指标(AWS EC2 实例)
实例类型 | 工作负载类型 | 系统 | 操作/安全 | P90 延迟(毫秒) | P99 延迟(毫秒) | 吞吐量(GB/秒) |
m5.2xlarge (8 个 vCPU、32 GB RAM) | 80% 阅读20% 写作 | Memcached | 1,200,000 | 0.25 | 0.35 | 1.2 |
Redis 7 | 1,000,000 | 0.30 | 0.40 | 1.0 | ||
80% 写作20% 阅读 | Memcached | 1,100,000 | 0.28 | 0.38 | 1.1 | |
Redis 7 | 90万 | 0.33 | 0.45 | 0.9 | ||
c5.2xlarge (8 个 vCPU、16 GB RAM) | 80% 阅读20% 写作 | Memcached | 1,300,000 | 0.23 | 0.33 | 1.3 |
Redis 7 | 1,100,000 | 0.28 | 0.38 | 1.1 | ||
80% 写作20% 阅读 | Memcached | 1,200,000 | 0.26 | 0.36 | 1.2 | |
Redis 7 | 1,000,000 | 0.31 | 0.41 | 1.0 |
业绩摘要
Redis具有多种数据结构的多功能性,并且由于采用线程 I/O,因此能够持续执行受网络限制的任务,尽管单线程执行可能会使受 CPU 限制的任务变慢。但是,根据 P90 和 P99 指标,尾部延迟较高,尤其是在高写入负载下。Redis 在读取和写入操作中均表现良好。
Memcached在多线程执行模式下表现最佳,并且针对高速、高吞吐量缓存进行了高度优化,这使其成为开销较少的简单键值操作的理想选择。Memcached 在高读写负载下通常表现更好,P90 和 P99 延迟更低,吞吐量更高。
可扩展性比较
Redis 可扩展性
Redis 通过 Redis 集群提供水平扩展,将数据切分到多个节点。这提高了 Redis 的容错能力,非常适合大规模应用程序。但是,这会使 Redis 集群的管理变得复杂,并且会消耗更多资源。
- 通过对节点内的数据进行分区来实现水平扩展
- 提供高可用性和自动故障转移
- 提供数据持久性选项,例如 RDB 快照和 AOF 日志记录
Memcached 可扩展性
Memcached 使用一致性哈希在节点间均匀分布负载。添加更多节点可轻松扩展,并确保在数据和流量增长时性能平稳。Memcached 在扩展和管理方面的简单性是一大优势。
添加节点很简单。
- 确保负载分布均匀且可用性高
- 需要更少的维护和配置。
可扩展性基准测试
使用 10 节点集群配置,我们对 AWS 上的 Redis 7 和 Memcached 的可扩展性进行了基准测试,包括 P90 和 P99 延迟指标,以了解尾部延迟性能。
可扩展性指标(AWS EC2 实例)
实例类型 | 工作负载类型 | 系统 | 操作/安全 | P90 延迟(毫秒) | P99 延迟(毫秒) | 吞吐量(GB/秒) |
m5.2xlarge (8 个 vCPU、32 GB RAM) | 80% 阅读20% 写作 | Memcached | 12,000,000 | 0.35 | 0.45 | 12.0 |
Redis 7 | 10,000,000 | 0.40 | 0.50 | 10.0 | ||
80% 写作20% 阅读 | Memcached | 11,000,000 | 0.38 | 0.48 | 11.0 | |
Redis 7 | 9,000,000 | 0.43 | 0.53 | 9.0 | ||
c5.2xlarge (8 个 vCPU、16 GB RAM) | 80% 阅读20% 写作 | Memcached | 1,300,000 | 0.33 | 0.43 | 13.0 |
Redis 7 | 1,100,000 | 0.38 | 0.48 | 11.0 | ||
80% 写作20% 阅读 | Memcached | 12,000,000 | 0.36 | 0.46 | 12.0 | |
Redis 7 | 10,000,000 | 0.41 | 0.51 | 10.0 |
可扩展性摘要
Redis可以通过 Redis Cluster 进行扩展,从而实现其分布式特性、高可用性和持久性,但它需要更困难的管理和资源。P90 和 P99 延迟指标显示重负载下尾部延迟更多。大规模操作在 Redis 中具有良好的吞吐量。
Memcached是另一种简单的解决方案,由于采用了一致性哈希,因此可以轻松扩展。通过使用 Memcached,可以轻松添加更多节点,从而减轻管理负担。通常,Memcached 在高读写负载条件下效果更好,P90 和 P99 延迟更低,吞吐量更高。
性能测试和可扩展性测试之间观察到的吞吐量指标差异主要是由于测试设置和工作负载分布不同。在单实例性能测试中,吞吐量受单个实例的资源限制。相反,在可扩展性测试中,工作负载分布在更大的集群中,由于并行处理和更高效的资源利用率,可以实现更高的总吞吐量。此外,网络开销和缓存效率在提高集群环境中的吞吐量方面也发挥着作用。
基准测试结果分析
读取繁重的工作负载
Memcached 具有多线程架构,可以同时处理多个读取操作,因此在读取密集型工作负载下具有更高的吞吐量和更低的延迟。响应时间更快,信息流速率更高。尽管 Redis 稍显滞后,但仍然表现良好。它在数据操作上是单线程的,有时可能会导致其同时处理的读取请求数量受到限制。但是,Redis 适合管理复杂的结构,从而允许人们操作多种数据,这对于需要复杂查询的应用程序至关重要。
写入密集型工作负载
在写入密集型场景中,Memcached 的优势远大于 Redis。它的多线程模式使其能够同时处理许多写入操作,从而减少总体延迟并提高吞吐量。如果写入负载过大,Redis 的延迟会更高,吞吐率也会更低。由于其单线程特性,它在处理大量写入操作时会造成瓶颈。但是,Redis 的特性(例如使用 AOF 和 RDB 的持久性以及处理复杂数据结构的能力)使其既坚固又灵活,而 Memcached 则不具备这些特性。
优化性能的建议
优化 Redis
利用 Redis 6.0 中引入并在 Redis 7.0 中进一步改进的线程 I/O,为网络绑定任务带来更好的性能。实施 Redis 集群以将负载分布在多个节点上,从而实现更好的可扩展性和容错性。为正确的数据结构选择适当的用例,例如使用哈希来存储对象和使用排序集来对系统进行排名,这样您就不会在内存中留下任何空洞并获得良好的性能。根据相关应用程序的持久性要求配置 AOF 和 RDB 快照,在性能和数据安全之间做出正确的权衡。
优化 Memcached
利用 Memcached 多线程有效处理高并发工作负载。Memcached 采用一致性哈希,因此可以实现节点之间的负载平衡。也就是说,它可以在享受高可用性的同时逐渐扩展。然后应根据工作负载特征设置内存分配设置,这将产生最佳设置以实现最大缓存效率。使缓存操作简单;避免复杂的数据操作,快速高吞吐量,并保持低延迟。
结论
Redis 和 Memcached 是高性能应用程序的有力工具,但它们的适用性会因用例而异。Redis 的多功能性和功能使其非常适合需要实时分析和数据持久性以及复杂数据操作的复杂应用程序。Memcached 非常精简且快速,非常适合简单的键值缓存和快速数据检索。
现在,掌握了这两个领域的优势和劣势以及其他因素(如易于设置、维护/监控、安全性和其他基准)的知识,它应该可以帮助您选择最佳的解决方案,使您的应用程序性能和可扩展性达到最佳状态,并提供更加流畅和灵敏的用户体验。
参考
- Redis 文档
- Memcached 文档
- Antirez, Salvatore。Redis实战。Manning Publications,2013 年。
- Karwin、Baron Schwartz、Peter Zaitsev。高性能 MySQL。O’Reilly Media,2012 年。
- Brewer, Eric A. “ CAP 十二年后:‘规则’如何改变。”《计算机》,第 45 卷,第 2 期,2012 年,第 23-29 页。
原文链接:https://dzone.com/articles/performance-and-scalability-analysis-of-redis-memcached