go负载均衡需兼顾并发安全、权重精度与健康检查:轮询须用atomic.int32或sync.mutex防竞态;加权轮询推荐平滑算法避免扎堆;随机必须基于健康节点列表,且禁用全局rand.seed。

Go 语言实现负载均衡算法不难,但直接照搬教科书式写法容易在线上出问题:比如并发下 requestIndex 竞态、权重累积误差导致分配倾斜、随机选节点没做去重或健康检查兜底。核心是「状态管理」和「调度语义一致性」。
轮询(RoundRobin)必须用原子操作或互斥锁保护索引
Go 没有内置的全局原子计数器变量,手写 int + ++ 在高并发下必然错乱。错误写法:index = (curIndex++) % len(servers);正确做法是用 atomic.AddInt32 或 sync.Mutex。
常见错误现象:多个 goroutine 同时读到相同 curIndex,返回同一台服务器,造成流量打偏。
- 推荐用
atomic.Int32(Go 1.19+),初始化为0,每次调用Load()后Add(1) - 如果兼容老版本,用
sync/atomic的atomic.AddInt32,注意参数类型必须是*int32 - 别在循环里直接用
%计算下标——先atomic.LoadInt32,再取模,最后atomic.AddInt32,顺序不能反
加权轮询(Weighted Round Robin)要避免“扎堆”和整数截断误差
简单按权重重复追加服务器到列表(如权重 3 就塞 3 次)看似直观,但会导致高权重节点被连续调度,引发瞬时压力;而纯比例计算又容易因浮点或整数除法丢失精度。
平滑加权轮询(Smooth Weighted RR)是更稳妥的选择,它维护每个节点的「当前权重」和「有效权重」,每次调度后动态调整。
- 每个节点保存
weight(配置值)和currentWeight(运行时累加值) - 每次选节点前,对所有节点执行
currentWeight += weight - 选
currentWeight最大的节点,然后对其currentWeight -= totalWeight - totalWeight 是所有节点
weight之和,必须是整数且固定不变
这个逻辑能保证长期分布严格符合权重比,且单次调度不会连续命中同一节点。
随机(Random)不能只靠 rand.Intn,得加健康检查兜底
rand.Intn(len(servers)) 看似一行搞定,但实际部署中,随机算法最常被忽略的是「失效节点隔离」。如果某台服务器已宕机,随机仍可能选中它,导致请求失败率陡增。
- 必须配合健康检查结果过滤——只在
healthyServers切片里随机,而不是原始全量列表 -
rand.Seed在 Go 1.20+ 已废弃,应使用rand.New(rand.NewSource(time.Now().UnixNano()))构造独立实例,避免多 goroutine 共享 seed 导致序列重复 - 如果要求「同一客户端尽量粘性」,随机就不合适,得切到 IP 哈希或会话保持,这点常被误认为“随机也能凑合”
真实服务中,轮询类算法必须和健康检查联动
轮询、加权轮询、随机这些静态算法本身不感知后端状态。线上最常见的故障不是算法写错,而是「服务器挂了但还在调度列表里」。
关键点在于:调度器拿到的服务器列表,必须是经过最近一次健康检查筛选后的子集,而不是配置文件里写的原始地址列表。
- 不要把健康检查逻辑写在调度函数内部——开 goroutine 定期探测,结果缓存为
map[string]bool,调度时查表过滤 - 缓存过期时间建议设为 5–10 秒,太短增加探测压力,太长导致故障发现延迟
- 如果用
sync.Map存健康状态,注意Load返回的是interface{},需类型断言
算法本身可以很简单,但脱离运行时上下文(健康状态、并发安全、权重收敛性)谈实现,等于在生产环境埋雷。











