Отдельный сервер для работников Resque

Question

Отдельный сервер для работников Resque

Я пытаюсь сегментировать несколько серверов для проекта Rails, и отчасти это развлекает идею изолировать работников Resque от их собственной системы. У меня уже есть Redis, но можно ли перевести работников Resque куда-либо еще? Нужно ли их привязывать к самому приложению?

Если это можно сделать, есть ли какие-либо общепринятые рекомендации или рецензии на эту тему? Если нет, то мне лучше просто добавить больше оперативной памяти на серверы приложений с работниками Resque?

Я планирую использовать бригадира для мониторинга всего этого и создания новых рабочих мест.

2

ubuntu ruby-on-rails ruby redis ruby-on-rails-3

Источник

cmhobbs 13 мар '12 в 03:16

1 ответ

Решение

Другие вопросы по тегам ubuntu ruby-on-rails ruby redis ruby-on-rails-3

Jeff Ferland 13 мар '12 в 03:49 2012-03-13 03:49 · Accepted Answer · 2012-03-13 03:49

Я пытаюсь сегментировать несколько серверов для проекта Rails, и отчасти это развлекает идею изолировать работников Resque от их собственной системы. У меня уже есть Redis, но можно ли перевести работников Resque куда-либо еще?

Я собираюсь сделать это немного более общим. Распространено ли размещение рабочих, обрабатывающих работу, на других машинах, чем в приложении? Абсолютно. Это то, что вы увидите практически в любой архитектуре обработки очередей заданий.

Нужно ли их привязывать к самому приложению?

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

Если это можно сделать, есть ли какие-либо общепринятые рекомендации или рецензии на эту тему?

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

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

Если нет, то мне лучше просто добавить больше оперативной памяти на серверы приложений с работниками Resque?

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