Вы можете посмотреть на реализацию очередей приоритетов: https://www.rabbitmq.com/priority.html
Если это не работа для вас, вы можете попробовать другие хаки для достижения того, чего хотите:
У вас может быть 100 очередей, связанных с обменом темами и установить ключ маршрутизации на хэш идентификатора пользователя% 100, то есть каждая задача будет иметь ключ от 1 до 100, а задачи для одного и того же пользователя будут иметь один и тот же ключ. Каждая очередь привязана к уникальному шаблону между 1 и 100. Теперь у вас есть парк работников, которые начинаются со случайного номера очереди, а затем увеличивают этот номер очереди после каждого задания, снова% 100, чтобы вернуться в очередь 1 после очереди 100.
Теперь ваш рабочий флот может обрабатывать до 100 уникальных пользователей параллельно, или все рабочие могут сосредоточиться на одном пользователе, если нет другой работы. Если работникам необходимо перебирать все 100 очередей между каждым заданием, в сценарии, что только один пользователь имеет много заданий в одной очереди, вы, естественно, будете иметь некоторые накладные расходы между каждой работой. Меньшее количество очередей - это один из способов борьбы с этим. Кроме того, каждый рабочий может подключиться к каждой из очередей и потреблять до одного не подтвержденного сообщения от каждого. Затем рабочий может циклически перемещать ожидающие сообщения в памяти намного быстрее, при условии, что недопустимый тайм-аут сообщения установлен достаточно высоким.
В качестве альтернативы вы можете создать две биржи, каждая из которых имеет связанную очередь. Вся работа идет на первый обмен и очередь, которую потребляет пул рабочих. Если рабочая единица занимает слишком много времени, работник может ее отменить и нажать на вторую очередь. Рабочие обрабатывают вторую очередь только тогда, когда в первой очереди ничего нет. Возможно, вам также понадобится пара работников с приоритетной очередностью очередности, чтобы убедиться, что долго выполняемые задачи все еще обрабатываются, когда бесконечный поток коротких заданий прибывает, так что партия пользователей всегда будет обрабатываться в конечном итоге. Это не будет действительно распределять ваш рабочий флот по всем задачам, но это остановит длительные задачи от одного пользователя, удерживающего ваших сотрудников от выполнения коротких запущенных задач для того же самого пользователя. Он также предполагает, что вы можете отменить работу и повторно запустить ее позже без каких-либо проблем. Это также означает, что будут потрачены впустую ресурсы от задач, требующих тайм-аута, и их нужно повторно запускать как низкий приоритет. Если вы не можете заранее определить быстрые и медленные задачи
Первое предложение со 100 очередями также может иметь проблему, если для одного пользователя есть 100 медленных задач, а затем другие пользователи отправляют пакет задач. Эти задачи не будут рассмотрены до тех пор, пока одна из медленных задач не будет завершена. Если это окажется законной проблемой, вы можете объединить два решения.