Ответ 1
Хорошо, давайте более подробно рассмотрим описанный выше сценарий. Я думаю, что важно вставить документацию непосредственно перед фрагментом вашего вопроса, чтобы предоставить контекст:
В разделе 4.7 основной спецификации AMQP 0-9-1 объясняется условия, при которых гарантируется порядок: сообщения, опубликованные в один канал, проходящий через один обмен и одну очередь, и один исходящий канал будет принят в том же порядке, в котором они были послал. RabbitMQ предлагает более надежные гарантии с момента выпуска 2.7.0.
Сообщения могут быть возвращены в очередь с использованием методов AMQP, которые параметр requeue (basic.recover, basic.reject и basic.nack) или из-за закрытия канала при сохранении неподтвержденных сообщений. Любой из эти сценарии привели к тому, что сообщения были запрошены в конце очередь для релизов RabbitMQ ранее 2.7.0. Из выпуска RabbitMQ 2.7.0, сообщения всегда хранятся в очереди в порядке публикации, даже в случае необходимости или закрытия канала. (выделено мной)
Итак, ясно, что RabbitMQ, начиная с версии 2.7.0, делает довольно резкое улучшение по сравнению с оригинальной спецификацией AMQP в отношении упорядочения сообщений.
С несколькими (параллельными) потребителями порядок обработки не может быть гарантирован.
Третий абзац (вставленный в вопрос) продолжает давать отказ, который я перефразирую: "Если в очереди есть несколько процессоров, больше нет гарантии, что сообщения будут обработаны по порядку". Все, что они говорят здесь, это то, что RabbitMQ не может игнорировать законы математики.
Рассмотрим линию клиентов в банке. Этот конкретный банк гордится тем, что помогает клиентам в том порядке, в котором они пришли в банк. Клиенты выстраиваются в очередь в очереди и обслуживаются следующими тремя доступными счетчиками.
Сегодня утром случилось так, что все три счетчика стали доступны одновременно, и к ним подошли следующие 3 клиента. Внезапно первый из трех счетчиков стал сильно болен и не смог закончить обслуживание первого клиента в очереди. К тому времени, когда это случилось, кассир 2 закончил с клиентом 2, а кассир 3 уже начал обслуживать клиента 3.
Теперь может произойти одна из двух вещей. (1) Первый клиент в очереди может вернуться к главе линии или (2) первый клиент может упредить третьего клиента, в результате чего кассир перестанет работать с третьим клиентом и начнет работу над первым. Этот тип предвосхищающей логики не поддерживается RabbitMQ и любым другим брокером сообщений, о котором я знаю. В любом случае, первый клиент на самом деле в конечном итоге не получает помощь сначала - второй клиент делает, будучи удачливым, чтобы получить хорошего, быстрого кассира с места в карьер. Единственный способ гарантировать клиентов помогает в том, чтобы один кассир помогал клиентам по одному, что может вызвать серьезные проблемы с обслуживанием клиентов для банка.
Надеюсь, это поможет проиллюстрировать проблему, о которой вы просите. Невозможно обеспечить, чтобы сообщения обрабатывались по порядку во всех возможных случаях, учитывая, что у вас несколько потребителей. Неважно, есть ли у вас несколько очередей, несколько эксклюзивных потребителей, разные брокеров и т.д. - нет способа гарантировать априори, чтобы на сообщения отвечали несколько клиентов. Но RabbitMQ сделает все возможное.