Redis最大并发量必须实测，关键在redis-benchmark的-c参数、maxclients、系统ulimit-n和客户端连接池maxTotal四者对齐；否则压测不准或崩溃。
直接看结论：Redis 能支持的最大并发量，不能靠猜或查文档，必须用 redis-benchmark 在**当前配置 + 当前硬件 + 当前网络**下实测；而压测结果不准、上不了量、中途崩掉，八成是 maxclients、系统文件句柄、连接池参数三者没对齐。
redis-benchmark 压测时连接数上不去的常见原因
跑 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 上不去，误判为“并发撑不住”
如何用 redis-benchmark 测出真实瓶颈点
关键不是堆高 -c，而是分阶段逼近、交叉验证：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先固定连接数（比如
-c 200），用-P 50和-P 200对比 QPS 变化——如果-P 200QPS 几乎不涨，说明 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 后必须同步检查的三项
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)，若 Redismaxclients=1000，但 10 台应用每台连 200，总连接就冲到 2000 —— 服务端直接拒绝后续连接
真正难的不是算出一个数字，而是让 redis-benchmark 的 -c、Redis 的 maxclients、操作系统的 ulimit -n、以及所有客户端的连接池 maxTotal 四者形成闭环。漏掉任意一环，压测数据就不可信，上线后照样雪崩。
