我建立一個多租戶應用程序，用戶可以提交至工（工人數量是動態的）來處理的任務批我想要實現的是以下幾點：共享工人的池RabbitMQ的
這樣的事情可能與工作隊列？ （出於某種原因，感覺就像一個轉折FIFO和隊列的想法，但是這是我的用例不管怎麼說：d）
你可以看一下優先級隊列實現：https://www.rabbitmq.com/priority.html
如果還是不行爲你工作，你可以嘗試一些其他的黑客實現你想要的：
你可以有100個隊列綁定到話題交換，並將路由關鍵字設置爲用戶ID％100的散列，即每個任務將有1到100之間的鍵和同一用戶的任務將具有相同的鍵。每個隊列與1和100之間的獨特圖案的結合現在你有一個隨機隊列號開始的工人組成的機隊，然後每增加作業後該隊列數量，再100％可循環回到隊列100後，排隊1。現在
你的工人艦隊能夠並行處理多達100個獨特的用戶，或者所有的工人可以專注於一個單一的用戶，如果沒有其他的工作要做。如果工作人員需要在每個作業之間遍歷所有100個隊列，在單個用戶在單個隊列中只有很多作業的情況下，每個作業之間自然會產生一些開銷。少量的隊列是解決這個問題的方法之一。您也可以讓每個工作人員與每個隊列保持連接，並使用每個隊列最多一個未確認的消息。只要未確認的消息超時設置得足夠高，工作人員就可以更快地循環訪問內存中的待處理消息。
另外，您可以創建兩個交易所，每一個綁定的隊列。所有的工作都進入第一次交換和排隊，這是一羣工人消耗的。如果一個工作單元花費太長時間，工作人員可以取消它並將其推送到第二個隊列。當第一個隊列中沒有任何內容時，工作人員只處理第二個隊列。您可能還需要一些具有相反隊列優先級的工作人員，以確保在存在永不停止的短任務流時仍處理長時間運行的任務，以便最終始終處理用戶批處理。這不會真正將工作人員分配到所有任務中，但它將阻止持有員工的長期運行任務，從而不會爲同一用戶執行短期運行任務。它還假定您可以取消一項工作，稍後重新運行而不會出現任何問題。這也意味着將會出現超時並需要重新運行爲低優先級任務的資源浪費。除非你能提前
識別快，慢任務，並具有100個隊列第一個建議也可能有問題，如果有單個用戶100級慢的任務，然後另一個用戶的帖子一批任務。直到其中一項緩慢的任務完成後，纔會查看這些任務。如果事實證明這是一個合理的問題，你可以結合這兩種解決方案。