C++实现带权重轮询调度算法 _ 状态保持与权重分布逻辑【源码】

C++实现带权重轮询调度算法 _ 状态保持与权重分布逻辑【源码】

轮询状态必须用可变对象保存，不能每次重算

这里有个常见的误区：以为权重轮询就是简单地按比例重复节点。其实不然，它的核心在于维护每个节点的“当前权重”和“已分配次数”这两种动态状态。如果每次调度都图省事，从头计算类似 current_weight = weight * (1 - allocated / total_allocated) 这样的公式，历史分配的节奏就全丢了，结果就是在短周期内，请求会严重地向某个节点倾斜，完全违背了平滑分布的初衷。

实际实现中，用 std::vector 来存储节点的元数据（比如 weight、current_weight、index）是成本最低的方案。当然，用 struct Server 封装一下会更清晰，但千万要留神，别顺手把 current_weight 声明成 const 或者只读字段——它可是要频繁变动的。

get_next_server() 的核心逻辑：加权最大值选取 + 状态衰减

标准的实现流程是这样的：每一轮调度，先遍历所有节点，给每个节点的 current_weight 加上它自己的原始 weight。接着，从所有节点里选出 current_weight 最大的那个作为本次结果。最后，也是最关键的一步：将这个被选中节点的 current_weight 减去所有节点的权重总和（sum_weights）。

这个“先加权增、再选最大、最后整体回退”的操作，本质上是在用离散的整数运算，去逼近一个理想的连续分数调度器。有几个细节必须卡死：

• current_weight 的初始值必须全部设为0，而不是初始化为 weight。
• “减去总权重和”这个操作，必须在选出节点之后执行，顺序一旦颠倒，整个权重的平衡就会被打破，产生漂移。
• 如果某个节点的权重被设为0，一定要跳过它，否则它的 current_weight 会持续负增长，干扰正常的比较逻辑。
• 当多个节点的 current_weight 相等时，通常按索引升序选择，以保证结果的确定性。

权重归一化不是必须的，但不归一化会影响浮点精度和整数溢出

直接使用整数权重（比如3、5、2）进行运算是最稳妥的。如果原始权重是小数（例如0.3、0.5、0.2），必须先放大转换成整数（比如乘以100，变成30、50、20）。否则，用 double 类型累加，几轮之后微小的误差就会累积起来，导致排序错乱，该选的节点没选上。反过来，刻意去做归一化（把所有权重除以总和）反而没有意义——算法只依赖权重之间的相对大小，归一化不仅多此一举，还会引入额外的计算误差。

实践中，下面这几个坑经常遇到：

• 用 float 存储 current_weight：通常3到4轮循环后，累积误差就可能超过0.01，导致本该在第3次被选中的节点意外被跳过。
• 权重和过大：比如单个节点权重就是10亿，总共100个节点，current_weight 累加几次就可能溢出 int32_t 的范围，这时必须使用 int64_t。
• 动态增删节点时，如果忘了同步调整 current_weight 状态数组的长度，很容易引发访问越界。

状态保持要跨调用生命周期，推荐封装成类而非函数静态变量

有些偷懒的做法，是在函数内部用一个 static std::vector state 来维持状态。这看似简单，却埋下了两个隐患：第一，多线程环境下不安全；第二，它无法支持多个独立的调度器实例（想象一下，你的系统里同时有多个不同的服务集群，每个都需要一套独立的权重配置）。

更专业的做法是定义一个 class WeightedRoundRobin。把 std::vector 和总权重 sum_weights 作为成员变量。构造函数接受一个 std::vector weights 参数来完成初始化；对外则提供一个 next() 方法来返回选中的节点索引或指针。这里还有几点需要注意：

• 避免在 next() 方法内部进行深拷贝或字符串拼接这类操作，防止引入隐性的性能开销。
• 如果需要线程安全，建议对 current_weight 的更新操作使用 std::atomic_int64_t 或更细粒度的互斥锁，而不是简单粗暴地给整个 next() 方法加上大锁。
• 调试阶段，可以在 next() 返回前打印出 current_weight 数组，观察其变化，验证分布是否平滑收敛。例如，对于权重 [3, 5, 2]，长期调用的频率应该稳定在近似3:5:2的比例。

说到底，权重轮询算法真正的难点，不在于理解公式，而在于确保 current_weight 在整数域里能够稳定地“震荡”而不发生“漂移”。只要有一次加法或减法的顺序搞错，后面的所有调度都会错位。所以，在上线之前，务必用一组固定的权重序列，模拟运行个上千轮，然后统计各节点出现的频次。如果误差超过±5%，那就得好好检查一下状态更新的路径是不是哪里出了岔子。