Советы по Python / Django и очередям сообщений - PullRequest
Новая
       29

Советы по Python / Django и очередям сообщений

42 голосов
/ 18 января 2009

У меня есть приложение в Django, которое должно отправлять большое количество писем пользователям в различных случаях использования. Я не хочу обрабатывать это синхронно в приложении по очевидным причинам.

Есть ли у кого-нибудь какие-либо рекомендации для сервера очереди сообщений, который хорошо интегрируется с Python, или они использовались в проекте Django? Остальная часть моего стека - Apache, mod_python, MySQL.

Ответы [ 9 ]

24 голосов
/ 19 января 2009

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

Что касается более общих решений очереди, я еще не смог попробовать ни одно из них, но вот список тех, которые выглядят мне более интересными:

  1. pybeanstalk / beanstalkd
  2. интерфейс python для gearman (что, вероятно, гораздо интереснее сейчас с выпуском C версии gearman )
  3. memcacheQ
  4. топают
  5. Сельдерей
14 голосов
/ 18 января 2009

Пока что я не нашел "хорошего" решения для этого. У меня есть более строгие требования в реальном времени (сделать снимок из картонной коробки с надписью), поэтому, вероятно, один из подходов достаточно быстр для вас. Я предполагаю, что электронные письма могут подождать несколько минут.

  • «Список задач» в базе данных, обработанный заданием cron.
  • «Список задач» в базе данных, обработанный постоянно опрашиваемым демоном.
  • Использование настраиваемого демона, который получает уведомление от веб-сервера через пакет UDP (в производственной версии сегодня). В основном моя собственная система очередей со стеком IP для обработки очереди.
  • Использование ActiveMQ в качестве брокера сообщений - это не сработало из-за проблем со стабильностью. Также для меня Java-демоны, как правило, несколько пухлые
  • Использование триггеров обновления в CouchDB. Хорошо, но триггеры обновления не предназначены для интенсивной обработки изображений, поэтому не подходят для моей проблемы.

До сих пор я не пробовал RabbitMQ и XMPP / ejabebrd для решения проблемы, но они находятся в моем списке следующих вещей, которые нужно попробовать. RabbitMQ получил приличное подключение к Python в 2008 году, и существует множество библиотек XMPP.

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

6 голосов
/ 03 апреля 2009

Stompserver - хороший вариант. Это легкий, простой в установке и использовании от Django / python.

У нас есть система, использующая в работе stompserver для отправки электронных писем и асинхронной обработки других заданий.

Django сохраняет электронные письма в базе данных, обработчик model.post_save в Django отправляет событие в stompserver, а stompserver передает событие в потребительский процесс, который выполняет асинхронную задачу (отправляет электронное письмо).

Он очень хорошо масштабируется, потому что вы можете добавлять потребительские процессы во время выполнения - два потребителя могут отправлять вдвое больше электронных писем, а потребители могут находиться на отдельных машинах. Одним небольшим осложнением является то, что каждому потребителю нужна своя именованная очередь, поэтому Django должен знать, сколько потребителей доступно, и отправлять события в каждую очередь в циклическом порядке. (Два потребителя, прослушивающие одну и ту же очередь, оба получат каждое сообщение = дублирование). Если вам нужен только один потребительский процесс, тогда это не проблема.

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

1 голос
/ 20 мая 2011

http://www.snakemq.net/ может также работать

1 голос
/ 13 сентября 2010

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

1 голос
/ 18 апреля 2010

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

1 голос
/ 19 января 2009

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

0 голосов
/ 25 марта 2012

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

drop table if exists mailqueue;
create table mailqueue (
    id bigint primary key,
    subject text not null,
    body mediumtext not null,
    from varchar(255) not null,
    to varchar(255) not null
);

Отправители должны вставлять новые строки в конец этой таблицы.

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

0 голосов
/ 18 января 2009

Если у вас уже установлен MySQL, вы можете создать таблицу для использования в качестве «списка задач».

Потоки синхронно добавляют задания в таблицу, а пакетное задание удаляет задания по мере их выполнения.

Таким образом, нет необходимости устанавливать и изучать больше программного обеспечения, и оно должно работать как постоянное хранилище заданий, если вы не отправляете лотов сообщений электронной почты (например,> 10 / сек) .

...