选负载均衡看连接数还是带宽，核心答案是：短连接业务盯带宽，长连接业务盯连接数，混合场景还得评估新建连接速率。 只盯单一指标，大概率会在流量高峰被现实教育要么服务器凉凉，要么用户卡成PPT。
以连接数和带宽为切入点,本质上是在讨论负载均衡设备的容量模型，搞清楚你的业务属于哪种流量特征，才能选对衡量标尺。
连接数上限决定设备能不能扛住压力
连接数指标在不少场景里是距离真实瓶颈最近的那把尺子,很多人觉得买负载均衡就是买个流量入口，但入口的并行处理能力往往才是命门。
并发连接数的本质含义
并发连接数指的是设备在同一时刻能够维持的TCP会话总数，这个数值直接由设备的内存大小、会话表结构、以及CPU处理会话创建/销毁的效率决定。
- 内存容量直接决定会话表能存多少条记录
- 会话表老化机制（老会话回收速度）影响实际可用容量
- CPU处理SYN Flood等新建请求的能力决定峰值响应速度
业内专家指出,并发连接数选型偏保守是常态，很多POC测试结果漂亮，上线跑真实业务就现原形，原因就在老化机制和新建速率上。
怎么判断你的业务属于连接数敏感型
这个判断不复杂,主要看你的用户行为模式，以下特征越多，连接数权重就要放得越高：
- 企业OA、ERP系统，员工登录后长时间保持在线
- 金融行情终端、交易客户端，连接保持数小时甚至全天
- WebSocket长连接、消息推送通道
- 数据库中间件或缓存层的长连接池
这类业务的共同点是：连接的“存活时间”远大于“建立时间”，你需要的不是每秒创建多少连接，而是能同时挂住多少条会话不死。
带宽指标还原真实业务吞吐能力
带宽是负载均衡对外服务能力的直观反映,尤其在视频、下载、大文件传输这类业务里，带宽不够等于把用户拒之门外。
带宽瓶颈出现的典型场景
连接数看起来没啥问题,但带宽满了导致体验崩盘的场景相当普遍，以下情况你大概率遇到过：
- 视频点播平台在晚高峰时段,连接数才1万出头，出口带宽已经跑满
- 文件分发系统在批量同步时,单条连接就能吃掉几百Mbps
- CDN回源流量突发,源站负载均衡被打爆
- 跨地域容灾场景中的数据同步流量
带宽的计算逻辑也简单：并发用户数 × 单用户平均带宽需求，比如视频720P大约需要2Mbps码流，1000人同时在线观看，峰值带宽就得预留2Gbps上下。
带宽选型的实际权衡逻辑
行业共识认为,带宽买多少核心看业务增长的冗余度，有一个不算复杂但很实用的经验值：峰值带宽预留30%-50%的余量。
- 按日峰值流量的1.5倍规划带宽冗余
- 按业务大促（电商、节日活动）最高峰的1.2倍做弹性上限
- 考虑静态资源（图片、JS、CSS）和动态接口的流量比例
- 区分内网带宽和公网带宽,内网成本低可以多给，公网带宽按实际业务需求量来
关键在于,带宽不像连接数那样能靠优化代码来补，它是实打实的硬件资源，连接数不够可以升级设备，带宽不够除了扩容没别的辙。
连接数和带宽的换算关系与场景差异
不能只看一端,也不能两头都抓瞎，正确打开方式是用换算公式把两个指标统一到同一个坐标系里。
单连接平均速率算清楚账
这里有个操作路径可以落地执行：从数据库或监控平台导出业务峰值时段的数据，算一下“单连接速率 = 峰值带宽 ÷ 并发连接数”，这个数能帮你判断设备瓶颈在哪一头：
- 单连接速率高于1Mbps（除长视频外的多数业务），带宽权重更高
- 单连接速率低于100Kbps（如IoT设备心跳、即时通讯），连接数权重更高
- 单连接速率在100Kbps-1Mbps之间，两者要综合评估
举个例子,某省级政务云平台的负载均衡选型（地域词融入），负责对接下辖各委办局的API接口，工作日早高峰并发连接数约8万条，峰值带宽约2Gbps，折算下来单连接速率25Kbps，这个数字说明业务特征是海量低频短连接，连接数上限才是这个平台该关注的指标，反之，某视频网站负载均衡选型时，并发连接数只有2万，但单连接速率高达3Mbps，这时候带宽就是硬指标。
不同协议的额度分配差异
TCP和UDP的会话表占用逻辑不同，这直接影响容量估算口径。
- TCP连接要占用完整的会话表条目,四元组、状态机、超时计时器全套上去
- UDP会话基于三元组（源IP、源端口、目的IP）折算，资源占用较低
- HTTP/HTTPS复用技术（Keep-Alive）能大幅降低连接数压力，但会拉高单连接带宽
- SSL卸载、压缩等功能会消耗额外CPU资源，间接影响连接处理能力
这个细节容易被忽略,有些方案商给你报的连接数看着很诱人，但那是基于纯TCP转发算出来的，一旦开启SSL卸载，性能直接打七折甚至打对折，选型时必须问清楚：连接数上限是基于什么协议、开启什么功能测出来的。
实操指南：负载均衡容量评估四步走（核心步骤）
这部分是可落地的操作流程,直接照着做就能完成一次靠谱的容量预估。
第一步：拉取业务日志算峰值并发连接数。
从业务服务器或现存负载均衡设备上,导出一周以上的连接监控数据（确认好统计维度），重点记录工作日的业务高峰时段，和周末的峰值数据，连接数指标有日周期性，只统计一天容易漏掉“周五晚高峰”或“月底对账”这种特殊时点。
第二步：推算峰值带宽消耗。
从流量监控平台拉取同时间段的出入口流量峰值,如果业务还没上负载均衡，可以直接在服务器侧用iftop或nload看网卡流量，带宽数据同样要按周取峰值，毕竟很多行业有明显的“黑色星期五”效应或电商大促效应。
第三步：算单连接速率并评估风险。
用第一步和第二步的数据算出单连接速率,然后结合业务类型做判断，拿不准的话，先按连接数大、带宽小来选型因为连接数超了直接拒绝新用户访问，带宽超了至少还能用，只是变慢，两害相权取其轻。
第四步：结合业务增长率乘系数。
很多IT团队做容量评估时漏掉增长因素,如果你业务年增长率在30%以上，建议在预估结果上乘以1.5到2的系数再选型（避开具体数字，用比例区间表述），这一步的意义是让负载均衡设备在生命周期内不被过早淘汰。
流量特征混杂时怎么定优先项
现实中很多时候连接数和带宽都不是单一瓶颈,这里需要关注核心维度的取舍逻辑。
| 维度 | 连接数敏感型 | 带宽敏感型 |
|---|---|---|
| 典型业务 | 消息推送、IoT平台、API网关 | 视频点播、文件下载、云盘同步 |
| 核心指标 | 并发会话数上限、新建速率 | 吞吐量、流量突发能力 |
| 设备侧建议 | 大内存、高会话表容量 | 万兆网口、高转发能力 |
| 排障信号 | 大量连接超时、SYN重传率高 | 丢包率上升、带宽跑满告警 |
如果业务是混合型的（比如既有长连接消息推送，又有文件上传下载），行业通行做法是建立两套独立的容量基线：一条按连接数，一条按带宽，最终选型结论选两者中规格更高的配置。
负载均衡容量预估常见问题解答
选的负载均衡设备连接数远超实际，就会绝对安全吗？
不会,连接数够用只能说明不会因并发连接数不足而拒绝服务，但CPU和内存压力还在，尤其是开启SSL卸载、健康检查频率调高、配了复杂策略路由等场景下，设备处理能力会明显弱化，连接数达标但CPU跑满导致转发延迟升高的情况也非常普遍。
带宽预估应该按入门带宽还是峰值带宽来买？
按峰值带宽的1.3倍左右来做基础配置，同时确认设备商是否有弹性带宽功能，结合业务形态预留突发流量余地，比如你的业务峰值带宽大约是3Gbps，起步按4Gbps配置，再确认设备是否支持按流量峰值动态扩容（大多主流厂商支持），带宽这类资源，宁可前期稍微多规划一些，也别等到高峰期才临时升级。
连接数指标里的“新建连接速率”和“并发连接数”分别指什么？
新建连接速率（CPS）指设备每秒能处理的TCP连接创建数量，影响突发流量下的响应速度和能够承受的SYN Flood压力，并发连接数（CC）指设备同时维持的连接总量，由内存和会话表容量决定，选型时两个指标都要看，新建速率不足会导致大量请求在握手阶段就被抛弃，并发不够则表现为连接超时或直接拒绝访问。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/634750.html
