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

Question

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

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

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

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

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

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

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

Вопросы:

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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