Потребители AMQ выбирают, какую очередь обрабатывать

Учитывая следующий сценарий:

У меня есть система, которая создает, обновляет и удаляет записи. Для каждого из этих действий мне нужно что-то сделать (скажем, записать события в журнал в качестве глупого примера), однако мне нужно обработать эти события для каждой записи по порядку - это означает, что я не могу зарегистрировать удаление, пока не сделаю create или любое из предыдущих обновлений. Я также не могу зарегистрировать обновление, пока не зарегистрирую создание.

Я исследую очереди, чтобы сохранить последовательность. Однако я действительно не хочу, чтобы RecordID_2 задерживался за RecordID_14. Записи не нужно обрабатывать последовательно, в отличие от действий над каждой записью. Следовательно, я не думаю, что могу / должен использовать одну очередь.

Поскольку у меня нет сотен активных записей RecordID_XX одновременно, я думал о наличии очереди для каждого RecordID_XX, поэтому, если для этого одного RecordID может быть несколько обновлений, каждое событие для этой записи будет добавлено в ту же очередь и обработано. по порядку (т. е. сначала создание, обновление_1 после завершения создания, обновление_2 обрабатывается после завершения обновления_1 и т. д.), однако, если появились дополнительные события для другой записи, они будут добавлены в свою собственную очередь. Если очередь пуста какое-то время, она просто получает удалено. Я понимаю, что это может привести к тому, что очередь получит одно сообщение, а затем будет удалена, поскольку не было обновлений до истечения времени ожидания простоя. (Это не кажется эффективным)

На основе Андрес Т Финнелл отличный ответ на этот вопрос.

Я думал о следующем

Producer (Web Service) -> Queue_Original <- Dispatcher  -> RecordID_14 
                                                        -> RecordID_2 
                                                        -> RecordID_8
                                                        -> RecordID_15

Некоторые из «журналов» могут занять много времени. Поэтому я хочу, чтобы несколько потребителей слушали эти очереди.

Допустим, у меня есть Consumer_1 и Consumer_2 (я могу добавить Consumer_3 позже, чтобы помочь с растущей нагрузкой)

Я бы хотел, чтобы Consumer_1 сделал getDistinations () где брокер вернет [RecordID_14, RecordID_2, RecordID_8, RecordID_15]

Вопросов:

• Может ли Consumer_1 выполнить итерацию по списку очередей, возвращаемых брокером, в поисках первой доступной очереди, к которой не подключен Consumer_X, и начать обработку 1-го сообщения в этой очереди?
• А затем каждый последующий Потребитель делать то же самое, пока не найдет следующую очередь без подключенного Потребителя?

• Подойдет ли здесь Консультативные сообщения?

• Я полностью ошибаюсь? Есть ли лучший подход справиться с этим сценарием?