在我实现一个简单的负载平衡服务时，我认为big-o是它未来性能和可伸缩性的关键因素。但我找不到关于这两种算法的big-o的参考（WRR&RR）。
我试着计算了一下。
（担心我的计算可能是错误的，但我会在得到正确答案后立即编辑文章）
n->服务节点数（和权重）
Z->等待/未完成任务数
对于wrr:o（nnz）
对于rr:o（z^2）
For WRR: O(1)
For RR: O(1)
所以真正的问题是，如果我的计算是正确的，但最重要的是哪种算法在持续负载平衡（对每个运行的节点）的情况下执行最快每秒提交的数千个任务。
一些有用的参考资料：
非常好的RRimplementation
关于WRR的stackoverflowquestion
干杯！
最佳答案
那么你到底需要测量什么呢？由于大O是算法性能，似乎合理的事情是每个调度决策的时间复杂度，即需要多少操作来匹配一个任务到一个节点。
循环赛
就绪节点列表和等待任务列表都可以实现为队列，对队列的操作可以实现恒定的摊余时间。因此，除了需要为队列分配新内存所需的时间外，您在O（1）中操作。
加权循环
如果你的权值是固定的和commensurable，那么你也可以在这里实现同样的复杂性：简单地把每个节点放进循环队列数次，与它的权重成正比。我们可以制定一个算法，将它们均匀地分布在队列中。对于大多数实际应用，一些适度的量化将导致可以表示为（即缩放到）合理小整数的权重。
其他注意事项
对于节点是忙还是闲，您有什么反馈吗？如果你这样做了，那么RR应该工作得足够好，因为你没有说明任何公平性要求如果你没有空闲的反馈，那么wrr可能是有意义的。但在这种情况下，公式中的数字z似乎有些混乱，因为如果您不知道节点是否准备好接受任务，任务如何等待？如果他们在等待，因为平衡器无法足够快地处理它们，那么这对您的考虑仍然不重要，因为您可以想象任务队列与调度算法之前一样：队列的长度对调度程序中发生的事情没有影响。再次假设所有任务对您都是相同的，没有优先级、QoS保证或类似的元信息。