Redis如何评估当前系统能支持的最大并发量_使用redis-benchmark进行压测并调整连接数-Redis-PHP中文网

redis最大并发量必须实测，关键在redis-benchmark的-c参数、maxclients、系统ulimit-n和客户端连接池maxtotal四者对齐；否则压测不准或崩溃。

redis如何评估当前系统能支持的最大并发量_使用redis-benchmark进行压测并调整连接数

直接看结论：Redis 能支持的最大并发量，不能靠猜或查文档，必须用 redis-benchmark 在**当前配置 + 当前硬件 + 当前网络**下实测；而压测结果不准、上不了量、中途崩掉，八成是 maxclients、系统文件句柄、连接池参数三者没对齐。

跑 redis-benchmark -c 5000 却只看到实际建立 1024 个连接，甚至报错 Could not create socket: Too many open files，本质不是 Redis 拒绝，而是客户端或系统卡住了：

ulimit -n 返回值小于 -c 设置值（比如 ulimit -n 是 1024，但你设了 -c 2000）——Linux 进程能打开的文件描述符上限直接拦住连接创建
Redis 服务端 maxclients 小于压测并发数（默认 10000，但很多生产环境手动调低过），INFO clients 里 connected_clients 会卡在该值不动
客户端机器内存不足或 TCP 端口耗尽（尤其短连接压测时），表现为 connect() failed: Cannot assign requested address
没加 -P（pipeline）却压测高吞吐命令（如 GET），网络 RTT 成瓶颈，QPS 上不去，误判为“并发撑不住”

关键不是堆高 -c，而是分阶段逼近、交叉验证：

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

先固定连接数（比如 -c 200），用 -P 50 和 -P 200 对比 QPS 变化——如果 -P 200 QPS 几乎不涨，说明 Redis 单线程处理已饱和，不是连接数问题，是命令复杂度或 CPU 限制
再逐步提高 -c（如 500 → 1000 → 2000），每次观察 redis-cli INFO clients 中 connected_clients 和 blocked_clients 是否同步增长；若 connected_clients 不变但 blocked_clients 暴增，就是 maxclients 或系统句柄到顶了
加 -r 1000000 强制随机 key，避免哈希槽倾斜或热点 key 导致的假瓶颈（特别是集群模式下）
用 --threads 4（Redis 6.0+ 客户端支持）替代单线程压测，更贴近多核应用真实行为；注意服务端仍单线程，只是客户端发包更快

maxclients 不是独立参数，改完不配平周边，等于白调：

系统级文件句柄：运行 ulimit -n 查当前值，它必须 > maxclients；若不够，需在 /etc/security/limits.conf 中为 redis 用户设 redis soft nofile 65536 和 redis hard nofile 65536，并确认启动方式（systemd 服务需额外设 LimitNOFILE=65536）
内核 net.core.somaxconn：该值控制 listen 队列长度，应 ≥ maxclients，否则新连接在进入 Redis 前就被内核丢弃；用 sysctl net.core.somaxconn 查，临时改用 sudo sysctl -w net.core.somaxconn=65536
客户端连接池 maxTotal：比如 JedisPoolConfig 的 setMaxTotal(200)，若 Redis maxclients=1000，但 10 台应用每台连 200，总连接就冲到 2000 —— 服务端直接拒绝后续连接