Celery: Предложение отказаться от Redis в качестве поддержки брокера. [Отклоненный]

В настоящее время существуют альтернативы сельдерею, например huey и rq которые явно ориентированы на поддержку Redis в качестве брокера. Когда сельдерей выпустили, ничего не было.

@ask, что вы думаете об
У нас также есть докер, что означает, что развертывание rabbitmq находится буквально в одной команде. Это уже не так сложно.

Я только что отказался от поддержки SQL в качестве брокера, включая всех других брокеров, кроме RabbitMQ / Redis / SQS / Qpid :)

(дубликат)

Я не так привязан к сообществу сельдерея; независимо от моих 0,02 доллара:

• Redis действительно популярен - примерно так же популярен, как и все другие поддерживаемые брокеры _combined_ , если вы думаете, что Google Trends является представительным
• Он может быть действительно хорошим брокером _и_ бэкэнд (хотя RabbitMQ тоже)
• Это уникально предлагается крупными поставщиками облачных услуг как полностью управляемая услуга.
• Мы много используем Redis!

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

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

@MaximilianR Говоря только о себе:

1. Это значительная кодовая база, в которую можно войти
2. Особенно если вы не знаток комбу и айнчио
3. И у вас нет интуитивного представления о глубине выявленных проблем.

Тем не менее, я использую сельдерей, поэтому, если есть способ быть полезным, я буду рад помочь.

@MaximilianR , было много участников, но определенно я проделал большую работу. Проект рос слишком быстро, и в какой-то момент у меня был выбор между исправлением ошибок или поддержкой пользователей в IRC / электронной почте / StackOverflow и т. Д. Особенно такие вещи, как проблема тупика многопроцессорного пула, заняли более 6 месяцев целенаправленного кодирования, тогда как я должен был наставничество людей. На тот момент мы были почти размером с RabbitMQ по загрузкам, но там, где 8 человек работали полный рабочий день, я был единственным.

Вероятно, есть другие вещи, которые можно ампутировать, но я не думаю, что что-то отнимает столько времени, как Redis.

Работа по переносу amqp / kombu на полную версию asyncio также потребовала значительных затрат времени, но была необходима для решения ряда проблем. Однако он так и не был завершен.

@ask Означает ли ваше сообщение выше, что вы все еще заинтересованы в разработке SQS? Я заметил, что здесь есть только один открытый запрос SQS, но я все еще вижу предупреждение «Экспериментальное» в документации. Можете ли вы посоветовать текущий статус и будущие потребности в SQS?

Мы будем использовать Celery + SQS в производстве, поэтому я, возможно, смогу внести в это некоторые усилия, но на самом деле я не хочу попадать в такую ​​ситуацию, если SQS не является частью вашего долгосрочного плана для проекта.

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

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

Связанный: предположение, что это одна команда, потому что именно так вы разрабатываете в Docker, может работать на вас, но это не обязательно то, как остальные из нас развертывают.

@nicksloan SQS теперь указан как поддерживаемый транспорт в основной документации: http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

Работа по переписыванию транспорта SQS с использованием асинхронного ввода-вывода была профинансирована чуть более чем на 1000 долларов.

@scoates Транспорт Redis находится в худшей ситуации, поскольку он действительно скомпонован для использования асинхронного ввода-вывода для чтения сообщений, но публикация по-прежнему синхронна. Библиотека Python redis является синхронной, поэтому существует множество проблем даже при чтении сообщений, а также большая неуверенность в том, как это работает. Там легко могут скрываться ошибки, и любые изменения в библиотеке redis-py могут иметь серьезные последствия, если мы используем ее неортодоксальными способами.

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

Это может быть слишком радикальным, учитывая историю сельдерея, но думали ли вы о том, чтобы оставить только Redis вместо RabbitMQ?

@MaximilianR Я

@scoates : Я не говорил о том, как я развиваюсь или что-то в этом роде. Я говорил, что говорить «rabbitmq сложно развернуть» в 2016 году - это чепуха. Даже если вы ничего не знаете о развертывании чего-либо где-то, есть докер, который действительно помогает. Пожалуйста, не делайте неправильных предположений.

Спасибо @ask за то, что

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

Поскольку протокол Redis настолько прост, переписать транспорт, чтобы он стал полностью асинхронным, не должно быть так сложно. Я создал слой, который позволяет Celery поддерживать любую библиотеку Tornado, то же самое можно сделать для asyncio и Twisted, поэтому у нас могут даже быть клиенты, которых мы можем повторно использовать.

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

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

@ask Мой подход заключался в том, чтобы заставить компании поддерживать своих брокеров. Итак, давайте попробуем поговорить с кем-нибудь из Redis labs и посмотреть, получим ли мы какую-нибудь поддержку.
То же самое для MongoDB и других сервисов.
Что касается брокеров SQL, я думаю, что это не очень хорошая идея, и мы не должны их поддерживать.
Мы можем извлечь код вместо того, чтобы удалять его, и тем не менее искать кого-нибудь, кто его поддержит. Если не хватает интереса, то в них нет нужды.
Единственная база данных SQL, которая может быть своего рода брокером, - это Postgres, потому что у нее есть возможности Pub / Sub, но они в настоящее время все равно не реализованы.

Я думаю, мы можем просто отказаться от него и посмотреть, что произойдет. Может быть, кто-то возьмется за это, взяв на себя обслуживание или спонсорство. Если нет, то у нас есть продукт, который нужен людям, но никто не хочет его поддерживать, что, вероятно, на данный момент набрало в общей сложности 18 голосов. Я не думаю, что это повлияет только на Redis Labs :)

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

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

Привет. Я работаю в Redis Labs и до недавнего времени употреблял сельдерей. @thedrow обратил на это мое внимание, и мы обсудили это внутри компании. Мы готовы помочь вам, ребята, мы считаем важным сохранить Redis в составе сельдерея. Я еще не уверен, сделаю ли я это лично или кто-то другой, но давайте начнем обсуждение того, что нужно сделать.

Как и @dvirsky, моя работа над Redis полностью спонсируется Redis Labs, и если мы сможем помочь с этим бэкэндом (надеюсь, да), я буду участвовать в поиске лучших решений на стороне Redis и, возможно, даже расширение поддержки обмена сообщениями Redis для облегчения некоторых вещей в реализации. Мы также могли бы подчеркнуть способность серверной части использовать Sentinel / Redis Cluster в какой-то момент, чтобы иметь опыт HA-ready. Я надеюсь, что у нас будут хорошие новости как можно скорее, в настоящее время мы оцениваем необходимые усилия.

Это действительно хорошие новости! Я полностью понимаю, что вы хотели бы знать, что это за работа, прежде чем приступить к ней :)

Сейчас 3 часа ночи, и я еще не собрал список проблем, но вот несколько коротких заметок:

Celery не определяет набор функций, которые реализованы с интерфейсом Redis, вместо этого
он использует API AMQP для общего использования обмена сообщениями. Обмен сообщениями от имени к очереди, маршрутизация публикации / подписки и темы. Тематическая маршрутизация не является строгим требованием, но остальное имеет решающее значение для основных функций Celery: 1) обработки сообщений задач, 2) отправки / получения событий мониторинга и 3) широковещательного обмена сообщениями для рабочих для управления ими (например, выключение / увеличение параллелизма и т. Д.). ).

1) Должен быть асинхронным, чтобы не блокировать работника при выполнении каких-либо операций.

Текущая версия использует синхронную библиотеку redis-py. Я взломал это, чтобы сделать
он обрабатывает сообщения асинхронно, но я подозреваю, что там все еще есть ошибки, поскольку мы не знаем точно, что происходит в клиенте. Возможно, уже доступны клиенты async redis для
Tornado / asyncio, которые мы могли бы использовать, или в худшем случае, поскольку нам не нужно много делать это в сыром виде, может не
будь таким хитрым.

2) Управление подключением

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

3) Подтверждение сообщения

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

Спасибо @ask , по поводу пункта "1" может иметь смысл напрямую реализовать минимальную поддержку асинхронного Redis, которая нам нужна для нескольких команд, которые мы отправляем непосредственно внутри брокера, вместо того, чтобы зависеть от внешней библиотеки.

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

1) Должен быть асинхронным, чтобы не блокировать работника при выполнении каких-либо операций.

В последний раз я проверял, что клиенты async redis не идеальны (есть пара для торнадо). Что я делал в этих ситуациях много раз, так это использовал исполнителя пула потоков и фьючерсы, чтобы заставить redis-py вести себя как асинхронный клиент. пока у вас не слишком много одновременных задач и достаточно нескольких потоков, он работает лучше, чем асинхронные клиенты.

РЕДАКТИРОВАТЬ: Я еще не работал напрямую с asyncio python, но из того, что я видел, он очень похож на торнадо, поэтому этот шаблон, вероятно, будет легко сделать.

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

@antirez re:

Что касается пункта «1», то может иметь смысл напрямую реализовать минимальную поддержку async Redis, которая нам нужна для нескольких команд, которые мы отправляем непосредственно внутри брокера, вместо того, чтобы зависеть от внешней библиотеки.

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

@dvirsky У нас есть дженерики управления подключением, которые идеально

@ask да, есть hiredis, это специальное расширение C для анализа протокола redis, IIRC оно также может работать с асинхронным клиентом. Какую стратегию вы выбирали до сих пор при создании асинхронного Redis?

в любом случае мне нужно взглянуть на то, что происходит с асинхронными клиентами в последнее время, я не делал много работы с python за последние полтора года. Я вижу, что https://github.com/leporo/tornado-redis был не очень активен.

Стратегии не так много, мы добавляем сокет в цикл событий и отправляем, например, BRPOP синхронно, затем ждем, пока сокет станет доступным для чтения, и синхронно считываем ответ;)

Поскольку у нас нет возможности перезапустить в середине анализа ответа

@dvirsky Если мы будем использовать hiredis для чего-либо, кроме синтаксического анализа протокола, у нас возникнут проблемы совместимости с gevent / eventlet (когда он используется вместо многопроцессорной обработки), и это также сделает hiredis обязательным, какие проблемы с переносимостью, если Celery запущен на PyPy.

@dvirsky Также py-hiredis на данный момент не предоставляет никаких функций, кроме анализа протокола.

Я считаю, что в какой-то момент Python понадобится достойный клиент async redis, поэтому начать что-то правильное было бы неплохой идеей. Например, рефакторинг кода синтаксического анализа протокола в redis-py.

ты сейчас пользуешься gevent?

@dvirsky Мы поддерживаем gevent, eventlet и многопроцессорность (prefork) с асинхронным вводом-выводом. Но если вы поддерживаете одного, у вас обычно есть другие.

Да, бывают случаи, когда gevent больше подходит для задач. например, когда задачи просто записывают в базу данных или выполняют HTTP-запрос.
Достаточно легко открыть и зарегистрировать FD в gevent, но это требует дальнейшей работы в py-hiredis.

@dvirsky Вот пример того, как это делается с PyCurl. https://gist.github.com/GuoJing/5875326
Вам нужно выставить FD, чтобы сотрудничать с gevent.

Недавно меня познакомили с проблемой, связанной с поддержкой сельдерея для Redis, и, хотя я не завершил тщательный анализ, могу сказать, что написание / обновление клиента redis python с помощью asyncio звучит как хорошая идея, но из недавних тестов это было бы лучше всего реализован поверх asyncio + libuv, чтобы максимально повысить производительность.

Ссылки см.

• https://github.com/MagicStack/uvloop
• https://github.com/saghul/pyuv
• http://magic.io/blog/uvloop-blazing-fast-python-networking/

Против этой позиции - или чтобы усложнить ситуацию, я хотел бы отметить, что по моему собственному опыту работы с клиентами Redis, как разработчик и пользователь, полностью полагаясь на libuv, на самом деле не позволит клиенту достичь максимальной производительности, и для этого необходимо нанять Hiredis. В libuv есть масса вещей, которые в некоторых случаях фактически замедляют io, ioredis делает это через Node, и это не очень эффективно.

Таким образом, решение, которое я хотел бы представить, имеет смешанную реализацию hiredis-async. (Другими словами, нужно попробовать кучу альтернатив с тоннами выборки вишен и сравнительного анализа)

@ merl-dev Проблема все еще в PyPy, где hiredis + cffi медленнее анализирует протокол Redis, чем реализация синтаксического анализатора протокола на чистом Python.
По крайней мере, в моей версии также есть несколько сбоев при тестировании с redis-py. См. Https://github.com/redis/hiredis-py/pull/46

Вполне возможно написать клиента hiredis как расширение CPython. Я все еще не уверен на 100% в CFFI.

давай получим это

@thedrow это напоминает мне - вы смотрели новую функцию потоков Redis? Его можно использовать как более надежный брокер сообщений, чем существующие. Совсем скоро это будет GA.

У нас нет. В настоящий момент у нас нет возможности провести рефакторинг брокера Redis.
Мы надеялись, что у вас есть свободные руки для этого.

@thedrow мы могли бы ... ничего не обещать, но мы могли бы выделить дополнительные ресурсы для активной поддержки экосистемы Redis.

@dvirsky ты предложение имел ввиду? Таким образом, вы можете использовать TAPPEND для постановки в очередь, TREAD + TACK для удаления из очереди, обработки и подтверждения.

@georgepsarakis это уже не предложение, оно работает, а префикс X, то есть XADD. см. https://www.youtube.com/watch?v=ELDzy9lCFHQ

Итак, каков последний призыв к поддержке брокера Redis? Будет ли прекращена поддержка в ближайшее время?

Не в данный момент.

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

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

А №301 / 601 все время устаревают.

@ermik попытается помочь разобраться в этом вопросе.