Должен ли я использовать очередь задач (Celery), ayncio или ни для API, который опрашивает другие API? - PullRequest
Новая
       32

Должен ли я использовать очередь задач (Celery), ayncio или ни для API, который опрашивает другие API?

0 голосов
/ 28 февраля 2019

Я написал API для Django, цель которого - работать в качестве моста между серверной частью веб-сайта и внешними сервисами, которые мы используем, чтобы веб-сайт не обрабатывал много запросов к внешним API (CRM, события календаря)., провайдеры электронной почты и т. д.).

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

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

Поскольку веб-сайт ожидает синхронных ответов, мой код содержит много:

results = my_task.delay().get()

или

results = chain(fetch_results.s(), parse_results.s()).delay().get()

Что не похоже на правильный способ использования задач Celery.

Он эффективен при одновременной обработке десятков запросов и параллельной обработке результатов - например, в периодической задаче refresh - но добавляет много накладных расходов для простых запросов (fetch - parse- forward), которые представляют большую часть трафика.

Должен ли я работать полностью синхронно для этих "простых запросов" и сохранять задачи Celery для определенных сценариев?Существует ли альтернативный дизайн (возможно, с использованием asyncio), который лучше подходит для целей моего API?

Использование Django, Celery (с Amazon SQS) на экземпляре EBS EC2.

1 Ответ

0 голосов
/ 01 марта 2019

Вы можете рассмотреть возможность использования Gevent с вашим веб-сервером Django, чтобы он мог эффективно работать для упомянутых вами "простых запросов" без блокировки.Если вы продолжите использовать этот подход, обязательно объединяйте соединения с базой данных с помощью PgBouncer, Pgpool-II или библиотеки Python, поскольку каждый гринлет создаст свое собственное соединение.

После того, как вы это реализовали, можно также использоватьGevent вместо Celery для обработки асинхронной обработки путем объединения нескольких Greenlets, каждый из которых делает внешний запрос API, вместо того, чтобы нести накладные расходы на передачу сообщений внешнему рабочему Celery.

Ваша реализация аналогична той, что мысделано в Kloudless , который предоставляет единый API для доступа к множеству других API, включая CRM, календарь, хранилище и т. д.

...