Выбор решения для очередей сообщений

  • 3 мин

Очереди службы хранилища и очереди служебной шины несколько отличаются наборами функций. В зависимости от потребностей конкретного решения можно выбрать один или оба варианта.

При выборе технологии очередей под конкретные цели и задачи архитекторам и разработчикам решений следует принимать во внимание приведенные ниже рекомендации.

Рассмотрите возможность использования очередей служебной шины

В следующих случаях архитекторам и разработчикам решений рекомендуется использовать очереди служебной шины:

  • Решение должно иметь возможность получать сообщения, не опрашивая очередь. С помощью служебной шины можно этого достичь, используя операцию получения с длинным опросом и протоколы на основе TCP, поддерживаемые служебной шиной.
  • В решении требуется, чтобы очередь гарантированно доставляла сообщения в порядке их добавления в очередь (FIFO).
  • В решении необходима поддержка автоматического обнаружения дубликатов.
  • Вы хотите, чтобы приложение обрабатывало сообщения как параллельные долговременные потоки (сообщения связываются с потоком с помощью свойства session ID сообщения). В этой модели каждый узел принимающего приложения конкурирует за потоки, а не за сообщения. Когда для принимающего узла выделяется поток, узел может проверить состояние потока приложения с помощью транзакций.
  • В решении требуется реализовать транзакционный режим работы и атомарность при отправке или получении нескольких сообщений из очереди.
  • Приложение обрабатывает сообщения, которые могут превышать 64 КБ, но, скорее всего, не подходят к ограничению в 256 КБ или 1 МБ в зависимости от выбранного уровня служб (хотя служебная шина очереди могут обрабатывать сообщения до 100 МБ).
  • Вам требуется обеспечить доступ к очередям на основе ролей, а также предусмотреть различные права или разрешения для отправителей и получателей.

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

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

  • Приложение должно хранить более 80 ГБ сообщений в очереди.
  • Нужно, чтобы приложение отслеживало ход обработки сообщения внутри очереди. Это полезно при сбое рабочего процесса, обрабатывающего сообщения. Другой рабочий процесс сможет использовать полученную информацию, чтобы продолжить обработку с того места, где произошел сбой предыдущего обработчика.
  • Вам требуются серверные журналы всех примененных к очередям транзакций.