2017-02-18 10 views
0

Я ищу наилучший подход для решения следующих задач:Heroku, RabbitMQ и многие работники. Какая лучшая архитектура?

У меня есть несколько пограничных устройств, публикующих данные датчиков для брокера RabbitMq. Брокер будет испытывать общую нагрузку ~ 500 сообщений в секунду. Затем есть рабочий динамик python, который потребляет один датчик за один раз, применяет к нему фильтр (который может занимать до 5-15 мс) и публикует результат на другую тему.

Конечно, одного работника недостаточно, чтобы обслуживать все запросы, поэтому мне нужно правильное масштабирование. Я использую очередь, чтобы убедиться, что каждое считывание датчика потребляется только один раз!

Мои вопросы:

  1. ли я масштабироваться горизонтально и просто начать столько динамометрические стенды, сколько необходимо для обработки всех запросов в очереди RabbitMQ? Кажется простым, но дорогим.

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

  3. Или имеется балансировщик нагрузки, который потребляет 1 элемент из очереди и динамически динамически динамически?

  4. Что-то совсем другое?

ответ

2

вариант 1 или 2 ваши лучшие ставки

я не думаю, что вариант 3 существует без привязки непосредственно в Heroku API, и писать тонны кода для себя ... но это излишеством для ваших нужд, IMO

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

вариант 1, как правило, является моим предпочтением, потому что я могу просто добавить новый экземпляр dyno и сделать это. занимает 10 секунд.

вариант 2 может работать, если вы не против настройки кода и перераспределения. это добавит дополнительное время и усилия для компромисса стоимости.

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

+0

Значит, это не пустая трата, чтобы один Dyno просто выполнял краткосрочный процесс python? Также в настоящий момент RabbitMQ как брокер отвечает за управление очередью и равномерно распределяет каждое сообщение потребителю, так что потребитель не получит одно и то же сообщение. Таким образом, нет необходимости в балансировке нагрузки, заботясь об этом праве? – binaryguy

+0

RabbitMQ заботится о балансировке нагрузки для вас. Имея несколько потребителей в одной очереди/прямом обмене, вы получаете балансировку нагрузки по умолчанию. Поскольку единственный Dyno просто выполняет краткосрочный процесс python, это рабочий, постоянно потребляющий новые сообщения для обработки, поэтому он всегда будет работать, если я не пойму ваш случай использования. – metame

+0

Да, вы правы. Я думаю, что нет необходимости в сельдере. Меня просто беспокоило, что такой простой процесс python может быть пустой тратой Dynos. В конце концов, этот подход может быть проще поддерживать, но, соответственно, более дорогостоящим из-за потребностей большего количества Dynos, работающих параллельно. – binaryguy