Выбор MQ очереди

Необходимо выбрать MQ очередь или что-то, что можно использовать таким образом, в рамках следующих условий.

  1. Продюсеров и потребителей может быть десятки тысяч, при этом каждый из них свободно подключается и отключается. В моменты когда продюсер отключен от своего топика сообщения в нее просто не поступают, когда подключается - снова поступают. Когда потребитель подключается, то начинает получать сообщения с момента когда подключился (как auto-offset-reset=latest в Kafka)
  2. Порядок сообщений критично важен.
  3. Скорость доставки важна.
  4. Гарантия доставки критично важна.
  5. Новые продюсеры появляются постоянно и топики появляются вместе с ними. 1 продюсер = 1 топик.
  6. Сообщения не большие, это строки до 200 символов.
  7. Хранить их историю в хранилище очереди нет смысла так как они будут сохраняться в PostgreSQL. (Возможно какой-то in-memory вариант)
  8. Каждый потребитель получает все сообщения самостоятельно (Выражаясь терминологией Kafka group-id у каждого свой)
  9. Подключаемся из Java клиента.

Сценарии использования (все продюсеры и потребители десктопные клиенты)

  1. Новый продюсер регистрируется в системе и под него создается топик\канал к которому можно подключатся.
  2. Продюсер включает десктопный клиент и начинает раздачу сообщений. (Включается по кнопке начать трансляцию).
  3. Некоторые из пользователей узнав о новом продюсере решают стать его подписчиками и подключается к нему используя десктопный клиент, и получив id топика, получают сообщения пока не нажмут кнопку отключения от трансляции.

Учитывая требования к скорости и и количеству подключений напрашивается Kafka, но она гарантирует упорядоченность только в рамках партиции что вызывает сомнения в гарантиях доставки. Остальные очереди типа RabbitMQ и ActiveMQ не удовлетворяют требованиям по кол-ву подключений.

Возможно единственный выход это использовать Kafka, контролируя, что бы на 1 топик была только 1 партиция, или может есть другие решения которых я не вижу?


Ответы (0 шт):