Я решил вылезать из пеленок и попробовать написать нечто большее хеллоуворолда.
Так вот есть у меня идея одного сервиса для работы с твиттером(взял tweepy). Мне придется частенько дергать апи твиттера, нужно будет выполнять задания по расписанию (отправить пачку твитов, обновить информацию по твиту, принять и обработать пачку твитов) и все это нужно делать по разным таймерам и для множества в данный момент активных задач. Ну и про запись в собственную бд забывать нельзя. Так же будет веб-морда которая собственно и позволяет ставить задачи на выполнение и смотреть за ходом событий (это будет джанга ибо это мой первый веб-проект вообще и я вот-вот уже дочитываю книжку по ней и ничего другого не знаю). И я так понимаю, что веб морда и сервер дергающий твиттер, это разные независимые приложения. Так вот, запрос к твиттеру занимает очень приличное время что как бы намекает мне на то что для реализации серверной части мне придется использовать какие-то многопоточные штуковины. Я в деле написания веб-серверов, многопоточности и прочем мягко говоря полный новичек :) В связи с чем хотел бы поинтересоваться технологиями которые мне можно будет применять в этом деле (пока я мельком глянул на gevent кажется то что надо), а так же литературу по этому всему счастью (например может есть какие статьи или даже книги по разработке серверных приложений ведь они отличаются от десктопных?!).

Всем кто дочитал до конца уже спасибо, буду рад любому совету, кроме как бросить это дело/найти работу/девушку/сменить профессию.

Ну Вы прям с козырей в веб-разработку заходите :)

ПМСМ использование gevent+django не самый лучший вариант для веб-морды. Так как gevent патчит socket модуль из стандартной библиотеки питона, а поэтому есть опасения, что какие-либо сторонние библиотеки будут работать некорректно и выдавать кучу трудноулавимых багов.

Возможно лучшим вариантом для веб-морды будет стандартный паттерн для реализации таких вещей - разделение работы между обычным веб-сервисом (тот же джанго), который возвращает страницы с условно неизменяющейся информацией (и в Вашем случае передача данных от пользователя в систему через стандартные запросы) и push-сервисом, который передает клиенту постоянно меняющиеся данные. По этому поводу есть хороший букварь - http://javascript.ru/ajax/comet/server-patterns там есть пример реализации как клиентской части, так и серверной (для питона - twisted + куча для других языков).

Также для веб морды очень хорошо может подойти tornado - это неблокирующий веб-сервер на основе epoll (как и gevent), но написание на нем веб приложений несколько отличается от джанги, хотя там все прозрачно. Плюсом tornado является то, что он никак не затрагивает стандартные библиотеки питона, реализуя работу с epoll самостоятельно.

По поводу организации взаимодействия между веб-мордой и “сервер дергающий твиттер” также возможны различные реализации:

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

- очереди сообщений на основе AMQP - есть две очень хорошие реализации RabbitMQ (медленная, но зато с гарантией сохранения данных при сбое сервиса) и ZeroMQ (очень быстрая, но данные при сбое сервиса теряются).

- очереди сообщений на основе redis - быcтрая in-memory БД с поддержкой паттерна PUBLISH/SUBSCRIBE - в последнее время этот подход сильно набирает популярность.

Организацию “сервера дергающего твиттер” можно сделать по разному. Самый простой способ - это использовать selery - он отлично работает с джангой и практически кроме него Вам вряд ли что-то понадобится. А если selery не понравится - то можно будет обсудить другие варианты. Единственно, хочется отметить, что selery ориентирован как раз на очередях AMQP.

Захожу круто потому что хочется освоить по максимуму нового-интересного и полезного в дальнейшем. Время свободное есть, я вроде тоже не дурак, так что хочу разбираться и делать :)

Похоже я не правильно понимаю для чего нужен gevent, я думал использовать его в демоне дергающем твиттер :)

Спасибо за пост пойду читать про все что вы накидали.

Я маленько почитал, поправьте меня если ошибаюсь, но кажется все что мне нужно можно сделать на одном лишь торнадо?

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

Если все так так я бы на нем и сделал все :)

UPD

А нет похоже нельзя.

Насколько я понял COMET сервер мне тоже не нужен.

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

То есть все обновления на странице происходят по запросу клиента. То есть все проще.

В связи со всем этим мне виделось создание двух отдельных программ-компонент, демона-сервера и морды. А сейчас я уже окончательно запутался.

Или я все усложняю?

ziro
1) не selery, а celery;
2) celery работает почти что на всём, не только на AMQP брокерах;
3) RabbitMQ не медленный, ZeroMQ из другой оперы, зачем их сравнивать?

Zubchick глянь в сторону Google App Engine, в плане инфраструктуры там всё что надо есть, и задачи по расписанию (крон), и очереди, и мемкэш. Можно будет посвятить больше времени написанию кода сервиса, а не заниматься экспериментами и администрированием этого зоопарка. Если GAE не подходит по религиозным причинам (а жаль), то тогда подойдет любой удобный способ запуска джанги + celery для выполнения отложенных задач + redis для кэширования и прочих нужд (его ещё и celery будет юзать).

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

Я извиняюсь, что ввел Вас в заблуждение с кометом - мне просто показалось из этой фразы “ставить задачи на выполнение и смотреть за ходом событий”, что Вы хотите видеть результаты в реальном времени - модно это нынче.

Вот по реализации рабочего процесса, который выполняет работу по твиттеру тогда возможны такие варианты:

1. Запуск рабочего процесса по крону (ну скажем раз в …цать минут). В этом случае как правило для очереди сообщений используют табличку в БД. Вебсервер в нее вносит записи о том, чего надо делать, а рабочий процесс при своем старте выгребает новые задачи, выполняет их и ставит в таблице отметку о выполнении.
Это самый простой вариант, но недостатком его является то, что работа может начаться сильно после ее постановки в очередь.

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

Против GAE я ничего не имею, но я с ним так же ни разу не работал, а по celery я уже начал читать доки + администрированние меня не пугает :)

Для каких нужд использовать редис помимо очереди? И как его использовать вместо memcached?
ЗЫ Я уже начал разбираться с rabbitMQ, но думаю труда перейти на редис не составит, если он правда хорош.

poltergeist
по GAE там будут проблемы с обработкой апи, думаю в лимиты не вложится, Twitter по API частенько выдаёт файло более 1мб ) Его надо скачать, обработать и сохранить, тут гугл обосрётся со свистом В)

Zubchick
всё зависит от сексуальных фантазий) можешь для сериализации как промежуточное хранилище данных, как счётчики, как кеш (вместо мемкешеда) по крайнеё мере я юзал редис для выливки Twitter данных по юзерам (вместо CSV файлов); только не забудь включить запись на диск