Redis单机到底能扛多大压力，实测告诉你性能极限在哪儿

关于Redis单机到底能扛多大压力，这个问题没有一个绝对的数字答案，因为它像一辆车的极速一样，严重依赖于“路况”和“车况”，所谓的“路况”就是你的业务操作类型，是简单的存取还是复杂的计算；而“车况”就是Redis服务器的硬件配置，特别是CPU、内存、网络，我们可以通过参考网络上一些工程师的实际测试数据,来勾勒出大致的性能边界。

我们必须明确一个共识，这个共识来源于多位测试者的结果：对于绝大多数常规的键值（KV）操作，Redis的单机性能非常高，通常不会成为你系统的第一个瓶颈。 它的性能瓶颈往往先出现在网络IO上,而不是CPU计算能力上。

硬件是性能的基石

根据CSDN博客上一位用户分享的测试经验，他在一台配置还算不错的服务器上（比如8核CPU、16GB内存）对Redis进行压测，当使用Redis自带的性能测试工具redis-benchmark进行简单设置（SET/GET）时，单机轻松达到了每秒10万次以上的QPS（每秒查询率），这个数字已经非常惊人了,这意味着每秒钟可以处理超过10万个简单的读写请求。

如果换一台配置较低的虚拟机，比如只有1核2G的云服务器，可能QPS就会骤降到每秒几万次，谈性能必须结合硬件，知乎上有讨论指出，为了充分发挥Redis性能，建议使用高性能的CPU（主频高、缓存大），内存容量要足够且最好用高速内存，网络带宽要足量（比如万兆网卡），并且强烈建议使用SSD硬盘来持久化，虽然Redis主要操作在内存,但持久化时的磁盘速度会影响整体稳定性。

操作类型是性能的开关

Redis不同的命令，其消耗的资源天差地别，根据多个来源的测试数据,可以总结出一个大致的性能损耗排名：

1. 简单的GET/SET操作： 这是Redis最快的操作，如上所述，在良好硬件上，达到10万+ QPS是常态,性能瓶颈基本在于网络往返时间和Redis处理网络请求的效率。
2. 复杂度为O(1)的命令： 比如LPUSH、RPOP、HSET、HGET等针对列表、哈希等数据结构的简单操作，性能虽然比最简单的KV略低一点，但依然非常高,可以达到大几万甚至十万QPS。
3. “轻度”复杂操作： 比如MGET（批量获取）或MSET（批量设置），这些命令一次网络往返可以处理多个键，能有效提升效率，但要注意，如果一次获取的键数量巨大（比如几千个），可能会阻塞其他请求片刻，测试数据显示，合理批量的MGET可能让QPS数值显得更高,因为它减少了网络开销。
4. “重度”复杂操作： 这是性能的分水岭，主要包括：
   • KEYS命令： 这是一个灾难性的命令，它会遍历整个数据库的所有键，如果你的数据库里有几百万个键，执行KEYS *可能会导致Redis在几百毫秒甚至几秒内不响应任何其他请求，等于一次小型服务瘫痪，所有测试文章都强烈禁止在生产环境使用此命令，应该用SCAN命令替代。
   • 范围查询或排序操作： 比如对一个大集合进行ZRANGE，或者使用SORT命令，这些操作的时间复杂度不是O(1),数据量大了以后会明显变慢。
   • Lua脚本： Lua脚本的执行在Redis中是原子性的，意味着脚本执行期间，整个Redis实例会阻塞，如果一个Lua脚本写得不好，里面包含大量循环和复杂计算，会严重拖累性能，测试表明，一个执行时间10毫秒的Lua脚本，就能让单线程的Redis的QPS上限被限制在100（1000毫秒/10毫秒）。

持久化配置的巨大影响

这是影响Redis性能稳定性的一个关键因素,根据知乎上的深度分析文章：

• 无持久化（RDB/AOF都关闭）： 这是性能最高的模式，所有资源都用于处理请求，但数据有丢失风险,一般只用于纯缓存场景。
• RDB持久化： 通过定时快照保存数据，在bgsave（后台保存）发生时，Redis会fork一个子进程。fork操作本身在数据量很大时（比如20GB内存），可能会让主线程停顿数百毫秒到数秒（取决于硬件速度），子进程生成RDB文件时，虽然不影响主进程处理请求，但会占用CPU和内存资源，可能对QPS有10%~20%的影响。
• AOF持久化： 记录每一个写操作日志，如果配置为appendfsync everysec（每秒同步一次，推荐），性能损耗相对较小，通常QPS下降不明显，但如果配置为appendfsync always（每次写操作都同步），为了保证数据安全，每次写入都要等待磁盘IO完成，性能会急剧下降，QPS可能会降到几千甚至更低，一篇博客的测试结果显示，从everysec切换到always,QPS可能下降一个数量级。

单线程模型的利与弊

Redis采用单线程模型处理网络请求和命令执行，这意味着它在一个瞬间只能处理一个命令，这个设计的优点是避免了多线程的锁竞争，非常简单高效，但缺点也很明显：它怕慢操作。

正如前面提到的KEYS命令和慢Lua脚本，任何一个慢命令都会像高速公路上的一个慢车，堵住后面所有的车，监控Redis的慢查询日志（slowlog）是保障高性能的关键，任何执行时间超过预设阈值（比如10毫秒）的命令都应该被揪出来优化。

性能极限在哪里？

综合来看,在以下理想条件下：

• 硬件： 高性能多核CPU、大内存、万兆网络。
• 操作： 绝大部分是简单的GET/SET或O(1)复杂度的命令。
• 持久化： 使用RDB或AOF everysec,且内存管理优化得当。
• 系统优化： 操作系统网络参数已优化,无其他资源竞争。

Redis的单机QPS突破15万，甚至向20万发起冲击是完全可以实现的，有国外的测试报告在极端优化的环境下,甚至报出过更高的数字。

但对于大多数业务场景，你可能不需要追求这个极限数字，更务实的做法是：在你的实际业务硬件上，用redis-benchmark或类似的压测工具，模拟你的业务命令混合比例进行测试，得到的数据才是对你最有价值的。 如果发现QPS无法满足要求，首先考虑的应该是优化命令使用（比如避免慢查询、使用管道pipeline批量操作），如果优化后仍不足,那么就应该考虑搭建Redis集群来进行水平扩展了。