Одной из основных характеристик службы очереди сообщений, включая RabbitMQ, является сохранение порядка публикации сообщений.Это подтверждается в документации RabbitMQ :
[QUOTE 1] Раздел 4.7 основной спецификации AMQP 0-9-1 объясняет условия, при которыхпорядок гарантирован: сообщения, опубликованные в одном канале, проходящие через один обмен, одну очередь и один исходящий канал, будут приниматься в том же порядке, в котором они были отправлены.RabbitMQ предлагает более строгие гарантии с момента выпуска 2.7.0.
Предположим в дальнейшем, что нет активных потребителей, чтобы упростить вещи.Мы публикуем по одному каналу.
Пока все хорошо.
RabbitMQ также предоставляет возможность сообщить издателю, что определенная публикация была полностью и правильно обработана [*].Это объясняется здесь .По сути, брокер отправляет сообщение basic.ack
или basic.nack
.Документация также гласит:
[QUOTE 2] basic.ack
для постоянного сообщения, направленного в длительную очередь, будет отправлено после сохранения сообщения на диске.
В большинстве случаев RabbitMQ будет подтверждать сообщения для издателей в том же порядке, в котором они были опубликованы (это относится к сообщениям, опубликованным на одном канале).Однако подтверждения издателя генерируются асинхронно и могут подтверждать одно сообщение или группу сообщений.Точный момент, когда отправляется подтверждение, зависит от режима доставки сообщения ( постоянный против временного ) и свойств очереди (ей), в которую сообщение было перенаправлено (см. Выше).То есть разные сообщения можно считать готовыми к подтверждению в разное время.Это означает, что подтверждения могут поступать в другом порядке по сравнению с их соответствующими сообщениями.Приложения не должны зависеть от порядка подтверждений, когда это возможно.
На первый взгляд, это имеет смысл: сохранение сообщения занимает гораздо больше времени, чем просто сохранение его в памяти, поэтому вполне возможно, что подтверждениеболее позднего переходного сообщения прибудет до подтверждения более раннего постоянного сообщения.
Но, если мы перечитаем первую цитату, касающуюся порядка сообщений [QUOTE 1] здесь выше, оно получитсбивает с толку.Я объясню.Предположим, мы отправляем два сообщения на один и тот же обмен: сначала постоянное, а затем временное сообщение.Поскольку RabbitMQ утверждает, что сохраняет порядок сообщений, как он может отправить подтверждение второго / временного сообщения, прежде чем он узнает, что первое / постоянное сообщение действительно полностью записано на диск?
Другими словами, делает ли замечание относительноНелогичный порядок подтверждения [QUOTE 2] здесь выше применяется только в том случае, если каждое из двух сообщений направляется в совершенно разные целевые очереди (например, если они имеют разные ключи маршрутизации)?В этом случае мы не должны ничего гарантировать, как это сделано в [QUOTE 1] .
[*] В большинстве случаев это означает «в очереди»,Однако, если нет применимых правил маршрутизации, он не может быть поставлен в очередь в целевой очереди.Тем не менее, это все еще положительный результат в отношении подтверждения публикации.
обновление
Я прочитал этот ответ на аналогичный вопрос.Это в основном говорит о том, что нет никаких гарантий вообще.Даже самая наивная реализация, где мы откладываем публикацию сообщения 2 до того момента, когда мы получили подтверждение сообщения 1, может не привести к желаемому порядку сообщений.По существу, [QUOTE 1] не выполнено.
Это правильно?