连接数上限不是单一数字
一台接入节点能支撑多少连接，取决于操作系统允许的文件描述符数量、每连接占用的内存、订阅关系总量，以及接入层向后端转发时的连接与线程模型。任何一项先到上限，整体连接数就上不去。扩容前先定位瓶颈在哪一层，否则加机器只会把瓶颈一起搬过去。
资源层与调整方向
| 资源层 | 限制表现 | 调整方向 |
|---|---|---|
| 系统层 | 文件描述符或内核参数耗尽，新连接随机失败 | 提高上限并排查连接泄漏 |
| 接入层内存 | 每连接缓冲与会话占用累积，内存先满 | 收敛会话配置，限制积压消息 |
| 订阅规模 | 订阅树匹配开销上升，响应变慢 | 收敛主题粒度与订阅数量 |
| 后端链路 | 连接池或线程池饱和，响应变慢 | 按并发模型调整池大小与超时 |
| 存储层 | 写入成为瓶颈，消息延迟上升 | 分离可丢数据与必存数据的通道 |
典型使用场景
- 容量规划：按峰值并发与消息速率压测并留出余量
- 扩容决策：区分是接入层还是后端先到瓶颈
- 故障切换设计：单节点失效后其余节点要能临时承接其连接
- 成本优化：把连接数与消息吞吐分开评估，避免过度采购
压测要模拟真实会话与订阅规模：空连接与带大量订阅的连接在内存占用上差别很大，只测连接数会得到过于乐观的结论。
集群没有故障切换余量是典型的雪崩前兆：一台节点失效后其余节点被瞬间压垮，可用性问题从局部扩展为整体。
压测方法
压测建议分三个阶段：先测连接建立与保持，再叠加订阅与消息吞吐，最后做节点故障切换演练。三个阶段暴露的瓶颈通常完全不同，合并在一起测会互相掩盖。