Комментарии 29
Возможно данная статья уже публиковалась на Хабре, но я ее не нашел. Об ошибках орфографии или опечатках пишите в личку
На практике Redis быстрее чем RabbitMQ в роли брокера.
Вполне вероятно что так, но можете описать условия в которых вы это выявили и предполагаемые причины?
Только скорее всего он будет терять задачи ри падениях воркеров.
У RabbitMQ есть встроенная веб морда с метриками для очередей.
Редис не может накапливать сообщения в очереди, то есть там нужно чтобы и подписчики и паблишеры были онлайн.
Насколько я в курсе в редисе нету подтверждения сообщений, нету авторизации, логического разделения очередей и много чего другого. В общем это инструменты для разных нужд и нагрузок.
Плюс про производительность хочу сказать, что у меня в работе есть очереди которые обрабатывают тысячи сообщений в секунду и сверхнагрузки на RMQ нет, а большинству людей насколько я в курсе и 10-20/секунду никогда не достичь нагрузки. Так что предлагаю вспомнить Дональда Кнута: «Предварительная оптимизация — зло».
Редис не может накапливать сообщения в очереди, то есть там нужно чтобы и подписчики и паблишеры были онлайн.
Насколько я в курсе в редисе нету подтверждения сообщений, нету авторизации, логического разделения очередей и много чего другого. В общем это инструменты для разных нужд и нагрузок.
Плюс про производительность хочу сказать, что у меня в работе есть очереди которые обрабатывают тысячи сообщений в секунду и сверхнагрузки на RMQ нет, а большинству людей насколько я в курсе и 10-20/секунду никогда не достичь нагрузки. Так что предлагаю вспомнить Дональда Кнута: «Предварительная оптимизация — зло».
В Redis-e есть авторизация и он умеет накапливать в очереди.
У рубистов есть Resque, который использует Redis в качестве бэкенда.
Resque сделан в GitHub и используется ими в качестве основного MQ. И он действительно быстрый и нагрузку он держит.
Есть очень много имплементаций на других языках и очень хорошая web паель управления (в лучших традициях GitHub).
У рубистов есть Resque, который использует Redis в качестве бэкенда.
Resque сделан в GitHub и используется ими в качестве основного MQ. И он действительно быстрый и нагрузку он держит.
Есть очень много имплементаций на других языках и очень хорошая web паель управления (в лучших традициях GitHub).
«В Redis-e есть авторизация и он умеет накапливать в очереди.»
Авторизация там не для разграничения доступа к очередям, а для доступа к Redis.
Да, накапливает, тут я неправильно сказал.
«У рубистов есть Resque, который использует Redis в качестве бэкенда.»
Он Redis использует в качестве брокера очередей. А Rescue по сути — воркер-враппер, для заданий и c RMQ его нельзя сравнивать потому что это совсем разные продукты.
Я не понимаю что вы хотите доказать, я не сказал что Redis'ом не надо пользоваться как брокером очередей, я сказал что у них разные задачи и их не нужно сравнивать. Redis для очень простых очередей с небольшим количеством неважных задач. Вот у меня на RMQ крутятся сотни очередей от десятков проектов, написанные на 4 разных языках программирования, которые изолированы друг от друга авторизацией. Данные в очередях (которые durable) ПЕРЕЖИВАЮТ РЕСТАРТ RMQ, вот в редисе так точно нельзя. Если у вас возникнут какие-то проблемы с Redis, например он начнёт жрать очень много памяти, вы не сможете выяснить почему, там нет никакой возможности мониторить сложные проблемы. Также у RMQ есть ещё море всяких уникальных возможностей которые в один комментарий не засунешь, это надо целый пост писать.
Авторизация там не для разграничения доступа к очередям, а для доступа к Redis.
Да, накапливает, тут я неправильно сказал.
«У рубистов есть Resque, который использует Redis в качестве бэкенда.»
Он Redis использует в качестве брокера очередей. А Rescue по сути — воркер-враппер, для заданий и c RMQ его нельзя сравнивать потому что это совсем разные продукты.
Я не понимаю что вы хотите доказать, я не сказал что Redis'ом не надо пользоваться как брокером очередей, я сказал что у них разные задачи и их не нужно сравнивать. Redis для очень простых очередей с небольшим количеством неважных задач. Вот у меня на RMQ крутятся сотни очередей от десятков проектов, написанные на 4 разных языках программирования, которые изолированы друг от друга авторизацией. Данные в очередях (которые durable) ПЕРЕЖИВАЮТ РЕСТАРТ RMQ, вот в редисе так точно нельзя. Если у вас возникнут какие-то проблемы с Redis, например он начнёт жрать очень много памяти, вы не сможете выяснить почему, там нет никакой возможности мониторить сложные проблемы. Также у RMQ есть ещё море всяких уникальных возможностей которые в один комментарий не засунешь, это надо целый пост писать.
Я не понимаю что вы хотите доказать
Ваше изначальное утверждение, что решение основанное на Redis недостаточно гибко/масштабируемо/надежно итд.
Я показал пример, что Redis в качестве бэкенда для MQ достаточно серьезное решение, используемое Github, где совсем не: «очень простые очереди с небольшим количеством неважных задач». К примеру Redis-Resque и RabbitMQ вполне конкурирующие системы.
Данные в очередях (которые durable) ПЕРЕЖИВАЮТ РЕСТАРТ RMQ, вот в редисе так точно нельзя
Конечно можно, Redis умеет складывать данные в файловую систему и подхватывать в случае рестарта/поломки. Кроме того, есть репликация.
По функционалу — пройдитесь по списку resque плагинов и их описанию. Заодно статья за 2009 год будет полезна почему Github написали свой велосипед, перепробовав кучу других MQ:
highscalability.com/blog/2009/11/6/product-resque-githubs-distrubuted-job-queue.html
Я в корне не согласен с трактовкой что Redis как бэкенд для MQ (пример resque) не подходит для серьезных задач и нагрузок. И по функционалу и по скорости (~100K сообщений/секунду на ядро одинаково достижимы как для resque так и для RabbitMQ) и по надежности (миллионы сообщений в сутки не проблема вообще ни для какой MQ).
Редис не может накапливать сообщения в очереди, то есть там нужно чтобы и подписчики и паблишеры были онлайн.Может, в редисе всего этого нет «из коробки» в механизме pub/sub, но все это точно можно реализовать средствами самого редиса.
Насколько я в курсе в редисе нету подтверждения сообщений, нету авторизации, логического разделения очередей и много чего другого. В общем это инструменты для разных нужд и нагрузок.
Тоже использую Редис как брокер. Радует.
Хотел бы попросить автора описать, чем celery выгоднее и лучше чем просто использовать RabbitMQ (я про реально используемые фичи). Потому что пару раз задумывался об этом, читал доку celery, но так там ничего полезного для нас и не нашёл особо. Как я понимаю это универсальная надстройка над разными брокерами сообщений, но вот конкретно для раббита что она добавляет?
У меня очень негативный опыт использования celery и особенно связки celery + mongo. Производительность мне была не важна, задачь очень мало. Но их надо было не терять. Т.е. если я добавляю задачу то она, во-первых, должна когда-нибудь выполниться, а во-вторых, мне должен прийти результат выполнения задачи. Запускаю систему, она работает, но иногда задачи исчезают. Долго копаюсь в коде, а там в celery абстракция над абстракцией и абстракцией погоняет, нахожу проблему, исправляю. Заодно понимаю, что оно by design будет терять задачи: задача выгружается в память воркера и если он упадет, то попытается в expect блоке положить её обратно в очередь. Но может и не положить.
Потом выясняется, что при смене мастера монги celery виснет. Оно исключение не обрабатывало. Пишу патч, отправляю разработчикам. Результат — мы сами не используем mongodb, поэтому не понимает что это исправление делает, так что патч принимать не будем.
Пока они над этим думали, я написал свой велосипед который занимает на несколько порядков меньше строк кода и который рагантированно отказоустойчив.
Потом выясняется, что при смене мастера монги celery виснет. Оно исключение не обрабатывало. Пишу патч, отправляю разработчикам. Результат — мы сами не используем mongodb, поэтому не понимает что это исправление делает, так что патч принимать не будем.
Пока они над этим думали, я написал свой велосипед который занимает на несколько порядков меньше строк кода и который рагантированно отказоустойчив.
А что именно в celery привлекло? Почему не чистый RMQ (там для вашей проблемы есть durable очереди + ручное подтверждение задач, своя кластеризация + один инструмент вместо двух, меньше точек отказа).
В RabbitMQ такой ситуации бы не возникло — при разрыве соединения с consumer'ом Rabbit автоматически пометит задачи как снова ожидающие в очереди. И используйте ACK_LATE.
RabbitMQ предназначен именно для работы с очередью сообщений, у него внутренний механизм это обеспечивает. Mongo — нет, это просто хранилище. Ей сказали «запиши 1 в колонку» — она и записала. И ее не волнуют ваши очереди-шмочереди. И как поддерживаемый брокер она имеет статус Experimental в celery.
Поэтому мне кажется, что вы зря жалуетесь. Именно из вашего описания RabbitMQ — это то, что вам бы подошло. Он довольно дружелюбен и не так сложен в установке, ИМХО.
RabbitMQ предназначен именно для работы с очередью сообщений, у него внутренний механизм это обеспечивает. Mongo — нет, это просто хранилище. Ей сказали «запиши 1 в колонку» — она и записала. И ее не волнуют ваши очереди-шмочереди. И как поддерживаемый брокер она имеет статус Experimental в celery.
Поэтому мне кажется, что вы зря жалуетесь. Именно из вашего описания RabbitMQ — это то, что вам бы подошло. Он довольно дружелюбен и не так сложен в установке, ИМХО.
Поэтому мне кажется, что вы зря жалуетесь.
Я жалуюсь на то, что патч был отклонен с формулировкой «мы не знаем как работает эта часть кода из нашго репозитория поэтому не можем понять хороший патч или плохой, вдруг он не только исправит critical багу, но и еще что-нибудь сломает».
И еще я жалуюсь на то, что код у celery + combu очень сложный. Очень много абстракций.
А та часть системы, для которой у меня отлично подходил RabbitMQ — это небольшая часть, деталь реализации.
Я жалуюсь на то, что патч был отклонен с формулировкой «мы не знаем как работает эта часть кода из нашго репозитория поэтому не можем понять хороший патч или плохой, вдруг он не только исправит critical багу, но и еще что-нибудь сломает».
И еще я жалуюсь на то, что код у celery + combu очень сложный. Очень много абстракций.
А та часть системы, для которой у меня отлично подходил RabbitMQ — это небольшая часть, деталь реализации.
Не соглашусь с вами по поводу сложности. Я копался в нем и, в принципе, все довольно внятно.
Для такого большого функционала оно очень грамотно написано — без абстракций было бы много копипасты.
В celery/kombu настраивается все что угодно — вы можете переписать/перегрузить почти любую часть с нужным вам функционалом. Посмотрите только на список брокеров — входной интерфейс один, но работает с совершенно разными движками.
Это уже третья версия же, обычно к такой цифре автор как раз два раза понимает как убрать накопившийся говнокод и сделать «чисто».
А можете найти ссылку на номер бага, о котором вы говорите? Просто интересно посмотреть на комментарии… Автор Ask Solem, вроде, довольно общительный и адекватный, на критику реагирует нормально…
Для такого большого функционала оно очень грамотно написано — без абстракций было бы много копипасты.
В celery/kombu настраивается все что угодно — вы можете переписать/перегрузить почти любую часть с нужным вам функционалом. Посмотрите только на список брокеров — входной интерфейс один, но работает с совершенно разными движками.
Это уже третья версия же, обычно к такой цифре автор как раз два раза понимает как убрать накопившийся говнокод и сделать «чисто».
А можете найти ссылку на номер бага, о котором вы говорите? Просто интересно посмотреть на комментарии… Автор Ask Solem, вроде, довольно общительный и адекватный, на критику реагирует нормально…
Может кому пригодится
указать альтернативное размещение конфига
os.environ['CELERY_CONFIG_MODULE'] = 'conf.celeryconfig'
указать альтернативное размещение конфига
Вопрос. Я занимаюсь разработкой большого проекта на Джанго, и сегодня увидел эту статью. Я не могу понять зачем нам нужен Celery. Можете привести примеры использования Celery в реальной жизни? Пытаюсь что нибудь нарыть в интернете, но все источники просто твердят, что это task queue
А чем он еще должен быть? Celery же и проектировался как абстракция над системами очередей. Вот, например, его использует такая джанго-батарейка: habrahabr.ru/post/253445 и ее репозиторий: github.com/LPgenerator/django-db-mailer
Начиная от cron задач и заканчивая любыми асинхронными операциями. Например, отправка писем.
НЛО прилетело и опубликовало эту надпись здесь
Много чего есть, конечно. Celery иногда может быть не нужен. Если вам не нравится «дубликат проекта в Django» — загружайте celery в отдельном проекте и не импортируйте весь проект. Хотя не думаю что будет сильно большой выигрыш, только если у вас в глобальном namespace в Django не идет обработка больших строк. Не идет же? Тогда откуда " жрали память"?
Вы можете и не использовать RabbitMQ — если у вас один сервер с двумя всего тасками, то используйте хоть sqlite как брокер или Redis.
Можете написать скрипт, который будет запускаться через cron каждые 5 минут и выполнять таски из базы.
Есть еще, например, Luigi как альтернатива. Или python-multitask.
Вы можете и не использовать RabbitMQ — если у вас один сервер с двумя всего тасками, то используйте хоть sqlite как брокер или Redis.
Можете написать скрипт, который будет запускаться через cron каждые 5 минут и выполнять таски из базы.
Есть еще, например, Luigi как альтернатива. Или python-multitask.
Классический пример: социальная сеть, в которой пользователи загружают картинки в свои профайлы. После загрузки картинки должны быть сконвертированы в один и тот же формат и обрезаны до определенных размеров. После этого они должны появиться в профайле, а всем подписчикам отправлены уведомления по почте. Если делать это синхронно запросом, то сервер может не справиться в пике, да и ждать долго всех операций, а мы не хотим долгие коннекты к серверу держать.
Как решение — мы ставим отдельный сервер (несколько серверов), на которых крутятся celery-воркеры. при загрузке картинки она пишется на временный storage и в очередь celery кладется задача с (user_id, image_name). Юзеру в браузер возвращается «200 OK» и он знает что картинка скоро появится.
Первый освободившийся воркер подхватывает эту задачу и обрабатывает картинку, кладет ее в базу, а потом создает новую задачу в другой очереди на отправку уведомлений (которая может тоже работать довольно долго).
Как решение — мы ставим отдельный сервер (несколько серверов), на которых крутятся celery-воркеры. при загрузке картинки она пишется на временный storage и в очередь celery кладется задача с (user_id, image_name). Юзеру в браузер возвращается «200 OK» и он знает что картинка скоро появится.
Первый освободившийся воркер подхватывает эту задачу и обрабатывает картинку, кладет ее в базу, а потом создает новую задачу в другой очереди на отправку уведомлений (которая может тоже работать довольно долго).
Я люблю celery за возможность строить сложные цепочки асинхронных задач, используя их примитивы
Например так:
# (4 + 4) * 8 * 10
res = chain(add.s(4, 4), mul.s(8), mul.s(10))
Результат выполнения задачи идёт в кач-ве первого аргумента для след. задачи
Ссылка на документацию
Бывает весьма полезно использовать web hooks, которые позволяют в кач-ве воркера использовать сторонний сервис
Так же часто бывает полезно, когда много мелких однотипных задач, держать соединение с базой для всех выполняемых задач, а не создавать его заново в каждой новой.
Пример
Например так:
# (4 + 4) * 8 * 10
res = chain(add.s(4, 4), mul.s(8), mul.s(10))
Результат выполнения задачи идёт в кач-ве первого аргумента для след. задачи
Ссылка на документацию
Бывает весьма полезно использовать web hooks, которые позволяют в кач-ве воркера использовать сторонний сервис
Так же часто бывает полезно, когда много мелких однотипных задач, держать соединение с базой для всех выполняемых задач, а не создавать его заново в каждой новой.
Пример
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Celery: лучшие практики