目錄
一.基於權重的隨機負載均衡策略
有3台機器，每台機器都有各自的權重，如下如所示：
現在假設用戶發起1次調用，請求被Server1處理，下一次請求，請求可能仍然被Server1處理，也可能是Server2或者Server3處理。
只是在大量調用后，總體的規律是，1/6的請求會走到Server1上，2/6的請求會走到Server2上，3/6的請求會走到Server3上。
二.基於輪詢的負載均衡策略
這種策略，與每台機器的權重就沒有關系了，如下圖所示：
在這種策略中，第1次請求被Server1處理，第2次請求被Server2處理，第3次請求被Server3處理，第4次請求被Server1處理，第5次請求被Server2處理，第6次請求被Server3處理....每個節點都會依次接收處理請求。
三.基於權重的輪詢負載均衡策略
這種策略，是在輪詢策略上增加了權重這個因素，如下圖所示：
使用這種策略，會將請求“分組”，以上面這個圖為例，因為總權重為600，和各節點約分后，分別占權重1/6，2/6，3/6，那么這個“分組”就是6，也就是說6個請求為一組，Server1會處理其中的1個請求（因為其權重占比為1/6），同理，Server2會處理2個請求，Server3會處理3個請求。
現在假設有2組（也就是12個請求），那么處理過程如下：
1.發起第1次請求，請求被Server1處理；
2.發起第2次請求，請求被Server2處理；
3.發起第3次請求，請求被Server3處理；
4.發起第4次請求，請求被Server2處理，注意，此時不是Server1處理，因為Server1已經處理了1/6的請求；
5.發起第5個請求，請求被Server3處理；
6.發起第6個請求，請求被Server3處理，注意，此時不是Server2處理，因為Server2已經處理2/6的請求；
此時，一組請求已經完成處理（共6個），接着進行第2組的處理。
7.發起第7個請求，請求被Server1處理；
8.發起第8次請求，請求被Server2處理；
9.發起第9次請求，請求被Server3處理；
10.發起第10次請求，請求被Server2處理，注意，此時不是Server1處理，因為Server1已經處理了1/6的請求（1個請求）；
11.發起第11個請求，請求被Server3處理；
12.發起第12個請求，請求被Server3處理，注意，此時不是Server2處理，因為Server2已經處理2/6的請求（2個請求）；
四.基於最少活躍數的輪詢負載均衡策略
這里說的“最少活躍數”，是指每個Server正在處理的請求數量。
每個Server維護一個counter計數器，當一個請求被Server處理時，counter加1，當請求被處理完畢，counter減1。
新發起的請求總是被counter最小的Server處理，因為counter最小，從側面可以推斷出請求到達該Server后，會更快的拿到響應結果。
五.基於一致性hash的負載均衡策略
輪詢和隨機，這兩種策略都存在這樣一個問題，假設是同一個用戶發起的多次請求，按照輪詢和隨機的規則，這多次請求會被不同Server機器處理。
但有些時候為了讓同一用戶的請求都被同一個Server處理，一般會根據某個條件進行路由，比如用userId取mod，確定服務器的編號，這樣的話，一個用戶發起多次請求，請求都將會被同一個機器處理。
上面說的這種方式，是一種簡單的取模確定機器，但是存在雪崩的風險，為了避免出現這個風險，所以才有了一致性hash的算法，關於一致性hash算法，這里就不闡述了。