当前位置：首页 > news >正文

GGSLB全局负载均衡策略详解

news 2026/8/4 15:33:49

GSLB（全局负载均衡）核心策略全景指南

在实际部署中，GSLB策略通常不是单一使用的，而是分层组合（例如：先过滤不健康的，再根据区域圈定范围，最后用RTT或权重进行精细调度）。以下是完整的策略体系，按“筛选过滤 → 静态调度 → 动态调度 → 高级粘性”四个层次划分。

第一层：健康与可用性过滤（前置“红线”策略）

此类策略不直接参与“选优”，而是用于剔除“不合格”的节点，是其他所有策略执行的前提。

策略名称	核心说明	业务举例
1.第四/七层健康检查	对VIP或RS进行TCP/UDP（四层）和HTTP/HTTPS（七层）探测。探测失败的站点直接移出候选池。	场景：某电商大促前，后端数据库连接数过高导致七层返回502。GSLB七层健康检查探测到/health.html失败，自动将该机房IP从DNS应答中剔除，用户流量不再导入故障节点。
2.会话能力阈值	通过私有协议同步各地负载均衡设备的当前会话数/最大会话数。当比值超过阈值（如80%）时，该站点不再被选择。	场景：某游戏机房会话数已达最大值的90%，即将过载。GSLB探测到后临时将其“摘除”，新用户被调度到其他空闲机房,有效避免服务器崩溃。
3.活动服务器数量	指一个VIP背后真正在线的“真实服务器（RS）”数量。优先选择活动服务器最多的站点。	场景：北京机房因运维停机缩容，只剩2台RS；上海机房正常有10台RS。GSLB优先将流量导向上海，确保新用户能获得更充沛的计算资源。
4.当前可用会话数	直接比较各站点当前剩余的可用会话连接数，选择剩余容量最大的站点。	场景：IDC-A当前剩余会话数还有5万，IDC-B只剩5千。调度器会将新来的用户DNS解析指向DC-A，实现细水长流的负载分摊。

第二层：静态与预定义调度策略（基于“已知信息”的分配）

此类策略基于IP库、权重、预设优先级等固定数据进行决策，计算开销小，速度快。

策略名称	核心说明	业务举例
5.地理区域/用户自定义区域	根据用户LDNS的IP所属IP地址段，将特定区域（如华东、华北）的用户指向指定站点。注意：DNS弱点——只能看到LDNS IP，用户配错DNS会导致调度不准。	场景：华东用户解析域名，LDNS为上海电信IP。GSLB匹配IP段后，直接返回上海机房的VIP。反面案例：某教育网学生手动将电脑DNS改为北京联通DNS，GSLB误以为是联通用户，将其调度到了联通机房，导致跨网访问卡顿。
6. IP地址权重	为DNS应答中返回的每个具体IP地址设置不同的权重（如IP-A权重70，IP-B权重30），权重决定流量比例。	场景：北京机房有两台物理机，IP-A性能强悍（权重80），IP-B性能较弱（权重20）。GSLB解析时，有80%的请求返回IP-A，20%返回IP-B，实现异构硬件下的合理利用。
7.站点（Site）权重	针对整个数据中心设置权重，决定与其他站点相比，该站点承担的总流量比例。	场景：杭州新建了双路机房，带宽成本低，希望多承担流量（权重50）；成都老旧机房带宽贵（权重20）。GSLB确保每10个新用户中，约5个去杭州，2个去成都。
8.站点管理优先级/故障转移顺序	为站点预设主备顺序（如P1>P2>P3）。只要P1健康，流量全部去P1；P1挂了才去P2。	场景：某金融核心业务，严格要求“同城双活”。主数据中心（P1）承载100%流量，同城备份中心（P2）平时不接收流量。只有当GSLB检测到P1整体机房掉电时，才将所有流量瞬时切换到P2。
9.基于拓扑的策略	不仅看地理区域，更结合AS（自治域）号或运营商内部层级（如城域网、骨干网）来选择路径最短的站点。	场景：用户LDNS属于中国电信AS4134。GSLB对比发现Site-A与LDNS同属一个城域网（跳数最少），Site-B虽地理近但需跨骨干网。拓扑策略优先选择Site-A，极大降低延迟。
10.基于成本	根据机房的带宽单价、电力成本或租用成本进行调度，优先选择“服务成本最低”的健康站点。	场景：某视频网站，夜间流量高峰时，海外昂贵带宽的机房成本飙升。GSLB自动将该机房权重降低，将更多非实时下载请求调度到国内低价带宽机房，日省数万元。

第三层：动态性能与负载感知策略（基于“实时测量”的智能选择）

此类策略依赖于实时探测或实时负载数据，能自适应网络波动和服务器压力变化。

策略名称	核心说明	业务举例
11.往返时间（RTT）	主动模式：LDNS请求时，GSLB通知各站点主动Ping/DNS Query该LDNS，选RTT最小的站点。被动模式：采集用户真实建立TCP连接时（SYN->ACK）的时间差，无需额外流量，更精准。（同样存在DNS配置错误的弱点）	场景：广州用户解析域名。主动RTT测得深圳机房响应5ms，上海机房响应30ms，GSLB将用户导向深圳。被动RTT进阶：上海机房因网络偶发拥塞，虽然Ping值正常，但TCP握手ACK延迟突增至100ms，被动RTT检测到后立即降低其命中率,用户自动流向延迟更低的北京机房。
12.基于流量（吞吐量）	监测站点当前的出/入口带宽利用率。当某站点带宽利用率超过设定阈值（如90%）时，不再向其分配新用户。	场景：某下载站，成都机房出口带宽已跑满95%。GSLB监测到后，后续用户的DNS解析将跳过成都机房，优先分配到带宽空闲的武汉机房，防止成都机房网络瘫痪。
13.基于新建连接速率	监测站点每秒处理的新建TCP/UDP连接数（CPS）。当CPS超过阈值时，该站点暂停接收新用户。	场景：秒杀活动开始时，杭州机房CPS瞬间飙升至10万/秒（阈值设定8万）。GSLB自动将杭州标记为“繁忙”，后续秒杀用户被调度到南京机房，确保杭州机房已建立的会话不受影响且不崩溃。

第四层：高级分发算法与会话粘性策略（解决“选谁”和“怎么选”的问题）

此类策略决定了在候选节点中具体如何选取唯一的那一个，并保证用户后续请求的连续性。

策略名称	核心说明	业务举例
14.轮询	按顺序循环选择健康节点。简单公平，不考虑任何性能差异。	场景：测试环境或内部管理后台，所有机房配置完全一致，按A->B->C->A的顺序轮流分配流量。
15.最少选择	调度器内部维护一个计数器，每次选择历史上被选中次数最少的节点。	场景：业务刚上线，3个新机房初始计数均为0。第一个用户去A，第二个用户发现A计数为1，B和C为0，于是选B，以此类推实现绝对均衡，避免轮询的固定顺序弊端。
16.随机选择	从所有健康站点中随机抽取一个返回。	场景：对延迟不敏感的非关键日志上报接口，使用随机策略简单粗暴地打散流量，降低调度器计算开销。
17.一致性哈希	根据客户端IP（或LDNS IP）进行哈希计算，确保同一用户每次解析都指向同一站点。若支持ECS（EDNS Client Subnet），可使用真实用户IP。	场景：用户将商品加入购物车（会话存储在Site-A的Redis中）。此时网络波动，如果改用轮询可能会把用户解析到Site-B，导致购物车丢失。采用一致性哈希，只要Site-A健康，该用户永远去Site-A，完美保持会话。
18.站点Cookie持久性	GSLB在首次DNS解析时，通过HTTP重定向或Set-Cookie在用户浏览器中植入站点标识。后续请求根据Cookie直接解析到对应站点。	场景：用户首次访问官网，被分配到北京机房，浏览器Cookie写入site=beijing。5分钟后用户再次刷新，GSLB读取Cookie，即使北京机房当前负载稍高，仍将其解析回北京，确保用户本地缓存的登录票据有效。