iwrr: a wrr with always O(1) time and O(n) memory

[jizhuozhi]

An IWRR implementation likes lua-resty-balancer, but uses the double queue as same as the O(1) scheduler to avoid many rounds of pointless traversals to ensure always be O(1).

IWRR abandons smoothness on the premise of ensuring the correctness of the weighted load balancing algorithm. The memory overhead is only a queue with two sentinels, no matter how big the total weight is, only n + 2 elements of memory space will be allocated in the process, is more suitable for very large size clusters with different weights.

[jizhuozhi]

Hello, @chobits and @wangfakang . PLAT thanks :)

[lhanjian]

abandons smoothness？

Can you give a specific example of this shortcoming?

[jizhuozhi]

Hello, @lhanjian .

There is no clear proof that the smoothness and stability of load balancing are positively correlated in large traffic scenarios.

In my opinion, in a large traffic scenario, no matter what algorithm, a complete load balancing cycle will be completed quickly, as long as the load balancing does not continuously select the same instance (eg, A:1, B:1 appear continuously likes AAAAABBBBB in 10 selections).

iwrr ensures that duplicate instances are avoided as much as possible within a continuous time window. For example, for the instance list A:1, B:2, C:3, D:4, E:5, then the sequence selected by iwrr is ABCDEBCDECDEDEE, but not ABBCCCDDDDEEEEE.

So I think this may not be a shortcoming, just a little difference from swrr.

[CLAassistant]

All committers have signed the CLA.

[jizhuozhi]

Hello, @chobits . All issues are fixed, PTAL

[lhanjian]

LGTM