При использовании RabbitMQ в процессе возникают бизнес-сценарии, требующие гарантированной последовательной обработки. Например, в ситуации, где требуется выполнить операции по добавлению, изменению и удалению данных на основе генерации трех сообщений, важно обеспечить порядок их обработки, так как неправильная последовательность может привести к нежелательным последствиям.
Как показано ниже:
Проблема последовательности сообщений в RabbitMQ требует рассмотрения с трех аспектов: порядок отправки сообщений, порядок сообщений в очереди и порядок обработки сообщений.
Порядок отправки сообщений
Для большинства бизнес-сценариев порядок передачи сообщений поставщиком не имеет строгих требований. Не имеет значения, кто отправляет сообщение первым. Если бизнес требует передачи сообщений в определенном порядке, это означает, что с глобальной блокировкой может быть отправлено только одно сообщение за раз, и сообщения не могут быть отправлены параллельно.
Порядок сообщений в очереди
В RabbitMQ сообщения в конечном итоге будут храниться в очереди. В пределах одной очереди сообщения упорядочены на основе принципа "первым поступил, первым ушел", что гарантируется RabbitMQ и обычно не требует особого внимания со стороны разработчиков.
Примечание: Порядок сообщений в различных очередях не гарантируется. Например, при входе на станцию метро, если вы встаете в одну из трех очередей, порядок входа в станцию не может быть гарантирован между различными очередями.
Порядок обработки сообщений
При обсуждении обеспечения последовательной обработки сообщений, обычно имеется в виду порядок, в котором потребители потребляют сообщения. В сценариях, где несколько потребителей потребляют сообщения из одной очереди сообщений, обычно невозможно гарантировать последовательность обработки сообщений. Как показано на открытой диаграмме, хотя сообщения в очереди упорядочены, несколько потребителей одновременно потребляющих сообщения, скорость извлечения сообщений, скорость выполнения бизнес-логики и возможные исключения выполнения могут привести к несогласованности последовательности сообщений.
Например: Сообщения A, B и C поступают в очередь последовательно. Потребитель A1 получает сообщение A, а потребитель B1 получает сообщение B. Однако, если потребитель B1 выполняется быстрее, он может завершиться раньше потребителя A1, или если потребитель A1 столкнется с ошибкой, обе ситуации могут привести к несогласованности последовательности сообщений.
Типичное решение проблемы последовательного потребления заключается в наличии только одного потребителя в очереди. Таким образом, сообщения могут быть обработаны по одному в определенном порядке. Однако, недостатком является уменьшение возможности параллельности и невозможность параллельного потребления сообщений. Это компромисс.
Примечание: Если бизнес требует последовательного потребления и увеличения параллельности, распространенным подходом является включение нескольких очередей. Бизнес может распределять сообщения по разным очередям на основе правил, тем самым увеличивая уровень параллельности. Например, в сценарии заказов электронной торговли достаточно обеспечить последовательность сообщений о заказах для одного пользователя. Сообщения, принадлежащие разным пользователям, могут быть направлены в разные очереди.