Как вы относитесь к сообщениям, выходящим из строя в очереди сообщений?

Question

Однажды меня спросили на собеседовании, как бы вы поступили с сообщениями, поступающими не по порядку в очереди сообщений. Прошло какое-то время, и я не нашел однозначного ответа, и мне было интересно, может ли эксперт в этой области помочь мне ответить на него, чтобы решить мое собственное любопытство.

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

Учитывая все это, мне интересно, как можно смешать один адресзаказ в традиционной системе обмена сообщениями, такой как AMQP, JMS или RabbitMQ, где десятки устройств IOT могут отправлять сообщения, и я, как потребитель, хочу согласовать их в правильном порядке.

Answer 1

Если очередь, которую использует ваша система, предоставляет гарантированную гарантию сообщений, то просто используйте этот канал (например, отдельный раздел kakfa, AMQP при некоторых настройках). Но если очередь, используемая вашей системой, не обеспечивает строгое упорядочение , то общая идея заключается в том, что клиент может иметь монотонно увеличивающееся число [1] (или метку времени), прикрепленное к каждому сообщению, которое он отправляет в очередь,Это формирует основу последовательности, которую производитель намеревается отправить своим получателям.

Как получить монотонно возрастающее значение:

Использование отметки времени: POSIXФункция clock_gettime () с CLOCK_MONOTONIC [2] предоставляет возможность получать монотонно увеличивающуюся временную метку, которую производитель может использовать для установки временной метки в каждом сообщении. Получатель может идентифицировать сообщения, не соответствующие порядку, когда он обнаруживает, что полученное сообщение имеет отметку времени старше, чем последнее сообщение.

Используя порядковый номер: Перед отправкой каждого сообщения вы можете просто увеличить атомный счетчик и прикрепить счетчикзначение для каждого сообщения, чтобы получатель мог знать о предполагаемом заказе. Это сформирует строго возрастающую последовательность. Подход очень похож на логические часы Лампорта [3], которые предоставляют виртуальные часы для производителя.

Работа с сообщениями о выходе из строя на стороне получателя: Это в значительной степени зависит от приложения, но в целом выесть два варианта, когда сообщения приходят не по порядку: а) отбрасывать старое сообщение, как в случаях, когда получатель должен показывать последнее значение запаса. b) Наличие буфера для изменения порядка последовательности, как в соединении TCP (например, zookeeper использует TCP в качестве очереди для упорядочения FIFO [4-5])

Инструменты: Если вы не добавляете метку времени всообщения, затем отправьте все сообщения в Apache kafka single partition в последовательности от производителя, так как это обеспечит получение получателем сообщений в последовательности.

Если вы используетесистема обмена сообщениями, которая не гарантирует заказанную доставку (например, AMQP при некоторых настройках [6]), тогда вы можете рассмотреть возможность добавления дополнительного монотонно увеличивающегося числа / часов с каждым сообщением.

[1] https://en.wiktionary.org/wiki/monotonic_increasing#targetText=Adjective,contrast%20this%20with%20strictly%20increasing

[2] https://linux.die.net/man/2/clock_gettime

[3] https://en.wikipedia.org/wiki/Lamport_timestamps#Lamport's_logical_clock_in_distributed_systems

[4] https://cwiki.apache.org/confluence/download/attachments/24193445/zookeeper-internals.pdf?version=1&modificationDate=1295034038000&api=v2

[5] http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf

[6] RabbitMQ - Сообщение о доставке

Answer 2

Я могу ответить относительно Apache Kafka. Apache Kafka гарантирует строгий порядок тем по разделам, то есть каждый раздел представляет собой неизменную последовательность сообщений, добавляемых в строгом порядке. Таким образом, в случае, если более одного потребителя раздела могут потреблять сообщения из более чем одного раздела, который не может быть в строгом порядке. Мы можем рассмотреть вариант ниже 2 для достижения строгого порядка.

1. Если вы ищете 1 сообщение производителя производителя, используйте только 1 раздел на тему. поэтому производитель будет публиковать на том же разделе в последовательности oder, которая будет потребляться потребителем в строгом порядке.

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