Smooth weight Round Robin algorithm

[wycccccc]

#315 中SWRR演算法討論，我有想到解決炮口一致的問題。
簡而言之借鑑了VNSWRR的思路。
因爲SWRR算出來的節點排序是固定的所以可以先事先算好一定量的後續排序。而不是需要的時候再一筆筆算。
這樣能帶來兩個好處：
1.解決炮口問題，一開始我們根據初始權重生成排序，然後隨機起點，這樣炮口就不一致了。
2.SWRR算法的時間複雜度是O(n),n爲節點數量，因爲他需要從所有節點中找到狀態最好的。改稱先算排序那就變成了直接拿，複雜度就變爲了O(1),這在節點數量有很多的情況下效能會有所改善。
缺點：
空間換時間，外加需要考慮排序所花的時間，何時排序才能不影響某筆資料的latency

第二個好處目前似乎還不急，我讀其他文章這個算法的效能瓶頸似乎在有2000個節點纔會開始影響。
似乎可以先只選用第一個好處的做法，只在初始化的時候生成排序和隨機起點。

其他神祕數字我還在思考，暫時還沒有頭緒。

[chia7712]

SWRR算法的時間複雜度是O(n),n爲節點數量，

這個假設之後可能要修正，因為之後要開始考慮同一個節點上的“不同”硬碟後，所謂的n會變成partitions數量，換言之，那個量級會比節點數量大很多

[chia7712]

@wycccccc 感謝幫忙拆成小的PR，幾個意見請看一下

[chia7712]

@wycccccc 你剛剛推了一個空白檔案上來，記得移除掉

[wycccccc]

這個假設之後可能要修正，因為之後要開始考慮同一個節點上的“不同”硬碟後，所謂的n會變成partitions數量，換言之，那個量級會比節點數量大很多

那可能就需要升級成vnswrr了，不過我感覺這個在換成partition打分的時候再升級就好。

[chia7712]

那可能就需要升級成vnswrr了，不過我感覺這個在換成partition打分的時候再升級就好。

沒錯，這個就交給 @chinghongfang 來負責了XDD

[wycccccc]

已按照學長給的建立，移除了不需要的程式碼，修改成了同步方法，添加了EffectiveWeightResult，不過我沒有把currentWeight包進取因爲它並不是每10秒算一次，而是每次選取都會改變。
再麻煩學長review了

[wycccccc]

我準備對那個調整分數的數值做以下修改。
現在是對負載分數做標準分數，但我準備換一個方法，原因在於標準分數只能體現分數與平均值相差了幾個標準差。而標準差的大小會掩蓋他們與平均值真正的差距。
首先調整初始effective weight統一都爲1,然後在0～2之間波動。之前的1/N不禁不直觀還很難在它之上做操作。

現在直接對負載分數做歸一化處理：定義爲B
假設有N個Broker：其中一個節點的偏移率計算爲：(B-（1/N））/（1/N）記爲rB
然後effective weight的變化就變爲：
該Broker的effective weight*（1+rB）
這樣做的物理意義爲，如果負載分數相比平均高了10%那麼我們就給他相比於之前多10%權重，這會讓他在接下來接收到比它之前平均多10%左右的資料。

我認爲這樣修改會比較直觀，唯一的問題在於嘗試將負載偏移率與資料偏移量劃等號這件事是否有其合理性。我感覺沒有感覺到不合理的地方。

[chia7712]

現在是對負載分數做標準分數，但我準備換一個方法，原因在於標準分數只能體現分數與平均值相差了幾個標準差。而標準差的大小會掩蓋他們與平均值真正的差距。
首先調整初始effective weight統一都爲1,然後在0～2之間波動。之前的1/N不禁不直觀還很難在它之上做操作。
現在直接對負載分數做歸一化處理：定義爲B
假設有N個Broker：其中一個節點的偏移率計算爲：(B-（1/N））/（1/N）記爲rB
然後effective weight的變化就變爲：
該Broker的effective weight*（1+rB）
這樣做的物理意義爲，如果負載分數相比平均高了10%那麼我們就給他相比於之前多10%權重，這會讓他在接下來接收到比它之前平均多10%左右的資料。
我認爲這樣修改會比較直觀，唯一的問題在於嘗試將負載偏移率與資料偏移量劃等號這件事是否有其合理性。我感覺沒有感覺到不合理的地方。

這邊是在討論當broker評分有變化時，effective weight該怎麼跟著變化，這樣理解對嗎？

如果我的理解對的話，現在的邏輯針對每次的評分變化有兩個“稀釋”的動作：

1. 只在固定週期後才會變更effective weight，也就是periodic在做的事情
2. 不完全依賴“現在”的broker評分，反而是在過去的評分上做比例上的調整

這兩者結合起來是想要避免什麼風險？直覺像是在說我們想避免大幅度的轉向，因此我們不頻繁變更effective weight，同時就算要變也只變一些些？

[wycccccc]

這邊是在討論當broker評分有變化時，effective weight該怎麼跟著變化，這樣理解對嗎？

對的

只在固定週期後才會變更effective weight，也就是periodic在做的事情

關於effective weight 是在重複以下流程：
變更effective weight -> 叢集負載產生變化 -> 收集到叢集負載變化後的metrics -> 變更effective weight

週期收集這件事更像是在確保我收集到的metrics計算出的負載分數，是有確切受到我上一次變更effective weight的影響

不完全依賴“現在”的broker評分，反而是在過去的評分上做比例上的調整

這一點是在於是上一次的effective weight產生的資料分配情況，導致了這次的負載分數。因爲它按照了我們給的模式發資料，所以我才得到了這個分數。因此調整建立在上一次的effective weight上就是這個理由。

這兩者結合起來是想要避免什麼風險？直覺像是在說我們想避免大幅度的轉向，因此我們不頻繁變更effective weight，同時就算要變也只變一些些？

其實這個做法更像是嘗試根據負載狀況進行調優，調整過後會看看大家有沒有變好，再做調整。
避免的風險可能在於，頻繁的調整，我們的這次分數可能無法對應到我們上次調整的結果。因爲他需要跑上述流程。如果僅僅只根據分數實時調整，不僅可能會有波動很大，而且因爲是過去全局所以我們總是慢一步。而收集叢集一段時間的資訊更能一定程度表現叢集當前的狀況，而不只有過去。

[wycccccc]

修改完畢，再麻煩學長了。

[chia7712]

@wycccccc 感謝耐心，整個看起來還不錯，測試跑過就合併，接著去下一隻PR討論