Репликация средства очереди задач AppEngine на EC2/Elastic Beanstalk

Я рассматриваю возможность перехода с AppEngine на EC2/Elastic Beanstalk, так как мне нужны мои серверы, расположенные в ЕС [AppEngine не предлагает вариант расположения сервера, насколько я знаю]. Я запустил тестовое приложение Elastic Beanstalk, которое, насколько это возможно, хорошо; однако одна из функций AppEngine, на которую я сильно полагаюсь, — это автономные очереди задач / средство cron, поскольку я периодически извлекаю много данных с других сайтов. Мне интересно, что мне нужно настроить на Elastic Beanstalk / EC2, чтобы воспроизвести это средство очереди задач, есть ли какие-либо передовые методы, сколько работы это займет и т. д.

Спасибо!


person Justin    schedule 25.03.2011    source источник
comment
Знаете ли вы о сервисе Simple Queue: aws.amazon.com/sqs.   -  person Calvin    schedule 25.03.2011
comment
Вам также может быть полезно ознакомиться с TyphoonAE (code.google.com/p/typhoonae).   -  person Robert Kluin    schedule 25.03.2011


Ответы (2)


Потенциальная проблема со службами cron в Beanstalk заключается в том, что данная запланированная команда может быть вызвана более чем одной службой, если приложение выполняется более чем на одном экземпляре. Необходима координация между работающими экземплярами Tomcat, чтобы гарантировать, что задания выполняются только одним, и что, если один из них умирает, служба cron не прерывается.

Как я это реализую, так это:

  1. Упакуйте задание cron «файл конфигурации» с файлом WAR. Этот файл должен содержать частоты и URL-адреса (поскольку каждый фактический cron — это просто вызов определенного URL-адреса, как это делает AE)
  2. Use a single database table to maintain coordination. It requires at least two columns.
    1. a primary or unique key which (string) to hold the command along with its frequency. (e.g. "@daily http://your-app/some/cron/handler/url")
    2. второй столбец, который содержит время последнего выполнения.

каждый экземпляр tomcat будет запускать поток cron, который должен считывать конфигурацию из WAR и планировать спящий режим столько, сколько необходимо, до следующего вызова службы. как только наступит время, экземпляр должен сначала попытаться «заявить» о вызове, сначала захватив время последнего вызова для этой команды из базы данных, а затем обновив его, чтобы получить «блокировку».

  1. query(SELECT last_execution_time FROM crontable WHERE command = ?)
  2. if(NOW() - last_execution_time < reasonable window) skip;
  3. query(UPDATE crontable SET last_execution_time = NOW() WHERE command = ? AND last_execution_time = ?)
  4. if(number of rows updated == 0) skip;
  5. run task()

Ключевым элементом здесь является то, что мы также включаем last_execution_time в предложение WHERE, гарантируя, что, если какой-либо другой экземпляр обновит его между тем, когда мы SELECT и UPDATE, обновление вернет, что никакие строки не были затронуты, и этот экземпляр пропустит выполнение этой задачи.

person Community    schedule 05.07.2011

Если вы перемещаете свое приложение, вам, вероятно, лучше просто использовать TyphoonAE или AppScale. Оба являются альтернативными средами, в которых вы можете запускать приложение App Engine без изменений, и оба поддерживают EC2.

person Nick Johnson    schedule 28.03.2011