Перепроектирование вычисления API с помощью асинхронной очереди

#node.js #api #express #asynchronous

#node.js #API #экспресс #асинхронный

Вопрос:

Мне нужна помощь, чтобы перепроектировать конечную точку моего API. Эта конечная точка запускает вычисление, состоящее из множества вызовов API.

Чтобы описать это вычисление :

  • Пользователь запрашивает вычисление с 3 географическими точками (A, B, C)
  • Сервер узла запрашивает у postgis 10 точек, содержащихся в области между ABC (1, 2, 3, 4, 5, и т.д.)
  • Затем сервер узла выполняет вызов API для каждой пары origin / dest (A1, B1, C1, A2, B2 и т.д.)

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

По совету друга я начал черновой проект, состоящий из :

  • Отправка запроса вычисления в базу данных (с идентификатором calcul, который будет использоваться интерфейсом для получения прогресса и результатов)
  • Создание параллельной очереди из n асинхронных функций, которые выполняют запросы postgis (n = 3?): проверьте, есть ли результат в кэше *, иначе выполните запрос postgis и кэшируйте результат, затем обновите ход выполнения
  • Создание параллельной очереди из n асинхронных функций, которые выполняют вызовы API (n = 30?): проверьте, есть ли результат в кэше, иначе выполните вызов и кэшируйте результат, затем вставьте / обновите строку в базе данных с идентификатором вычисления
  • Создание задачи CRON, которая каждую секунду проверяет ожидающие вычисления и добавляет их в нужную очередь

* Я до сих пор не знаю, должен ли кэш быть базой данных Redis или некоторыми таблицами в моей базе данных Postgresql

Я новичок в такого рода дизайне, поэтому любой совет был бы полезен!

Комментарии:

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

2. Насколько велик кеш (с точки зрения использования памяти)? И вы кластеризуете свой сервер? Redis не является постоянным хранилищем (если вы не добавляете поверх него моментальные снимки) по сравнению с PostgresqlDB, который является постоянным, поэтому, вероятно, будет определять, какой путь вам нужно выбрать, исходя из того, нужно ли вам сохранение заданий в очереди, если ваш сервер выйдет из строя. Если постоянство не требуется, а объем используемой памяти невелик, и вы не кластеризуете, вы можете просто пойти проще и использовать Javascript в памяти для кэша.