среда, 4 сентября 2013 г.

Проектирование решений с использованием очередей?

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

Такие инструменты, как серверы ActiveMQ, RabbitMQ, MSMQ, JMS проверены временем и предназначены для надежного выполнения этих требований. У меня позитивный опыт использования данных инструментов для так называемых "happy paths" (максимально гладких вариантов). А вот в случае с "unhappy paths", независимо от инструментов, бывает достаточно тяжело спроектировать механизм восстановления после отказа.

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

Скорость обработки

Очереди по сути являются системой producer/consumer (производитель/потребитель) или pub/sub (вещание/подписка). То есть, медленный темп потребления приводит к скоплению сообщений.

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

Пути ошибки

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

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

Автоматизированный мониторинг

Автоматизированный мониторинг играет для любой очереди в промышленной системе решающую роль. Без мониторинга очередь рискует быть переполненной непотребляемыми сообщениями.

Вмешательство человека

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

Развертывания

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

Комментариев нет:

Отправить комментарий