2012-07-10 167 views
0

我正試圖在此刻實現負載平衡器,並且遇到了一點速度顛簸。情況如下(簡化的),使用共享優先級隊列進行負載均衡

  • 我有請求的隊列queue_a其通過worker_a
  • 處理有其通過worker_b處理的請求queue_b的第二隊列
  • 我有請求queue_c,可以去任何工人的3隊列

這種設置的原因是每個工作人員都有唯一的請求,只有它可以處理,但也有任何人都可以處理的一般請求。

我打算使用IntervalHeap的C5的3個實例來實現這個功能。每個工作人員都可以訪問其本地隊列+它所屬的共享隊列(例如,worker_a可以看到queue_a & queue_c)。

這個想法的問題是,如果在本地隊列中有一個請求,並且共享隊列中的請求具有相同的優先級,那麼不可能知道哪一個應該先被處理(IntervalHeap通常是當這種情況發生時,先到先服務)。

編輯:我發現IntervalHeap似乎先來先-服務器相同的優先級的請求!

我想盡量減少隊列中的鎖定,因爲它會有相對較高的吞吐量和時間敏感性,但目前我能想到的唯一方法會涉及更多的複雜性,其中第三個隊列被刪除並共享請求放入queue_a和queue_b中。當請求被吸收時,它會知道這是一個共享請求,並且必須從其他隊列中刪除它。

希望能夠解釋清楚!

+1

查看TPL數據流,它爲您陳述的問題提供了通用解決方案。在這種情況下,您可能不得不放棄C5的使用 – Polity 2012-07-10 05:55:24

+0

您是否還有關於此的更多信息?例如,我如何在這種情況下使用TPL?我已經GOOGLE了一下,但目前還不清楚如何在我的情況下使用它 – mike 2012-07-10 08:10:33

回答

1

看來你最終會推動泡沫 - 無論你如何安排它,在最糟糕的情況下,你會有三件同樣優先的事情只由兩名工作人員執行。什麼樣的平局標準可以超越優先級來應用,以便選擇從哪個隊列中抽取下一個任務?

這裏有兩個想法:

  1. 隨機挑選的隊列。所有優先事項都是平等的,所以選擇哪一個都不重要。在最糟糕的情況下,所有隊列的平均維修費用大致相同。

  2. 通過從具有最多元素的隊列中取出來使隊列長度最小化。如果一個隊列的填充率一直高於其他隊列,這可能會導致其他隊列的捱餓。

HTH

+0

是的每個解決方案似乎都有侷限性。我想到了共享隊列將一種令牌插入其他隊列以表示可用工作的情況。當員工在本地隊列中看到這些令牌時,他們會嘗試從共享隊列中獲取請求。如果它不再存在,他們就繼續。否則它正常處理。如果您在大量其他隊列中共享隊列,這隻會引入開銷,因爲每個隊列都需要檢查每個共享隊列請求。 – mike 2012-07-10 08:26:36

+0

我不同意這個答案。私人和共享項目之間肯定存在優先區別。這一切都取決於不同隊列的狀態。看到我的答案。 – Polity 2012-07-11 02:51:21

+0

@Polity OP明確指出隊列前面的項目優先級是相等的。說私人隊列的優先級較高可能是解決問題的完全有效的方式,但不是原始問題支持的價值判斷 - 基本上歸結爲:我有兩個同等重要的事情要做,但只有一個工人 - 它應該選擇哪一個?需要一些打破平局的機制,並且在衆多選擇中,選擇私人隊列不會比選擇隨機或選擇最長隊列更有效。 – 2012-07-12 05:27:46

1

同步你的員工可以共享同樣的資源池,以及他們的私人隊列。在隊列1中可用的項目和共享隊列中可用的項目1中,如果工作人員1首先拾取共享隊列的項目,這將是一個恥辱,因爲這會限制並行運行。相反,你希望工人1先拿起私人物品,然而這會導致新的警告,其中一個是工人1和工人2都忙於處理私人物品,因此舊的共享物品將不會被拾取。

尋找解決這些問題的解決方案在試圖降低複雜性時將會非常困難。一個簡單的實現只是在專用隊列爲空時處理共享項目。這不會解決在高負載情況下不能正確處理優先級的部分。 (例如,由於專用隊列總是滿的,共享隊列不會被處理)。爲了平衡這一點,只有在其他員工私人隊列爲空的情況下,纔可能首先處理私人隊列。這仍然不是一個完美的解決方案,因爲這仍然會優先於專用隊列項目而不是共享項目。再次解決這個問題可以通過設置多種策略來實現,但是這會帶來更多的複雜性。

這一切都取決於您的要求。

+0

我目前實現它,所以共享隊列不是一個隊列,而是更多的查找列表。當共享隊列接收到工作時,它將工作放入所有底層隊列中,並帶有一個特殊標誌來指示它是共享工作。當工作人員接收到具有這些特殊標記的工作負載時,它將檢查共享隊列以確保仍需要完成工作。如果它不再有效,它會丟棄並抓取隊列中的下一個項目。如果有效,它會繼續處理它。這會導致一些額外的檢查發生,但維護我之後的功能。 – mike 2012-07-12 04:34:18