Как гарантировать доставку сообщений с помощью сельдерея?

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

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

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

Глядя на Celery, похоже, что он поддерживает множество различных бэкэндов, некоторые из которых имеют больше функций, чем другие. Два самых популярных выглядят как redis и RabbitMQ, поэтому мне потребовалось время, чтобы изучить их подробнее.

RabbitMQ: поддерживает устойчивые очереди и кластеризацию, но проблема нынешней кластеризации заключается в том, что если вы потеряете узел в кластере, все сообщения в этом узле будут недоступны, пока вы не вернете этот узел в оперативный режим. . Он не реплицирует сообщения между различными узлами в кластере, он просто реплицирует метаданные о сообщении, а затем возвращается к исходному узлу, чтобы получить сообщение, если узел не запущен, вы являетесь S.O.L. Не идеально.

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

Redis: поддерживает чтение ведомого устройства, и это позволило бы мне создать резервную копию на случай чрезвычайных ситуаций, но он не поддерживает настройку мастер-мастер, и я не уверен, обрабатывает ли он активное аварийное переключение между мастером. и раб. Он не имеет тех же функций, что и RabbitMQ, но выглядит намного проще в настройке и обслуживании.

Вопросы:

  1. Как лучше всего настроить сельдерей, чтобы он гарантировал обработку сообщений.

  2. Кто-нибудь делал это раньше? Если да, не могли бы вы поделиться тем, что вы сделали?


person Ken Cochrane    schedule 05.07.2011    source источник
comment
Что касается аварийного переключения rabbitmq, ходят слухи, что скоро будет доступно что-то попроще!   -  person asksol    schedule 05.08.2011
comment
Redis может быть надежным, если вы установите параметр append_only. Но redis по-прежнему не поддерживает подтверждения сообщений, а это означает, что сообщение доставляется повторно, если работник его не подтверждает. Поддержка Celery redis эмулирует это, но только настолько хорошо, насколько это возможно на стороне клиента, что означает, что любое незапакованное сообщение может быть потеряно, если работник внезапно прервется или произойдет сбой питания. См. ask.github.com/celery. /faq.html#should-i-use-retry-or-acks-late   -  person asksol    schedule 05.08.2011
comment
Возможно, вам удастся избежать потери сообщений, если вы установите CELERY_DISABLE_RATE_LIMITS = True, установите CELERYD_PREFETCH_MULTIPLIER = 1, установите CELERY_ACKS_LATE = True и запустите соло-пул. Но пришлось бы это проверить.   -  person asksol    schedule 05.08.2011
comment
соло-пул может понадобиться, а может и не понадобиться (-P соло)   -  person asksol    schedule 05.08.2011
comment
@asksol спасибо за помощь, я проверю их.   -  person Ken Cochrane    schedule 05.08.2011
comment
Какая устойчивость вашего приложения к дублированию? Если вам нужна гарантированная доставка без дубликатов, все становится сложнее, чем если бы вы могли видеть каждое сообщение хотя бы один раз.   -  person Malcolm Box    schedule 07.09.2011
comment
Коробка @Malcolm В настоящее время у меня не может быть дубликатов.   -  person Ken Cochrane    schedule 08.09.2011


Ответы (5)


Многое изменилось со времен ОП! Теперь есть опция для высокодоступных очередей, или «зеркальных» очередей. Это довольно далеко от решения описанной вами проблемы. См. http://www.rabbitmq.com/ha.html.

person Chris Johnson    schedule 29.08.2013

Вы можете попробовать IronMQ, он отвечает вашим требованиям (надежность, высокая доступность и т. Д.) И является нативной облачной средой. решение, поэтому нулевое обслуживание. И для этого есть брокер Celery: https://github.com/iron-io/iron_celery так что вы можете начать использовать его, просто изменив конфигурацию Celery.

person Travis Reeder    schedule 01.03.2013
comment
Придется проверить, но, судя по тому, что я вижу, похоже, что он отвечает всем требованиям. Спасибо. - person Ken Cochrane; 02.03.2013

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

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

person Malcolm Box    schedule 07.09.2011
comment
Спасибо, вы знаете названия систем с распределенной системой очередей с высокими гарантиями долговечности и надежности? Я бы хотел их проверить. - person Ken Cochrane; 08.09.2011
comment
Amazon SQS - один из них. Других я не знаю, но Google, вероятно, ваш друг, теперь вы знаете, какой вопрос задать - person Malcolm Box; 08.09.2011
comment
Посмотрите на MQSeries и аналогичные продукты. - person michaelok; 06.10.2011

Я использовал Amazon SQS для этого предложения и получил хорошие результаты. Вы будете получать сообщение до тех пор, пока не удалите его из очереди, и это позволит увеличить ваше приложение до нужной вам высоты.

person varela    schedule 31.08.2011
comment
Amazon SQS работает медленнее по сравнению с redis и rabbitMQ, и я не думаю, что он работает с сельдереем, но могу ошибаться. - person Ken Cochrane; 01.09.2011
comment
Celery действительно поддерживает AmazonSQS, но этот пост не отвечает на вопрос. Гарантирован ли порядок сообщений? Можете ли вы гарантировать, что дубликаты не будут созданы / обработаны в распределенной системе и т. Д. - person Sam Redway; 27.07.2017

Можно ли использовать распределенную систему рендеринга? Обычно зарезервировано для высокопроизводительных вычислений, но многие концепции остаются неизменными. Попробуйте Qube или Deadline Render. Есть и другие решения с открытым исходным кодом. Все они имеют в виду аварийное переключение, учитывая высокую степень сложности и риск сбоя в некоторых рендерингах, который может занять несколько часов на один кадр последовательности изображений.

person rjmoggach    schedule 18.09.2011