一般情况下,围绕「服务器负载均衡」的核心机制，行业共识是七大件：DNS轮询、HTTP重定向、IP负载均衡（L4）、应用层负载均衡（L7）、健康检查、会话保持以及全局负载均衡（GSLB），它们共同协作，把用户请求智能地分发到不同服务器上，避免单台机器过载，保证业务稳定，下面咱们用聊天的口气，把这些机制掰开揉碎了讲清楚，顺便把服务器负载均衡算法有哪些、以及负载均衡会话保持怎么配置这些实际操作问题一并解决。
先弄明白：流量进你的服务器前发生了什么
想象一下,你的网站在高峰期涌进来一万人，如果只有一台服务器，它大概率会直接摆烂，但有了负载均衡机制，请求会先撞上一道“交通指挥中心”它可能是台硬件设备，也可能是Nginx、HAProxy这类软件进程，这个指挥中心会按预设的调度策略，把请求像分菜一样均匀地派发给后端的服务器集群，这个过程就是服务器负载均衡，而它的核心价值在于：让每台后端机器发挥合理利用率，同时不让任何一台被流量压垮。
业内专家指出,80%的应用性能瓶颈并非出现在代码层面，而是出在流量分发不合理上，所以理解这套机制比盲目加服务器更管用。
服务器负载均衡算法有哪些：静态分发策略与场景适配
刚入行的朋友最常问的问题就是“服务器负载均衡算法有哪些”，简单说，它们分两派：一派是静态算法（不看服务器实时状态，纯按规矩办事），另一派是动态算法（实时看服务器负载再决定分给谁）。
轮询与加权轮询：入门标配
轮询（Round Robin）是颜值最高但脑子最直的算法：来一个请求，给服务器A，再来一个给服务器B，依次循环，适合那种所有后端机器配置一模一样、请求处理时间差不多的政务网站或展示型官网。
加权轮询（Weighted Round Robin）是它的升级版，你给配置高的服务器权重设成3，给低配的设成1，流量就会按3:1比例分配，适用场景很明确：新老服务器混搭的过渡期，或者不打算拆代码但想临时扩容的时刻，这里有个小坑：如果业务是长连接（比如WebSocket），轮询算法容易把连接压到同一台机器上，这时候就得考虑下面的算法。
最少连接与加权最少连接：动态感知派
最少连接（Least Connections）是对轮询的“拨乱反正”，它每次分流量之前，先去数一数每台后端服务器当前还挂着多少条活跃TCP连接，然后挑连接最少的那台扔过去，如果你的业务是动态请求占比高，或者每个请求执行时间差别很大的API接口
（比如一个接口查询秒回，另一个接口要算五秒），这种方式能防止“一台忙死，一台闲死”的尴尬局面。
加权最少连接则是在这个基础上叠加了权重设置,适合算力不均衡但业务复杂多变的混合集群。
IP哈希与URL哈希：定向导流的艺术
IP哈希（IP Hash）得记住一个公式：对客户端的IP地址做哈希运算，把结果映射到服务器列表上，它的好处是“同一客户端的请求永远打到同一台后端机”，这个机制对无状态接口意义不大，但对需要session保存在本机（虽然不建议但存量系统很多这么干）的传统应用，是救命稻草，而URL哈希则是对请求地址做哈希，主要用在你自己撸了一套CDN缓存、想让相同资源的请求命中同一台边缘节点时。
响应时间与带宽感知：高端玩家的选择
响应时间算法会持续探测后端每台机器的平均响应延时,然后跳过分发到最慢的那一台，带宽感知算法则看的是每台机器的出口流量使用率，这俩的动态性很强，但有个前置条件：你需要有比较完善的监控埋点，小团队或者云上购买SLB的用户，建议直接跳过这俩，选前面的静态算法就够了。
| 算法类型 | 核心判断依据 | 最适合的场景 | 常见劣势 |
|---|---|---|---|
| 轮询 | 次数循环 | 同配置机器、短连接业务 | 对慢请求无能为力 |
| 加权轮询 | 权重比例 | 新旧机器混用、临时扩容 | 权重设置靠经验 |
| 最少连接 | 活跃连接数 | API网关、动态请求 | 无法感知CPU瓶颈 |
| IP哈希 | 客户端地址 | 需要会话保留的传统业务 | 流量倾斜风险高 |
请求分发之外的隐藏机制：健康检查与故障转移
光会按策略发请求,不算一个完整的平衡机制，因为后端服务器可能会宕机，真正可靠的负载均衡器都必须配置健康检查。
主动探测与被动熔断的实现路径
主动探测的原理很好懂：负载均衡器每隔几秒（比如你设置在5秒或10秒）向后端服务器发一个HTTP HEAD请求，或者干脆建立一次TCP连接，如果连续失败三次，就把这台机器从可用列表里摘除，流量刺激就到别的机器上了。
被动熔断则是负载均衡器在真实转发请求时发现“发过去就超时”，然后动态降低该机器的优先级的操作，这两种机制能彻底解决单点故障导致整个网站打不开的问题，在简米云SLB、酷番云CLB的控制台里，这些设置项的位置一般在“后端服务器组 → 监听配置 → 健康检查”下面，你只需要填一个检测路径（比如配置成/healthz），后端写个接口返回200，就完事了。
摘除和恢复的回路细节
你可能关心“坏掉的服务器怎么回来”，常规流程是：故障机器摘除 → 运维修好并重启Nginx/Tomcat → 负载均衡器探测成功两次 → 自动加回流量池，这个过程不用人工干预，但在你的架构图里，必须明确画出探测端口与健康检查超时时间，否则刚恢复的机器容易被瞬间涌来的请求再打死。
负载均衡会话保持怎么配置：跨请求的状态锁
这是业务里最常被忽略的机制,现在很多互联网应用都是无状态的，但电商购物车、用户登录状态、后台编辑系统这种有状态业务，要求同一个用户必须始终打到同一台服务器上，如果第一次请求让A服务器处理，第二次请求被刷到B服务器，用户的登录状态就识别不出来了。
客户端的Cookie粘性方案
配置步骤很直白：你用的是Nginx的话，在upstream模块里加上ip_hash；你用的是云负载均衡的话，在监听配置里打开“会话保持”，选择“Cookie处理方式”为“植入Cookie”，此时负载均衡器会强制给用户浏览器种下一个标记，比如SERVERID=web01，之后的请求，浏览器带着这个Cookie来，负载均衡器看到cookie里写着web01，就直接转发给web01这台机器。
服务端的Session同步兜底方案
有些架构不喜欢让负载均衡器管会话,于是选择在后端服务器之间同步Session（比如用Redis存Session），这种情况下，负载均衡算法用最小连接就行，因为会话状态都沉淀到缓存里了，流量分给谁都一样，需要提醒的是：如果用了IP哈希做会话保持，请确保后端的某一台机器不要同时承担流量转发和业务处理的双重角色，否则这台机器流量一上来，很可能变成瓶颈。
跨地域容灾：全局负载均衡机制的最后一公里
上面聊的都是在一个机房内部的“服务器平衡机制”，如果你的业务牛到开了多个地域的分机房，那就需要
全局负载均衡（GSLB）机制了，它的工作方式不像上面那些那么细致，而是粗颗粒度的地域路由。
它的逻辑是：你在全局负载均衡器上配置了三个机房的IP（比如上海、广州、北京），用户从西安发起请求，GSLB解析DNS，看到用户的来源IP属于西北区，就自动把解析结果指向网络跳数最少或动态探测后延迟最低的那个机房IP，如果北京机房整体光纤被挖断，GSLB会通过存活探测发现节点不可用，然后自动把华北的流量全部切给上海机房。
这套机制在云上很好实现：你直接购买多家云的全局流量管理服务，价格丰俭由人，最低的可能就是一条DNS解析记录的成本，但生产环境建议直接买带健康检查的版本，毕竟故障自动切换这个动作，靠DNS手动不可靠，这里顺便回应一个高概率会搜到的长尾问题：服务器负载均衡价格贵吗？ 答案是：开源的Nginx不要钱，云上的成熟负载均衡实例一个月大约几十到几百块，全局负载均衡产品按流量和探测次数计费，不会让中小团队肉疼。
常见问题抽屉：帮你跳过配置雷区
问：轮询算法和加权轮询算法，在生产环境里到底怎么选？
答：如果后端服务器配置完全一致，选轮询；只要有一台是不同时代买的机器，马上切换成加权轮询，权重设置建议先按CPU核数比来，运行半天后再根据CPU使用率微调，别拍脑袋定权重。
问：如果需要临时停一台机器做运维，是直接删掉服务器还是要先调权重？
答：先去负载均衡控制台，把该服务器的状态改为“不可用”或“权重调为0”，等待现有的存量连接自然断开（大概需要等待一个keepalive超时周期），然后再对机器做维护，如果直接删服务器，正在处理的慢请求会被瞬间切断，用户看着就是“白屏报错”。
问：用了负载均衡，源站数据库还需要上只读集群吗？
答：需要，负载均衡只解决“无状态计算层”的横向扩展，它不解决数据库写入并发瓶颈，当你的请求量达到一定程度，后端的MySQL单库会成为新的瓶颈点，这时需要你自己把读写分离机制搭建好。
记住一件事：没有万能的服务器平衡机制，只有适合你当前业务阶段的配置组合。 先选对算法，再把健康检查和会话保持打开，最后用全局负载均衡兜底地域容灾，这套组合拳足以支撑绝大多数中小型业务的正常运转，别一味追求高级特性，稳定和可排查性才是生产环境的第一要务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/710274.html
