我們有一個應用程序需要將作業分配給資源。這些資源具有許多屬性，這些屬性定義了它們對特定工作的適用性 - 其中一些屬於偏好，一些屬於嚴格的約束條件（所有成員資格多樣，例如「資源A適合於具有X，Y或Z顏色的工作」。作業隊列優化算法
資源具有與它們（他們花費上線時間）我們要招資源的能力相關的成本 - 這需要時間變量量，我們可以招募的時間以固定間隔
。想了解規模：任何時候都會有大約20個資源，100個未完成的工作，完成工作需要5-15秒，招募一個資源需要1-2分鐘，我們可以從1- 30分鐘的時間（允許重新招募）。也許，我們對提交的工作沒有太多的提醒幾秒鐘。
目標是完成具有給定平均延遲（作業完成時間）的最低成本（資源使用情況）的作業。
我很欣賞指向算法，軟件庫或解決此問題的方法的指針。
可能想查看knapsack problem或bin packing問題，因爲這些問題與您在此處嘗試執行的操作原則上相似。
在您的問題描述中，您提到目標是完成具有最低延遲的作業。如果這實際上是您唯一的目標，那麼解決方案很簡單 - 聘請所有可用資源。它們中的很多會在很長時間內閒置，但它幾乎可以保證儘可能低的延遲。
我懷疑你的真正目標是儘可能地減少延遲和空閒資源，所以在這裏玩遊戲時總是會有延遲和浪費資源之間的折衷。
我會以這種方式來看待它...不知道它是否涵蓋了所有內容。
1）「資源」實際上可以被視爲「工作中心」。您有多少工作中心可以在「工作」上工作，與誰登錄系統有關。
2）通過等待時間分配資源 - 他們一直等待工作的時間越長，他們應該在下一個請求列表中的位置越高。那樣沒有人變冷或變慢。你必須找到並設定一個門檻（相對於資源和工作）。您可以決定是否希望他們點擊接受他們的下一份工作，或者讓系統自動獲得一份工作
3）設置作業計劃隊列 -我不知道它是否相關，但可能存在高/低優先級的作業等。您需要一個「按攻擊順序」列出的作業池。工作時間表上的每項工作都可以經歷不同的階段，因此您可以知道所有事情都在哪裏，並知道何時完成下一個工作。作業調度程序將查找可用資源並將其分配給計劃中的作業。這可能是您調度系統的大部分大腦。
我只是希望你不是建立一個呼出呼叫中心：P
這感覺就像一個幾件事情：經濟訂貨量，以平衡成本運行前期的招聘成本; LP或IP，最大限度地減少受各種限制的總成本公式;然後有概率分佈（招聘時間;所需的工作資源？），使整個事情隨機。
這聽起來非常複雜，如果我這樣做，我可能會建立一個模擬。系統似乎不太複雜，或者數學上太麻煩，無法運行大量迭代或長時間運行，所以您可以獲得一些相當穩定和有用的結果。
我不知道有關這類問題的文獻。不過，我認爲有一些，因爲排隊理論是一個大的學術領域，這聽起來不像是一個荒謬的人爲的情況。請注意，事實上你關心的是平均等待時間，而不是最差情況等待時間或第N個等待時間等待時間，這可能會使你處於少數。
我的第一個直覺是，由於似乎周圍有很多工作，一個好的解決方案將會有幾個「靈活」的工作人員連續工作。這是一組工人，他們之間可以完成大多數類型的普通工作，並具有可接受的等待時間。你想要延遲的時間越短，這個集合中的資源就越多，他們花費的時間就越多。此外，您輸入的「突發」越多（假設突發不可預知），您需要的空閒時間越多，以防止突發期間的高延遲。
然後在兩種情況下，你僱用更多的「專業」人員：
1）一種罕見類型的工作中來，您的當前設置員工可以在高時間成本只處理或根本沒有。所以你僱用（粗略地說）誰可以改變它，然後儘可能地做好剩餘的隊列。
2）沒有這樣的工作，但你找到一個機會僱用一個恰好能夠從當前隊列中取出一些工作組合的人，並且他們比你當前的工作人員更便宜，但是沒有離開你目前僱用閒置。所以你聘請了這個資源。
至於實際算法：找到最佳解決方案几乎肯定不是計算上可行的，所以正確的答案取決於處理資源，並且您正在尋找啓發式算法並解決部分問題。只要你僱用的每個人都很忙，而且你不能僱用其他人而不會在未來某個時候導致大量的空閒時間，那麼你可能就在一個很好的解決方案附近，並且在某個地方接近「 「延遲/成本折衷點。在此之後僱用更多的資源會帶來收益遞減，但這並不意味着您不願意爲特定的延遲和/或指定的預算執行此操作。
但它取決於傳入工作的樣子：如果您有一種資源只能執行一種類型的工作，並且該工作只能每天/每週/每年進行一次，那麼最好聘用他們一次一天只能等到你有足夠的工作來填補他們最小可能的時間片（這就是爲什麼消防隊員花大部分時間玩紙牌遊戲，而打字員花大部分時間打字。總是有足夠的打字來保持至少一個打字員很忙，但是火很少見，而且我們不希望火災的「最大爆炸」解決方案，我們想要比這更低的延遲）。因此，如果您正在解決某個特定的問題實例，而不是編寫通用調度軟件，那麼可能有機會針對您的特定資源和傳入作業模式調整算法。
加上大概是如果資源是人類，你實際上不能保證招聘成功。他們不會一整天坐在旁邊，只是在一分鐘的時間內工作，是嗎？
恐怕我沒有一個簡單的答案給你，但這裏有一些更多的相關資源來梳理思路。
真棒！問題
我會研究動態規劃，線性優化和排隊理論。不幸的是，我沒有真正簡單的方法來回答這些問題。我沒有必要的數學專業知識來爲您提供這些事情的最佳答案。然而，如果你熱衷於這樣的事情，這聽起來像是一個機會，通過使用人工智能算法得到一個好的，但可能不是最優的解決方案。我會推薦一個遺傳算法或模擬退火爐。這兩種代碼都不需要很長時間。這個想法是，你選擇隨機的，有效的投入，你可以調整這些潛在的解決方案，隨着時間的推移將它們演變成更好的（或自動挑選新的）解決方案。這些是在獲得最佳答案和永遠花費代碼並證明正確性之間的妥協。
這聽起來非常像Real-Time Operating System調度。維基百科詳細一些時使用的算法：
- 協同調度
- round-robin調度
- 搶佔式調度
- 固定的優先級先發制人調度，一個實施 搶先分時
- 臨界區搶佔式調度
- 靜態實時調度
- 最早時限的方法使用隨機和MTG
的一點想法
如果是這樣，比你可以從一開始就減少一些複雜的，然後使用某種形式的偏好加權平均。另外，當你招募時，自從分鐘。你可以招募30分鐘，並假設他們的成本較高，你可能想確保他們的利用率最高。
這裏的一些文章，可能會幫助：
一張紙條上面的數值，他們不是硬性約束，而是平均值。 – sehugg 2009-06-23 15:01:45
哦，工作有確定的優先級（只有幾個）。我現在閉嘴:) – sehugg 2009-06-23 15:07:50
我不完全明白。 「等待時間」是指工作等待時間還是未使用的資源容量？如果前者只是招募儘可能多的資源，你就可以得到你的手。如果是後者，則爲每個適用性的硬限制僅招募一個資源。是否有一塊失蹤或我只是誤解了這個問題？ – 2009-06-23 15:27:20