Как лучше организовать очередь сообщений для их разбора по графику?
По REST API приходят 10-50 тыс. запросов в минуту.
Обрабатывать нужно не все, а только ~2% ( так как большинство запросов это дубли )
Real-time не нужен, достаточно раз в минуту их обрабатывать.
Подскажите как лучше это организовать ?
Использовать какой-то готовый инструмент для построения очереди ?
Или просто как-то складывать в файл (на чём такое лучше писать - nodejs, python, go ?), и потом этот файл разбирать по крону ?
Обрабатывать нужно все запросы на уровне своего REST API, но на сколько я понял, то ты пытаешься топорным методом решить проблему с большим кол-вом лишних запросов к бэку, если ты например пользуешься nginx то там даже для каждого location - можно настроить лимиты запросов, период между запросами, и т.д ( гугл в помощь ) и если чувак нарушил твои лимиты - просто блочишь все запросы с его ip или проксируешь все дальнейшие его запросы на какой-нибудь чужой api)
Клиент использует CRM систему, и там видимо это не баг а фича - дёргать api при каждом изменении сущности. Подписаться, только на нужные события нельзя. Поправить её не представляется возможным, т.к. это большое saas решение.
Тело сообщения - это данные в json, данные совпадают не полностью, т.к. в них есть временные метки
Иерокопус Таманский,
чтобы накопить дубли, чтобы их отбросить и обработать только не задублированные.
важно обработать последний запрос, т.е. последний дубль не пропустить, остальные можно проигнорировать.
Иерокопус Таманский,
никак. копим очередь, отбрасываем все дубли обрабатываем последнее в этой очереди (может оно и будет последним, а может совсем последнее будет в следующей очереди)
Можно писать в тот же redis, для данных с одинаковым хэшем дублирования не будет. Ну и есть очереди на основе redis разные, зависит от вашего языка.
А так, соглашусь с предыдущим оратором - надо бы разобраться с дублированием, откуда его столько...
