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

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

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

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

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

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

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

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

Вопросы:

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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