自Redis Labs 2024年3月20日将BSD-3-clause源码使用协议修改为RSAv2和SSPLv1协议，包括亚马逊云科技在内的40多家公司持续投入在Valkey项目上。

博客《推陈出新——内存key-value数据库Valkey介绍和剖析》，介绍了Valkey的新特性，而用户关心的性能部分表现如何？和Redis相比是否有性能提升或者下降？

本文将通过多个全面的性能测试对比，一探究竟。

《推陈出新——内存key-value数据库Valkey介绍和剖析》

https://aws.amazon.com/cn/blogs/china/introduction-and-analysis-of-the-in-memory-key-value-database-valkey/

性能测试整体概述

本文中对自建和托管Redis与Valkey在不同版本、不同Amazon EC2实例规格进行了对比测试，得出2个主要结论。

1.托管Valkey7.2、托管Redis7.1性能均优于自建Redis7.2.4。

2.随着新的版本迭代，新的Valkey与Redis托管版本性能优于老的托管版本。

下文将深入介绍各个版本在不同场景下的具体表现。

压测环境和压测方式

在压测环境上，考虑到会进行非常高的QPS压测，为确保不因为施压端带宽等资源成为瓶颈点，因此施压端统一使用了Amazon EC2 C7i.16xlarge的规格，Amazon EC2规格表请参阅下方链接。

Amazon EC2规格表：

https://aws.amazon.com/cn/ec2/instance-types/

在Valkey、Redis中，存在一个参数io-threads，对应着Valkey中运行任务的线程数。通过增加IO线程数，Redis可以并行处理更多的网络IO操作，减少单线程处理的瓶颈。这样可以显著提高Redis处理网络请求的能力，尤其在高并发场景下，可以显著提升整体性能和吞吐量。

亚马逊云科技已经在托管的服务中做了最适配的设置，对于自建Valkey，可以按照需要设置。在不同Amazon EC2规格下推荐的io–threads设置也不同，官方关于io–threads配置建议如下：

So for instance if you have a four cores boxes, try to use 2 or 3 I/O threads, if you have a 8 cores, try to use 6 threads. 

详情请参阅Valkey官方介绍。

Valkey官方介绍：

https://raw.githubusercontent.com/valkey-io/valkey/7.2/valkey.conf

压测对比和分析

01

托管Valkey 7.2与托管Redis 7.1、托管Redis 6.2对比

测试目的：测试不同版本的托管Amazon ElastiCache服务的性能对比表现。

测试结果如下。

在服务端使用r7g.4xlarge的规格，通过压测可以发现如下结果：

• 托管Redis 7.1和托管Valkey 7.2 Get QPS均能超过100W。

• 不论Set还是Get，托管Redis和Valkey 7.x版本性能均好于Redis 6.x版本。

• 托管Redis 7.1版本和托管Valkey 7.2版本在4xlarge的摸高测试下比较接近。

压测结论：在4xlarge机型下，托管Valkey 7.2、托管Redis 7.1性能均好于托管Redis 6.2，特别是高并发场景下性能表现要更好。

02

托管Valkey 7.2与托管Redis 7.1、自建Redis 7.2对比

测试目的：评估托管Valkey与自建Redis在不同Amazon EC2规格下对比的性能表现。

服务器规格为r7g.xlarge

自建环境io-threads配置为4

测试结果如下。

在Value为64 Bytes情况下：

在Value为512 Bytes的情况下：

在服务端使用r7g.xlarge的规格，通过压测可以发现如下结果：

• 托管Redis 7.1和托管Valkey 7.2 QPS相对接近，QPS最高到60W。

• 托管Redis 7.1和托管Valkey 7.2 QPS对不同大小的item性能都优于自建Redis 7.2。

服务端规格为r7g.2xlarge

自建环境io-threads配置为8

测试结果如下。

在Value为64 Bytes的情况下：

在Value为512 Bytes的情况下：

在服务端使用r7g.2xlarge的规格，通过压测可以发现如下结果：

• 托管Valkey 7.2 QPS最高超过100W+，托管Redis 7.1 QPS最高超过80W+。

• 托管Redis 7.1和托管Valkey 7.2 QPS对不同大小的item性能都优于自建Redis 7.2。

服务端规格为r7g.4xlarge

自建环境io-threads配置为8

测试结果如下。

在Value为64 Bytes的情况下：

在Value为512 Bytes的情况下：

在服务端使用r7g.4xlarge的规格，通过压测可以发现如下结果：

• 托管Valkey 7.2 、托管Redis 7.1最高QPS均超过100W+。

• 托管Redis 7.1和托管Valkey 7.2 QPS对不同大小的item性能都优于自建Redis 7.2。

压测结论：托管Valkey 7.2和托管Redis 7.1 QPS在不同规格、不同item大小测试，性能均优于自建Redis 7.2。

03

自建Valkey 8.0、自建Redis7.2增加io-threads对比

测试目的：评估io-threads参数设置对于自建Valkey性能表现的影响。

服务端规格为r7g.xlarge

自建Valkey 8.0

测试结果如下。

在Value为16 Bytes的情况下：

在Value为64 Bytes的情况下：

在服务端使用r7g.xlarge的规格，通过压测可以发现如下结果：

随着io-threads数量的提升，不论Get和Set QPS都有明显提升。

服务端规格为r7g.2xlarge

自建Valkey 8.0

测试结果如下。

在Value为64 Bytes的情况下：

在Value为512 Bytes的情况下：

在服务端使用r7g.xlarge的规格，通过压测可以发现如下结果：

• 随着io–threads数量的提升，Get QPS会有明显的提升，在当前规格和压力下，6→8增加较少。

• 随着io–threads数量的提升，Set QPS会增加，64字节在2→4有跃升，512字节的2→4→6都有提升。

• 2xlarge在IO线程数打满到8核后，SET性能不稳定。

服务端规格为r7g.2xlarge

自建Redis 7.2

测试结果如下。

在Value为64 Bytes的情况下：

在Value为512 Bytes的情况下：

在服务端使用r7g.xlarge的规格，通过压测可以发现如下结果：

• 随IO线程数增加，GET/SET RPS会增加，但增加幅度较小，不及Valkey，尤其在6→8时，基本看不到变化。

• 自建2在不同io-threads设置下，性能都和自建Valkey8.0差距较大：GET，40w vs 90w；SET，35w vs 70w。

压测结论如下：

• IO线程数增加，会带来自建0的性能提升。但到达临界点，再增加IO线程，不会再带来额外性能提升。

• 自建0 GET比SET能享受到IO线程红利的几率更大。原因分析SET能利用到IO线程多路复用。GET能利用到IO线程多路复用和内存访问摊销的双重优势。

IO多路复用：通过IO多路复用技术可以在高并发场景下显著提升服务端处理能力，详情可参阅“Enhanced I/O multiplexing”。

内存访问摊销：内存访问分摊（MAA）是一种用于降低内存访问成本的技术，尤其适用于大型动态数据结构，例如在Redis中使用的结构。MAA将许多数据结构操作的步骤交错在一起，以确保并行访问内存并减少内存访问延迟，详情可参阅博客《借助Amazon ElastiCache for Redis 7.1，可实现每个集群每秒超过5亿个请求》。

Enhanced I/O multiplexing：

https://aws.amazon.com/cn/blogs/database/enhanced-io-multiplexing-for-amazon-elasticache-for-redis/

《借助Amazon ElastiCache for Redis 7.1，可实现每个集群每秒超过5亿个请求》

https://aws.amazon.com/cn/blogs/china/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/

压测结论总结

经过上述多轮对比和压测，可得出以下结论。

1.亚马逊云科技托管Valkey 7.2和托管Redis 7.1在增强IO多路复用的加持下，QPS最大可以超过100W，性能均好于托管Redis 6.2和自建的Valkey。

2.对于自建Valkey，调大io–threads对高并发的场景能带来性能提升，但需要结合服务器规格来设置，会存在临界点，即再增加IO线程，不会再带来额外性能提升。Get比Set能享受到IO线程红利的几率更大。Set有IO线程多路复用。Get有IO线程多路复用和内存访问摊销，因此在部分压测场景下，Get QPS增幅明显大于Set。

上述结论基于对redis-benchmark的压测，不同负载下可能达到的效果不尽相同。

从理论分析，IO多路复用的提升，内存资源的节约应该对性能有正向的提升。建议结合您的应用负载综合评估测试Valkey的效果。

本篇作者

王海忠

亚马逊云科技解决方案架构师，负责基于亚马逊云科技的云计算方案架构的咨询和设计，在云计算行业有超过9年的从业经验，具有丰富的项目实践经验，目前专注于游戏行业。

马丽丽

亚马逊云科技数据库解决方案架构师，十余年数据库行业经验，先后涉猎NoSQL数据库Hadoop与Hive、Apache HAWQ以及亚马逊云科技云原生数据库的开发和研究。

星标不迷路，开发更极速！

关注后记得星标「亚马逊云开发者」

听说，点完下面4个按钮

就不会碰到bug了！

点击阅读原文查看博客！获得更详细内容！