Очередь: от N производителей до N потребителей - PullRequest
Новая
       52

Очередь: от N производителей до N потребителей

1 голос
/ 23 февраля 2012

Требуется следующее:

  • Существует N производителей, которые генерируют сообщения или задания или как вы хотите их называть.
  • Сообщения от каждого прокурора должны обрабатываться впорядок и каждое сообщение должно быть обработано ровно один раз.
  • Есть еще одно ограничение: в любое время для любого данного производителя должно быть не более одного обрабатываемого сообщения.
  • Сторона-потребительсостоит из ряда потоков (они идентичны по своей функциональности), которые распределены по ряду процессов - это приложение WSGI, запущенное через mod_wsgi.

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

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

1 Ответ

2 голосов
/ 23 февраля 2012

Есть много продуктов, которые делают то, что вы ищете. Люди с опытом Django, вероятно, скажут вам «сельдерей», но это не полный ответ. Celery - (полезная) оболочка для реальной системы очередей, и использование оболочки не означает, что вам не нужно думать о лежащей в основе технологии.

ZeroMQ, Redis и RabbitMQ - это несколько разных решений, которые приходят на ум. Есть конечно больше вариантов. Я совершенно уверен, что ни одно решение для организации очередей не будет поддерживать ваше требование «в любое время для любого конкретного производителя должно быть не более одного обрабатываемого сообщения» в качестве параметра конфигурации; вам, вероятно, следует выполнить это требование у производителя (т.е. не отправляйте задание № 2, пока не получите подтверждение того, что задание № 1 выполнено).

Redis - это не настоящая система массового обслуживания, а очень быстрая база данных с функциями pub / sub; вы не сможете использовать Redis pub / sub для выполнения требования «задание обработано ровно один раз», хотя вы можете использовать Redis pub / sub для публикации заданий одному подписчику, который затем помещает их в базу данных как список (очередь бедняка). Тогда ваши потребители атомарно вытянут работу из списка. Это сработает, если вы хотите пойти по этому пути.

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

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

...