为何Redis在性能较弱的硬件上延迟表现更优？

我最近在几台不同配置的服务器上用redis-cli --latency -h '127.0.0.1' -p '6379'命令测试Redis延迟，结果完全超出我的预期——那些看起来硬件配置更弱的机器，Redis延迟反而比高性能硬件更低！

测试结果汇总： #

• E3-1270 @ 3.80GHz - Debian 9 - 内存2400MHz：延迟 ~0.26ms
• E5-405 @ 2.00GHz - Debian 7 - 内存664MHz：延迟 ~0.06ms（所有测试中延迟最低的机器）
• E5-2620 @ 2.10GHz - Debian 9 - 内存2400MHz：延迟 ~0.16ms
• E5-2420 @ 1.90GHz - Debian 7 - 内存800MHz：延迟 ~0.21ms

我之前一直笃定采购像E3这类高主频、高内存频率的硬件能带来更好的Redis性能，但这次测试结果直接打破了我的认知——低主频、老内存、旧系统的服务器反而跑出了最优的延迟表现。

背后可能的原因推测： #

要解释这种反直觉的结果，大概率和Redis的单线程特性、系统环境的差异有关：

1. 系统轻量化程度：Debian 7的内核和后台服务更精简，对CPU、内存的资源占用更少，给Redis留出了更干净的运行环境；而Debian 9的系统功能更完善，后台进程多，容易产生资源抢占。
2. CPU缓存适配性：Redis的工作集如果能完全装入CPU缓存，内存频率的影响会被大幅削弱。低配置机器内存小，工作集更容易被CPU缓存容纳，反而减少了内存访问的延迟开销。
3. 单线程性能匹配：Redis以单线程为主，单核心性能比多核总性能更关键。E5-405这类老CPU的单核心指令集优化可能刚好适配Redis的操作模式，高主频的E3反而可能因为其他后台进程干扰，单核心的实际利用率不如前者。
4. 系统调优差异：不同版本系统的默认参数（比如TCP栈配置、内存分配策略）不同，老系统的默认配置可能更偏向低延迟场景，而新系统更侧重通用性。

如果要精准定位原因，还需要进一步对比各服务器的Redis配置、CPU缓存命中率、后台进程占用等细节指标。

内容的提问来源于stack exchange，提问作者Henrique