业务要上负载均衡该先判断流量模型吗，什么是会话需求？

业务上负载均衡，第一步不是选品牌、看参数，而是先搞清楚流量模型与会话需求，否则买再贵的设备也扛不住真实业务。

先分清流量模型，搞懂自己业务属于哪一种

负载均衡选型的本质,是让转发能力和业务特征匹配，流量模型决定了你要买四层还是七层、要硬件还是软件、要多大吞吐，很多团队在架构评审时直接跳过这一步，等到大促压测才发现瓶颈不在带宽，而在连接处理能力。

加载中

01_基础知识培训 深信服负载均衡应用交付SANGFOR_AD初级培训

Mit在线教入门到躺平

3539231

原视频地址

并发模型与吞吐模型怎么分

业务流量大致分两类,一类是高频短连接，比如API网关、支付回调、抢购秒杀场景，这类请求量大、单个请求处理时间短，但对新建连接速率和并发连接数极其敏感，另一类是大流量长连接，比如视频推流、文件传输、消息推送，单连接持续时间长，讲究吞吐量和带宽利用效率。

行业共识认为,负载均衡的选型判断顺序应该是：先数清楚每秒新建连接数，再看并发在线数，最后才看带宽需求，因为并发数可以靠扩容扛，新建连接速率一旦顶不住，整个链路直接雪崩。

长连接和短连接的区别，直接决定协议选型

• 短连接场景：每次请求都要经历TCP三次握手，负载均衡需要快速处理SYN Flood，四层转发优势明显，但要注意源端口耗尽问题。
• 长连接场景：连接复用好，服务端内存占用高，负载均衡需要做空闲连接超时管理，否则失效连接堆积，后端节点健康检查会误判。
• 混合场景：比如WebSocket叠加HTTP轮询，必须让负载均衡区分协议类型，七层能力此时更有用。

判断方法是抓包看连接持续时间分布,用tcpdump抓一分钟流量，如果大部分连接生命周期在几百毫秒以内，属于典型的短连接；如果大量连接存活超过几分钟甚至几十分钟，就是长连接主导，统计工具用ss命令也行，看State列里ESTABLISHED连接的平均寿命。

通过抓包和压测判断流量画像

实操步骤建议这样走：

• 用tcpdump在负载均衡入口抓包，抓取5到10分钟真实业务流量，重点看TCP握手频率和连接持续时间。
• 用wrk或ab做基础压测，先测单机极限QPS，估算集群总量级。
• 用netstat或ss监控当前并发连接数，高峰时段数值除以业务实例数，得到单机基准值。

这套动作做完,流量模型基本就有数了，很多业务自以为是高并发，实际压测后发现每秒只有几百个请求，这种情况直接上软件负载均衡就够了，反过来，有的业务看起来流量不大，但每个请求要回源拉取大文件，带宽反而成了瓶颈，这种情况就得关注负载均衡价格中网卡吞吐和转发时延的投入产出比。

四层负载均衡和七层负载均衡的区别，关键看会话需求

这是老生常谈但依然高频踩坑的话题,四层工作在网络层和传输层，只做IP端口转发，不关心报文内容；七层工作在应用层，能解析HTTP头部、URL路径、Cookie等信息，但落到实际选型，真正的分水岭不是协议栈，而是业务有没有会话状态。

会话保持是什么意思，为什么影响转发策略

会话保持,也叫粘性会话，指的是同一个用户的多次请求被负载均衡转发到同一台后端服务器，原因很简单：如果用户在A服务器登录，下次请求被转发到B服务器，而B服务器没有用户的Session数据，用户就被迫重新登录。

负载均衡会话保持怎么配置,取决于业务用不用Session，无状态服务（比如JWT鉴权的API接口）不需要会话保持，轮询算法就能把请求均匀打散，有状态服务（比如传统Java Web应用、WebSocket聊天室）必须开启会话保持，否则体验直接崩掉。

有状态业务的会话保持流程

典型场景是电商购物车系统,用户加购、结算、支付这串操作跨多个请求，后端Session里存了购物车数据，如果负载均衡用轮询，第一次请求打到节点A，第二次打到节点B，用户购物车直接变空，这是事故级故障。

有状态业务推荐这样处理：

• 在七层开启基于Cookie的会话保持，让负载均衡在响应头注入会话Cookie，后续请求带上这个Cookie就能精确调度到同一台后端。
• 在应用层做Session共享，用Redis或Memcached统一存储Session，这样即使转发到不同节点也能读到数据，此时负载均衡可以关闭会话保持，用最少连接算法反而更均衡。
• 后端做WebSocket长连接时，负载均衡器需要在建立连接时绑定节点IP和端口，后续数据帧按绑定关系转发，会话保持是硬性要求。

反过来,无状态服务上会话保持会带来严重不均衡，因为哈希调度会把同一IP或同一Cookie的请求固定到某个节点，如果某个用户请求特别频繁，节点负载会远高于其他节点，行业共识认为，无状态服务优先用轮询或最少连接，刻意不用会话保持才是正确的。

下面是两套场景配置对照：

负载均衡会话保持怎么配置，按业务状态类型分步落地

配置本身不难,难的是判断该不该开、在哪一层开、超时时间设多少，这里直接分场景给配置思路，适合动手实操时对照使用。

源地址会话保持与Cookie保持如何选

• 源地址哈希：根据客户端IP做哈希，同一IP固定转发到同一后端，适用于内网系统、OA办公类应用，客户端IP固定且数量不多，但公众网络下NAT场景多，大量用户共享公网IP，哈希会倾斜，不推荐。
• Cookie插入：负载均衡在首次响应中插入Set-Cookie字段，后续请求携带该值进行定向转发，适用于公网Web业务，粒度比源地址精细，但需要负载均衡支持HTTP层解析。
• Cookie学习：后端应用自己种Cookie，负载均衡读取该Cookie值做调度，适用于后端已经有会话标识的场景，负载均衡不用改报文，性能损耗小。

配置命令以Nginx和HAProxy为例,Nginx的sticky指令用cookie方式最省事，HAProxy用stick-table配合cookei前缀来实现，nginx配置里upstream块中加上sticky cookie srv_id expires=1h;即可生效，HAProxy的backend段中加cookie SERVERID insert indirect nocache，配合server web1 10.0.0.1:8080 cookie A这样指定节点标识。

结合超时参数看链路会话需求

会话保持生效期间,后端健康检查可能出现误判，比如一个长连接挂在节点A，节点A进程卡死，负载均衡健康检查探测失败，把流量切到节点B，但会话保持状态还是指向节点A，导致新请求全量报错，这种情况需要在负载均衡上配置会话保持与健康检查联动，检测到后端异常时强制清除会话绑定。

超时参数推荐这样设：

• 业务会话超时：取业务登录态过期时间的1.5倍，比如登录态15分钟失效，会话保持设25分钟比较合适。
• 健康检查间隔：3到5秒探活一次，连续两次失败摘除节点。
• TCP空闲超时：面向公网的短连接业务，空闲超时设成60秒；长连接业务设成3600秒以上，或者对接后端应用的keepaliveTimeout。

有些负载均衡器支持会话表老化时间动态调整,短连接业务把会话表老化时间缩短，能释放更多内存给新建连接，这也是为什么先判断流量模型再配置参数的原因，参数不匹配会引起表项溢出，这比选错型号更隐蔽。

负载均衡价格差异背后，流量模型错配才是最大成本

负载均衡价格从几千到几十万跨度很大,但单纯对比硬件参数没意义，如果业务是轻量API服务，买两台高性能硬件负载均衡完全是浪费；如果业务是全国性直播平台，只靠软件负载均衡跑大量长连接，性能衰减会非常明显，因为软件方案受制于CPU中断处理和内核协议栈效率。

硬件负载均衡与软件负载均衡怎么选

硬件方案强在专用芯片处理转发面，四层转发时延可以做到微秒级，吞吐量达到百G级别，软负载（Nginx、HAProxy、LVS）跑在通用服务器上，性能上限由CPU主频和网卡队列决定，但大多数中小业务跑不到硬件的瓶颈，软负载配合多实例横向扩展完全够用。

还要考虑运维成本,硬件设备从采购到上线要经历稳定测试、配置下发、变更管理，周期以周计，软件方案在云环境里分钟级拉起，弹性伸缩天然适配，选型时把TCO算清楚，能省下很多预算。

四层与七层的性能侧重点

• 四层转发只改IP和端口,CPU开销极小，单机并发可以做到百万级，用于Redis、MySQL、Kafka这类TCP协议的流量分发，效果很好。
• 七层转发要解析HTTP头部、做正则匹配、处理Cookie，对CPU算力消耗大，单机QPS受限于并发连接数，用于Web应用、API网关、SSL卸载场景更合适。

一个实用的判断标准是：业务协议是TCP裸流（数据库中间件、消息队列），一律用四层；业务协议是HTTP/HTTPS（Web站点、移动端API），用七层做卸载和路由，这种情况下的负载均衡价格高低并不代表性能好坏，只代表功能覆盖范围的差异。

关于负载均衡流量模型与会话需求的常见问题

问题1：四层负载均衡和七层负载均衡的区别到底是什么？

四层负载均衡工作在传输层,转发数据包时只改目标IP和端口，不剖析数据内容，天然支持任意TCP/UDP协议，七层负载均衡工作在应用层，能理解HTTP头部、URL路径、Cookie和请求体，两者核心区别不只是协议层级，而是能否感知业务状态，四层适合高吞吐、纯协议转发；七层适合需要智能路由、SSL卸载、会话保持的业务场景，代价是更高的CPU消耗和更低的并发承接量。

问题2：负载均衡会话保持怎么配置才能避免重复登录？

两个前提条件：一是负载均衡必须开启Cookie会话保持或IP哈希；二是后端应用必须配置Session超时时间，保证会话记录不提前失效，配置路径以酷番云为例，进入负载均衡控制台，在监听器管理中新建七层监听器，开启会话保持并选择Cookie植入方式，过期时间插件中填600秒或更长，注意Session超时时间要和负载均衡会话保持时间对齐，否则会出现前端保持还在、后端Session已过期的情况。

问题3：什么情况下需要负载均衡？小流量业务也要用吗？

判断标准不是流量大小,而是单点故障容忍度，只要业务要求7×24可用，哪怕日均请求量只有几百次，也应该至少部署两台服务器加负载均衡做冗余，小流量业务用软件负载均衡配合健康检查，成本接近零；大流量业务才需要专门设备来做性能承载，另一个判断维度是扩容效率，业务规模无法预估时，提前挂上负载均衡能显著降低后续扩容的复杂度。

流量模型和会话需求是负载均衡的底层地基,地基打错了，后面用再多优化手段都是缝缝补补，先看业务是长连接还是短连接、有状态还是无状态，再决定四层还是七层、硬件还是软件、会话保持怎么配，这条路走顺了，负载均衡才能真正扛住业务增长的压力。