网卡PPS打满是吞吐量上不去的常见原因，尤其在小key/value场景下，单请求虽仅60–100字节却生成独立TCP包，易使网卡达到硬件上限。
Redis响应时间正常但吞吐量上不去，先查网卡PPS是否打满
响应时间（latency）低只说明单次请求快，不代表单位时间能处理多少请求。吞吐量（TPS/QPS）卡住，很可能是网卡每秒处理的数据包数量（PPS）达到硬件上限——尤其在大量小 key/value 场景下，比如 SET key1 val1 这类命令，每个请求约 60–100 字节，但会生成一个独立 TCP 包。此时即使 CPU、内存、Redis 自身都空闲，网卡也扛不住。
常见现象：
- redis-cli --latency 测出平均延迟
- top 看 Redis 进程 CPU 使用率长期 netstat -s | grep "packet receive errors" 出现大量
receiving errors或dropped -
ethtool eth0显示当前速率是 1Gbps，但实际吞吐才 200Mbps，且cat /proc/net/dev中 RX PPS 持续接近 148,800（1G 网卡理论 PPS 上限）
实操建议：
- 用
perf stat -e net:netif_receive_skb -I 1000监控每秒进来的数据包数，对比网卡标称 PPS 极限（1G ≈ 148K，10G ≈ 1.48M） - 确认是否启用了 TCP 小包合并：检查
/proc/sys/net/ipv4/tcp_nodelay是否为 0（默认是 1，即禁用 Nagle；若为 0，小包会攒批发，但增加延迟） - 压测时改用
pipeline或MSET批量操作，把 100 次SET压成 1 次网络往返，直接绕过 PPS 瓶颈
跨机房或云厂商 VPC 内部带宽被限速
公有云环境里，“网络带宽”不是指实例规格标注的“峰值带宽”，而是指 VPC 内部转发带宽或安全组/ACL 的隐式限速策略。Redis 客户端和服务端哪怕在同一可用区，也可能经过虚拟交换机、ENI、NAT 网关等中间节点，其中任一环节限速都会拖垮吞吐。
典型表现：
-
redis-cli --latency -h redis-prod.internal --p 6379延迟稳定在 0.3ms，但压测时QPS卡在 1500 左右再也上不去 - 用
iperf3 -c redis-server-ip -P 4测 TCP 吞吐，结果只有 300Mbps（远低于实例标注的 5Gbps） - 云控制台监控里看到“VPC 流量整形丢包”或“弹性网卡入方向限速告警”
实操建议：
- 确认客户端与 Redis 实例是否真在同一个子网 + 同一安全组；避免走公网 NAT 或跨 AZ 路由
- 阿里云需检查“ECS 实例带宽类型”是“按固定带宽”还是“按使用流量”，后者可能受突发带宽限制；腾讯云关注“云服务器带宽配额”和“VPC 流控策略”
- 临时绕过：把压测客户端部署到 Redis 所在宿主机（Docker 共享 host 网络），若 QPS 立刻翻倍，基本锁定是网络路径问题
Redis 客户端连接未复用或连接池过小
每个 TCP 连接都要经历三次握手、TIME_WAIT 回收、内核 socket 缓冲区分配。如果压测脚本每次请求都新建连接（比如 Python 里没用 connection pool），连接建立开销会吃掉大量 PPS 和 CPU，吞吐自然上不去，而单次命令 latency 看不出异常。
容易踩的坑：
- Python redis-py 默认不启用连接池，
r = redis.Redis(host="x")每次调用都可能建新连接 - 连接池
max_connections设为 10，但压测并发设了 200，导致 190 个请求排队等连接 - Jedis 设置了
setMaxTotal(10)，但没设setBlockWhenExhausted(true)，连接耗尽后直接抛异常，压测工具误判为失败而非排队
实操建议：
- Python：显式创建连接池：
pool = redis.ConnectionPool(host="x", port=6379, max_connections=200)，再传给redis.Redis(connection_pool=pool) - Java：JedisPool 初始化时确认
setMaxWaitMillis()不为 -1（无限等待易卡死），并开启testOnBorrow防止脏连接 - 用
redis-cli client list | wc -l实时看当前连接数，对比压测并发数——若长期远小于并发数，说明连接根本没打满，问题在客户端配置
Redis 服务端配置未适配高吞吐场景
默认 redis.conf 是通用配置，面对万级 QPS 会暴露多个隐性瓶颈：TCP backlog 不足导致连接被丢弃、TCP keepalive 时间过长占着连接不放、甚至 tcp-keepalive 开启反而加重内核负担。
关键参数检查项：
-
tcp-backlog：Linuxnet.core.somaxconn值必须 ≥ 此值，否则新连接 SYN 包会被内核丢弃；生产建议设为 511 或更高 -
tcp-keepalive：设为 300（5 分钟）即可，设 0 表示关闭，设太小（如 60）会导致大量保活包冲击网卡 -
io-threads（Redis 6+）：单机多核场景下必须开启，设为 CPU 核数一半（如 8 核设 4），否则网络读写全压在主线程 -
maxmemory-policy：若设为noeviction且内存快满，后续写入会频繁触发内存检查，拖慢吞吐；建议用allkeys-lru并配好maxmemory
真正容易被忽略的是：这些参数改完必须 CONFIG REWRITE 持久化，且要 redis-cli CONFIG GET xxx 现场验证是否生效——很多团队改了 redis.conf 却忘了重载或 CONFIG SET，配置实际没生效。
