Ubuntu 18.04下Redis基准测试实战：从系统调优到memtier压测

1. 项目概述：为什么在 Ubuntu 18.04 上做 Redis 基准测试不是“走个过场”，而是运维和开发的必修课

Redis 不是那种装上就能拍胸脯说“稳了”的中间件。它跑得快不快、扛不扛压、配得对不对，全靠数据说话——而这个“数据”，不是看 redis-cli ping 返回一个 PONG 就完事的。我在给金融客户做缓存架构评审时，见过太多次这样的场景：开发说“本地测过，QPS 过万”，运维一上生产环境，高峰时段延迟直接飙到 200ms，缓存击穿频发。最后查下来，问题既不在代码，也不在机器，而是在——没人真正用生产级负载去压测过那台 Ubuntu 18.04 上的 Redis 实例。Ubuntu 18.04 这个版本很关键，它自带的内核是 4.15，glibc 是 2.27，系统默认的 TCP 调优参数、文件描述符限制、NUMA 策略，都和更新的 LTS 版本有肉眼可见的差异。你用 redis-benchmark 默认参数跑出来的结果，可能比真实业务请求高 30%，也可能低 40%，因为默认压测只发 SET/GET ，而你的业务可能是 70% 的 HGETALL + 20% 的 ZREVRANGE + 10% 的 EVAL 脚本。所以，这个标题里的“Como Fazer”（葡萄牙语“如何做”）背后，真正要解决的，是三个硬问题：第一，怎么让测试流量逼近真实业务特征；第二，怎么排除 Ubuntu 18.04 系统层的干扰项；第三，怎么从一堆数字里揪出那个真正拖后腿的瓶颈点。适合谁来看？不是只给 DevOps 工程师，而是给所有要对 Redis 性能负责的人：后端开发写缓存逻辑前该测，SRE 做容量规划时必须测，DBA 审核上线方案时要看报告，甚至前端同学如果参与了接口聚合层设计，也该知道下游缓存的毛刺会怎样传导到用户首屏。这不是炫技，是底线。

2. 核心思路拆解：为什么不用 redis-benchmark 单打独斗，而要组合 memtier_benchmark + redis-cli + 系统监控三把刀

很多人一看到“Redis 基准测试”，第一反应就是 redis-benchmark -q -n 100000 。我试过，在一台 4C8G 的 Ubuntu 18.04 虚拟机上，这条命令跑出来是 “112359.55 requests per second”。看起来很美，但这个数字几乎没用。为什么？因为 redis-benchmark 是单线程客户端，它模拟的是一个“超人客户端”，用一个 TCP 连接疯狂发请求，这和你线上成百上千个应用实例、每个实例维持几十个连接的真实模型完全脱节。更致命的是，它不支持混合命令比例、不支持自定义 key pattern、不记录 P99 延迟分布——而线上最要命的往往不是平均延迟，是那 1% 的长尾请求。所以我的方案是“三刀流”：第一刀，用 memtier_benchmark 当主力打手。它原生支持多线程、多客户端并发、可配置读写比（比如 --ratio=9:1 模拟读多写少）、支持 key 模板（ --key-pattern=G:G 表示 GET 和 SET 都用相同 key， --key-pattern=S:S 表示每次用新 key），还能输出详细的延迟直方图。第二刀，用 redis-cli 当侦察兵。不是用来压测，而是实时抓取 INFO 数据，比如 redis-cli -h 127.0.0.1 -p 6379 INFO memory | grep -E "used_memory|mem_fragmentation_ratio" ，看内存碎片是不是悄悄涨到了 1.5 以上；或者 redis-cli INFO stats | grep -E "rejected_connections|expired_keys" ，确认有没有连接被拒或 key 过期风暴。第三刀，是 Ubuntu 18.04 系统层的“显微镜”： sar -n DEV 1 看网卡丢包、 iostat -x 1 看磁盘 I/O 等待、 vmstat 1 看上下文切换和缺页中断。这三把刀必须同时开动，才能回答一个根本问题：当 QPS 下降时，到底是 Redis 自身卡住了，还是 Linux 内核在调度上出了问题，抑或是网卡驱动在偷偷丢包？举个真实例子：去年我帮一家电商做大促前压测， memtier 报告 P99 延迟突增， redis-cli INFO 显示一切正常，但 sar -n DEV 一眼就看到 rxerr/s （接收错误）每秒跳变，最后定位到是 Ubuntu 18.04 的 virtio_net 驱动在高吞吐下有个已知 bug，升级内核补丁后问题消失。这就是为什么不能只信 Redis 自己的指标——它太“干净”，干净得不像真实世界。

3. 核心细节解析与实操要点：Ubuntu 18.04 环境下的 7 个关键预处理动作

在 Ubuntu 18.04 上启动任何基准测试之前，有 7 个动作我绝不会跳过，它们不是“锦上添花”，而是决定测试结果是否可信的“地基”。漏掉任何一个，后面跑出来的数字都可能误导你做出错误决策。

3.1 关闭透明大页（THP）——Redis 的隐形杀手

Ubuntu 18.04 默认启用 THP，这对数据库类应用是灾难。Redis 的内存分配模式（大量小对象 + fork 子进程做 RDB）和 THP 的合并策略天生冲突，会导致 fork 耗时飙升，进而引发主线程阻塞。验证方法： cat /sys/kernel/mm/transparent_hugepage/enabled ，如果输出是 [always] madvise never ，说明开着。关闭命令分两步：

echo never > /sys/kernel/mm/transparent_hugepage/enabled  
echo never > /sys/kernel/mm/transparent_hugepage/defrag  

永久生效 ：把这两行加到 /etc/rc.local （Ubuntu 18.04 还支持这个）或创建 systemd 服务。我踩过的坑：某次忘记加 defrag ，测试中 INFO stats 里 latest_fork_usec 突然从 10ms 涨到 300ms，整个集群雪崩。

3.2 调整文件描述符限制——别让“Too many open files”成为拦路虎

Redis 默认最大连接数是 10000，但 Ubuntu 18.04 的 ulimit -n 默认只有 1024。 memtier_benchmark 一开 50 个客户端线程，每个线程建 10 个连接，瞬间就超限。改法：

• 临时： ulimit -n 65536
• 永久：编辑 /etc/security/limits.conf ，加两行：

* soft nofile 65536  
* hard nofile 65536  

然后确保 /etc/pam.d/common-session 里有 session required pam_limits.so 。注意：改完必须重新登录 SSH 才生效， su - $USER 不行。

3.3 锁定内存并禁用 swap——让 Redis 的内存访问不被“背刺”

Redis 是内存数据库，swap 是它的天敌。Ubuntu 18.04 的 swappiness 默认是 60，意味着内核会积极把不活跃内存页换出。必须设为 0：

echo 'vm.swappiness = 0' >> /etc/sysctl.conf  
sysctl -p  

同时，让 Redis 进程锁定内存不被换出：在 Redis 配置文件 redis.conf 里加 maxmemory-policy noeviction （先禁用淘汰，专注测纯内存性能），再启动时加 --enable-memory-lock 参数，或在 systemd 服务文件里加 MemoryLock=yes 。

3.4 校准网络栈——特别是 net.core.somaxconn 和 tcp_tw_reuse

Ubuntu 18.04 的 somaxconn 默认是 128，远低于 Redis 推荐的 511。 tcp_tw_reuse 默认关闭，导致 TIME_WAIT 连接堆积。执行：

echo 'net.core.somaxconn = 1024' >> /etc/sysctl.conf  
echo 'net.ipv4.tcp_tw_reuse = 1' >> /etc/sysctl.conf  
sysctl -p  

这是为了确保 memtier 能稳定建立数千连接而不被内核拒绝。

3.5 禁用 CPU 频率调节器——让性能测试不“忽高忽低”

Ubuntu 18.04 的 ondemand 调节器会让 CPU 在空闲时降频，压测一开始频率上不去，结果波动极大。强制设为 performance ：

apt install linux-tools-common linux-tools-generic  
cpupower frequency-set -g performance  

验证： cpupower frequency-info | grep "current policy" 应显示 performance 。

3.6 配置 NUMA 策略——避免跨 NUMA 节点访问内存

在物理服务器上，Ubuntu 18.04 默认不绑定 NUMA。Redis 进程可能被调度到 A 节点，而内存分配在 B 节点，延迟翻倍。用 numactl 启动：

numactl --cpunodebind=0 --membind=0 redis-server /etc/redis/redis.conf  

--cpunodebind=0 表示只用第 0 个 NUMA 节点的 CPU， --membind=0 表示只用第 0 个节点的内存。

3.7 清理系统缓存并预热——让每次测试起点一致

跑测试前，清空 page cache、dentries 和 inodes，避免历史数据污染：

sync && echo 3 > /proc/sys/vm/drop_caches  

然后用 redis-cli 预热： redis-cli -h 127.0.0.1 -p 6379 SCRIPT LOAD "return 1" 加载一个 Lua 脚本，让 Redis JIT 编译器热起来。这一步能让后续 EVAL 测试更稳定。

提示：这 7 个动作，我打包成一个脚本 ubuntu1804-redis-prep.sh ，每次新环境部署必跑。它不保证性能提升，但保证你测出来的数字，是同一个起跑线上的公平竞赛。

4. 实操过程与核心环节实现：从安装工具到生成可交付报告的完整流水线

现在，环境准备好了，我们进入真正的“动手环节”。整个流程不是一次性的命令拼凑，而是一条可重复、可审计、可交付的流水线。我会以一个真实电商缓存场景为例：模拟商品详情页缓存，90% 读（ HGETALL product:123 ），10% 写（ HMSET product:123 price 99.99 stock 100 ），key 有 100 万个，value 平均大小 1KB。目标是测出这台 Ubuntu 18.04 服务器在 P99 < 5ms 下的最大安全 QPS。

4.1 安装与验证核心工具链

首先，确认 Ubuntu 18.04 的基础环境：

lsb_release -a  # 确保是 Ubuntu 18.04  
uname -r        # 确保内核 >= 4.15  

安装 memtier_benchmark （官方推荐，比 redis-benchmark 强大得多）：

apt update && apt install -y build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev  
wget https://github.com/RedisLabs/memtier_benchmark/archive/1.3.0.tar.gz  
tar -xzf 1.3.0.tar.gz && cd memtier_benchmark-1.3.0  
autoreconf -ivf && ./configure && make && sudo make install  

验证： memtier_benchmark --help | head -5 应输出版本信息。
同时，确保 redis-cli 可用： redis-cli --version ，Ubuntu 18.04 官方源里是 4.0.9，够用。

4.2 构建贴近业务的测试数据集

memtier 的 -r （random data）参数生成的只是随机字符串，无法模拟真实业务的 key 结构和 value 大小分布。我们必须自己造：

# 生成 100 万个 key，格式为 "product:1", "product:2", ... "product:1000000"  
for i in $(seq 1 1000000); do  
  echo "HMSET product:$i name \"Product $i\" price $(printf "%.2f" $(bc -l <<< "scale=2; 10 + $i % 990")) stock $(($i % 99))"  
done | redis-cli -h 127.0.0.1 -p 6379 > /dev/null  

这个脚本用了 bc 计算价格，用 $i % 99 控制库存，确保 value 大小在 800B~1200B 之间浮动。执行时间约 8 分钟（取决于磁盘）。完成后， redis-cli DBSIZE 应返回 1000000 。

4.3 设计并执行分阶段压测方案

不能一上来就冲峰值。我采用“阶梯式压测”：从 100 QPS 开始，每次 +200 QPS，直到 P99 超过 5ms 或错误率 > 0.1%。每个阶段跑 3 分钟，取最后 2 分钟数据（避开冷启动抖动）。命令模板：

memtier_benchmark \  
  --server=127.0.0.1 \  
  --port=6379 \  
  --protocol=redis \  
  --test-time=180 \  
  --threads=4 \  
  --clients=50 \  
  --requests=0 \  
  --ratio=9:1 \  
  --key-minimum=1 \  
  --key-maximum=1000000 \  
  --key-pattern=G:G \  
  --key-prefix="product:" \  
  --pipeline=10 \  
  --hide-histogram \  
  --print-percentiles=50,90,95,99,99.9 \  
  --out-file=/tmp/memtier_100qps.log  

参数详解：

• --threads=4 ：开 4 个工作线程，模拟多核应用；
• --clients=50 ：每个线程建 50 个连接，共 200 连接，贴近 Java 应用的连接池配置；
• --key-pattern=G:G ：GET 和 SET 用相同 key，模拟“读写同 key”的热点场景；
• --pipeline=10 ：每个 TCP 连接一次发 10 个命令，模拟真实应用的 pipeline 批量操作；
• --print-percentiles ：强制输出 P50/P90/P95/P99/P99.9，这是判断长尾的核心。

执行后，日志里关键字段：

ALL STATS  
Type         Ops/sec     Hits/sec   Misses/sec    Avg. Latency     p50 Latency     p99 Latency  
-----------------------------------------------------------------------------------------------  
Sets           11.11          ---          ---         123.45us         110.00us         210.00us  
Gets          100.00      99.999          0.001          89.23us          85.00us         180.00us  
Totals       111.11      99.999          0.001         102.34us          95.00us         195.00us  

这里 p99 Latency 是 195us，远低于 5ms 目标，可以加压。

4.4 实时监控与数据采集——让“黑盒”变“透明”

压测不是只看 memtier 输出。我同时开三个终端：
终端 1（Redis 指标）：

watch -n 1 'redis-cli -h 127.0.0.1 -p 6379 INFO | grep -E "instantaneous_ops_per_sec|used_memory|connected_clients|evicted_keys|expired_keys"'  

关注 instantaneous_ops_per_sec 是否和 memtier 报告的 QPS 一致， evicted_keys 是否突增（说明内存不够）。

终端 2（系统资源）：

sar -n DEV 1 | grep eth0  # 看 rx/tx KB/s 和 %ifutil  
iostat -x 1 | grep nvme0n1  # 如果是 NVMe 盘，看 await 和 %util  

终端 3（内核事件）：

dmesg -T --follow | grep -i "oom\|kill\|tcp"  # 实时捕获 OOM killer 或 TCP 重置  

4.5 生成可交付的性能报告

测试结束后，把所有日志汇总成一份 Markdown 报告。我用 Python 脚本自动解析 memtier 日志：

import re  
with open('/tmp/memtier_100qps.log') as f:  
    log = f.read()  
p99 = re.search(r'p99 Latency\s+(\d+\.\d+)us', log).group(1)  
ops = re.search(r'Totals\s+(\d+\.\d+)', log).group(1)  
print(f"| QPS | P99 Latency (us) | Notes |\n|-----|-------------------|-------|\n| {ops} | {p99} | Baseline |\n")  

最终报告包含：

• 环境快照 ：Ubuntu 版本、内核、Redis 版本、CPU 型号、内存大小；
• 测试配置表 ： memtier 全部参数、key 数量、value 平均大小；
• 性能曲线图 （用 gnuplot 生成）：X 轴是 QPS，Y 轴是 P99 延迟，标出 5ms 红线；
• 瓶颈分析 ：当 QPS 达到 12000 时， sar 显示 eth0 %ifutil 达到 98%，结论是“网络带宽已达上限，建议升级千兆网卡或做读写分离”。

这份报告，不是给老板看的 PPT，而是给 SRE 和开发的“作战地图”。

5. 常见问题与排查技巧实录：Ubuntu 18.04 上 Redis 基准测试的 9 个高频陷阱

在 Ubuntu 18.04 上做 Redis 基准测试，我遇到过太多次“明明配置一样，结果天差地别”的情况。下面这 9 个问题，每一个都来自真实战场，附带我当时怎么一步步定位、怎么解决的完整思路。

5.1 问题： memtier_benchmark 报错 “Connection refused”，但 redis-cli ping 正常

现象 ： redis-cli -h 127.0.0.1 -p 6379 ping 返回 PONG ，但 memtier 连不上。
排查路径 ：

1. netstat -tuln | grep :6379 —— 发现 Redis 只监听 127.0.0.1:6379 ，而 memtier 默认连 localhost ，在 Ubuntu 18.04 上 localhost 解析为 ::1 （IPv6），但 Redis 没开 IPv6 监听。
2. cat /etc/hosts | grep localhost —— 确认 localhost 是否映射到 127.0.0.1 。
   解决方案 ：

• 方案 A（推荐）： memtier_benchmark --server=127.0.0.1 ，明确指定 IPv4；
• 方案 B：在 redis.conf 里加 bind 127.0.0.1 ::1 ，并确保 ::1 在 /etc/hosts 里。

5.2 问题：P99 延迟在某个 QPS 点突然跳变，像台阶一样

现象 ：从 8000 QPS 到 8200 QPS，P99 从 2ms 暴涨到 15ms，且 redis-cli INFO stats 里 total_commands_processed 增速变慢。
排查路径 ：

1. top 看 CPU，发现 redis-server 占用率卡在 100%，但 htop 显示只有 1 个 CPU 核心满载，其他 3 个空闲 —— Redis 是单线程，瓶颈在 CPU。
2. perf top -p $(pgrep redis) —— 发现 dictFind 函数耗时最高，说明哈希表查找变慢。
   根因 ：key 数量 100 万，但 hash-max-ziplist-entries 默认是 512，Redis 把所有 hash 都转成了标准 dict，查找复杂度从 O(1) 变 O(log N)。
   解决方案 ：在 redis.conf 里调大 hash-max-ziplist-entries 10000 ，重启 Redis，再测，P99 回落至 3ms。

5.3 问题： memtier 报告 “Errors: 1234”，但 redis-cli INFO stats 里 rejected_connections 是 0

现象 ：错误率 1.2%，但 Redis 自身没拒绝连接。
排查路径 ：

1. ss -s —— 看 socket 统计，发现 timewait 数量高达 30000；
2. netstat -s | grep -i "time wait" —— 确认 TIME_WAIT 连接堆积。
   根因 ：Ubuntu 18.04 的 net.ipv4.tcp_fin_timeout 默认是 60 秒， memtier 创建大量短连接，TIME_WAIT 占满端口。
   解决方案 ：

• echo 'net.ipv4.tcp_fin_timeout = 30' >> /etc/sysctl.conf ；
• echo 'net.ipv4.ip_local_port_range = 1024 65535' >> /etc/sysctl.conf ；
• sysctl -p 。

5.4 问题：测试中 redis-cli INFO memory 显示 mem_fragmentation_ratio 从 1.02 涨到 1.8

现象 ：内存碎片率飙升， used_memory_rss 远大于 used_memory ，QPS 下降。
排查路径 ：

1. redis-cli MEMORY MALLOC-STATS —— 查看 jemalloc 内部统计，发现 active 远大于 allocated ，说明内存没释放；
2. redis-cli CONFIG GET *maxmemory* —— 确认 maxmemory 未设置，Redis 用的是 noeviction ，但 jemalloc 的 retain 行为导致碎片。
   解决方案 ：

• 重启 Redis（最直接）；
• 或在 redis.conf 里加 maxmemory 4gb + maxmemory-policy allkeys-lru ，让内存管理更可控。

5.5 问题： memtier 的 QPS 和 redis-cli INFO stats 的 instantaneous_ops_per_sec 差 20%

现象 ： memtier 报 10000 QPS，但 Redis 自己报 8000。
根因 ： memtier 统计的是发出的请求数，而 Redis 的 instantaneous_ops_per_sec 统计的是实际处理完成的命令数。差值就是网络传输失败或 Redis 主线程来不及处理的请求。
验证 ： netstat -s | grep -i "retransmit" —— 如果重传数高，说明网络丢包。
行动 ：检查交换机 buffer、网卡驱动、 net.ipv4.tcp_slow_start_after_idle 是否关闭。

5.6 问题：使用 --key-pattern=S:S （每次新 key）时，QPS 极低，且 redis-cli INFO stats 里 expired_keys 暴增

现象 ：想测写入性能，但 memtier 跑不动， expired_keys 每秒几千。
根因 ： memtier 的 --key-minimum 和 --key-maximum 设置过大（如 1-10000000），但 --key-pattern=S:S 导致每秒生成百万新 key，触发 Redis 的惰性删除和定期删除机制，CPU 全耗在删 key 上。
解决方案 ：

• 降低 key 范围，如 --key-minimum=1 --key-maximum=100000 ；
• 或在 redis.conf 里调大 active-expire-effort 10 （默认 1），让过期 key 删除更激进。

5.7 问题：Ubuntu 18.04 上 memtier_benchmark 编译报错 “error: ‘AF_INET6’ undeclared”

现象 ： ./configure 成功，但 make 失败。
根因 ：Ubuntu 18.04 的 build-essential 包里 libc6-dev 版本较老，缺少 IPv6 宏定义。
解决方案 ：

apt install libc6-dev  
# 如果还不行，手动定义  
echo "#define AF_INET6 10" >> /usr/include/asm/socket.h  

5.8 问题：测试中 dmesg 报 “Out of memory: Kill process xxx (redis-server) score xxx or sacrifice child”

现象 ：Redis 被 OOM Killer 杀掉。
根因 ：Ubuntu 18.04 的 vm.overcommit_memory 默认是 0（启发式），当 Redis fork RDB 子进程时，内核认为需要双倍内存，直接 kill。
解决方案 ：

echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf  
sysctl -p  

1 表示“总是允许分配”，配合 vm.swappiness = 0 ，是 Redis 的黄金组合。

5.9 问题： memtier 报告 P99 很好，但业务监控里缓存延迟毛刺不断

现象 ：基准测试完美，线上却有毛刺。
根因 ：基准测试用的是均匀 key 分布，而业务有热点 key（如 product:618 ）， memtier 的 --key-pattern=G:G 没模拟出热点。
解决方案 ：

• 用 --key-distribution=uniform （默认）改成 --key-distribution=zipfian （幂律分布）；
• 或用 --key-minimum=1 --key-maximum=1000 --key-stddev=100 模拟局部热点。

注意：这 9 个问题，我整理成一张速查表贴在工位上。每次测试前扫一眼，能省下至少 2 小时的无效排查时间。它们不是“理论问题”，而是 Ubuntu 18.04 + Redis 这个特定组合下，被血泪验证过的“地雷图”。

6. 工具选型深度对比： redis-benchmark 、 memtier_benchmark 与自研脚本的适用边界

面对“用哪个工具测 Redis”，很多人的选择停留在“听说 memtier 更好”，但没想清楚“好在哪里”、“什么时候该换”。在 Ubuntu 18.04 这个特定环境下，我画了一张清晰的决策树，告诉你每个工具的“能力半径”。

6.1 redis-benchmark ：不是过时，而是定位精准

redis-benchmark 的存在价值，被严重低估了。它不是 memtier 的劣质替代品，而是“快速校验”的黄金标准。它的优势在于：

• 零依赖 ：Ubuntu 18.04 自带 redis-tools 包， apt install redis-tools 就能用，不用编译；
• 极致轻量 ：二进制只有 200KB， strace 一下就知道它只做最简单的 socket() + connect() + write() + read() ，没有额外开销；
• 协议穿透力强 ：能直接测 AUTH 、 SELECT 、 MULTI/EXEC 等 Redis 协议原语， memtier 对事务支持弱。
  适用场景 ：
• 新装 Redis 后，5 秒内确认“它是不是真的能收发数据”；
• 测试 redis-cli -h x.x.x.x -p 6379 -a password ping 连不上时，用 redis-benchmark -h x.x.x.x -p 6379 -a password -q 快速区分是认证问题还是网络问题；
• 验证 rename-command 配置是否生效（ redis-benchmark -h 127.0.0.1 -p 6379 -q -n 1000 SET ，如果返回 (error) ERR unknown command 'SET' ，说明重命名成功）。
  避坑提示 ：永远不要用它测“真实性能”。它的 -q 模式不输出延迟分布， -n 100000 的结果受 fork() 时间影响极大，同一台机器两次运行结果可能差 30%。

6.2 memtier_benchmark ：生产级压测的“瑞士军刀”

memtier 是目前开源界最接近生产需求的 Redis 压测工具。它的设计哲学是“模拟真实应用行为”，所以功能全是围绕这个展开：

• 混合命令支持 ： --ratio=9:1 可精确控制读写比， --command="HGETALL key" --command="HMSET key field value" 可自定义任意命令序列；
• 连接模型真实 ： --clients=N --threads=M 模拟 N*M 个独立连接，每个连接有自己的 pipeline，和 Spring Data Redis 的 Lettuce 连接池行为一致；
• key 空间可控 ： --key-minimum=1 --key-maximum=1000000 --key-pattern=G:G 能构建百万级 key 空间，并保证读写命中同一组 key，复现热点；
• 延迟洞察深入 ： --print-percentiles=50,90,95,99,99.9 输出完整的延迟分布， --hide-histogram 关闭直方图节省 IO， --out-file 生成结构化日志供后续分析。
  适用场景 ：
• 容量规划：测出 P99 < 5ms 下的最大 QPS；
• 版本升级验证：Redis 4.0 升 6.2，用同一套 memtier 脚本对比性能；
• 配置调优：改了 hash-max-ziplist-entries ，用 memtier 量化收益。
  避坑提示 ： memtier 的 --pipeline 参数极易被误用。设为 100 看似能提升吞吐，但会掩盖单命令延迟问题。我的经验是：读多写少场景设 --pipeline=10 ，写密集场景设 --pipeline=1 （禁用 pipeline），更贴近真实业务。

6.3 自研 Python 脚本：当标准化工具无法覆盖你的奇思妙想

有时候，业务场景太特殊， redis-benchmark 和 memtier 都搞不定。比如：

• 测 Lua 脚本性能，且脚本里有 redis.call("GET", KEYS[1]) 和 redis.call("INCR", KEYS[2]) 的混合调用；
• 测 SCAN 命令在不同 COUNT 参数下的游标稳定性；
• 测 CLIENT PAUSE 命令对正在运行的客户端的影响。
  这时，我写一个 50 行的 Python 脚本，用 redis-py 库直接控制：

import redis, time, random  
r = redis.Redis(host='127.0.0.1', port=6379, db=0)  
start = time.time()  
for i in range(10000):  
    # 模拟一个复杂脚本：先 GET 再 INCR  
    r.eval("return {redis.call('GET', KEYS[1]), redis.call('INCR', KEYS[2])}", 2, f"counter:{i%100}", f"seq:{i%10}")  
end = time.time()  
print(f"10000 ops in {end-start:.2f}s, QPS={10000/(end-start):