Оптимизация Celery‑задачи изменения статуса
Передавать ORM-объект в Celery некорректно для обычного JSON-сериализатора. Также APIView не предоставляет get_serializer/create-контракт, а отправка письма не согласована с записью статуса.
Читать ответПодготовка к интервью
60 вопросов по Celery с технических собеседований
Что проверяют на интервью
На странице собраны вопросы по Celery — от проверки базовых принципов до практического применения и архитектурных решений. В подборке чаще встречаются темы: celery, backend, rabbitmq.
Каталог
Передавать ORM-объект в Celery некорректно для обычного JSON-сериализатора. Также APIView не предоставляет get_serializer/create-контракт, а отправка письма не согласована с записью статуса.
Читать ответПередавайте в Celery идентификатор Feedback, а не экземпляр ORM. Ставьте задачу после commit и изменяйте статус условно, чтобы не откатить более позднее состояние.
Читать ответПередавайте account.pk, а не экземпляр User. Стандартный JSON-сериализатор Celery не поддерживает ORM-модель; worker должен заново получить пользователя и проверить актуальное состояние.
Читать ответВ текущем виде задача не гарантирует смену статуса: ORM-объект не подходит для JSON Celery, а APIView использован неверно. Передавайте id после commit; фоновая задача выполняется позже, не «сразу».
Читать ответПри стандартной JSON-сериализации Celery экземпляр Django User передать нельзя. Передавайте первичный ключ и загружайте актуальную модель внутри задачи; создание новой записи согласуйте с commit.
Читать ответFastAPI принимает задания, Celery выполняет сверку, RabbitMQ доставляет задачи. Полный отказ от ручного аудита нельзя объявлять без подтверждённых требований и измерений качества конкретного проекта.
Читать ответCanvas описывает композицию задач: chain выполняет шаги последовательно, group запускает набор, chord добавляет callback после группы. Завершение координируют Celery и result backend, а не брокер сам по себе.
Читать ответПередавайте стабильный ID и минимальные сериализуемые параметры, а ORM-объект загружайте в worker. Объект может быть тяжёлым, устаревшим и связанным с уже закрытой сессией.
Читать ответРасскажите, для каких фоновых задач применяли Celery, какой был брокер и как обеспечивали повторы и идемпотентность. Отдельно уточните эксплуатационный опыт и настройку работников.
Читать ответСначала отличите утечку живых объектов от фрагментации и удержания памяти allocator. Для prefork Celery полезна плановая замена дочерних процессов по числу задач или объёму памяти, но это не исправляет причину.
Читать ответfork создаёт дочерний процесс с отдельным виртуальным адресным пространством, а физические страницы первоначально могут разделяться через copy-on-write. Копирование требуется при записи в разделяемую страницу.
Читать ответПри аварии риск зависит от persistence и подтверждений, а не только от названия брокера. Redis без подходящей долговечности может потерять недавно принятые задачи; RabbitMQ тоже требует правильной настройки.
Читать ответ