Собственно стек технологий следующий API на php БД - Redis и ещё пару знаминитостей...в данном случае это не важно брокер сообщений Kafka для логов и сбора статистики точка входа в апи одна. Авторизация OAuth2 и главное апи ещё пока в разработке, не в продакшене и поэтому можно крутить и вертеть. Авторизация осуществляется по токену. по токену мы можем определить client_id. Задача - ограничить запросы по client_id. Что имею в виду под словом ограничить. Допустим есть клиент сайт, есть моб приложение и есть некий контрагент. Нужно допустим в критические дни запросы от контрагента сделать менее приоритетными, на первое место поставить запросы от сайта, потом от моб приложения. Интересует не пхп код, а методика данного ограничения. Есть ли у кого опыт в данном вопросе. ?
что то пришла мысль. может вешать каждого клиента на отдельный порт. наверное так и делает весь народ
нет нужды так делать. --- Добавлено --- кстати вот, поищи готовых знаменитостей к твоим уже в команду https://www.google.ru/search?q=менеджер+очередей --- Добавлено --- например https://www.rabbitmq.com/priority.html
А как можно ещё организовать ? Давайте порасуждаем. RabitMQ тоже рассматривали как конкурсанта, но предпочтение отдали Kafka. Но этот стек сейчас пользуется только для сбора лога и статистики. В самой функциональности это не участвует. Т.е приходит запрос выполняем действие, + плюем в Kafka лог и статистику. А тут вопрос как ограничить на первом этапе. Что бы в критические дни менее важные клиенты не мешали более важным клиентам. Слышал что в RabitMQ можно использовать не только как очереди но и организовать типа некой шины. Но это никогда не пользовал, и вопрос что будет под нагрузкой например в 100-500 тыс запросов в сек. Сейчас прихожу к мнению, что вообще физически нужно разносить клиентов. Это даст возможность для масшатабирования и на уровне сервера уже производить манипуляции для ограничения запросов и настроек.
давай тебе для управления очередью нужна управлялка очередями. ты либо пишешь её сам, либо берёшь готовую. конец рассуждений. тестируй нужно продумать горизонтальное масштабирование проекта, это да. если у тебя клиенты слабо друг на друга влияют, а ещё лучше если никак, то надо разносить стопудово. Тебе тогда даже париться приоритетами не придётся. Может стоит начать с решения этой задачи.
ладно я понял. тут походу форум только php. буду впредь вопросы только по пыхе задавать. спасибо за ответ p/s если кому пригодится разнес клиентов по портам. на nginx уже разруливаю ограничения.
Ещё раз ограничения не на очередь запросов внутри микросервисов апи, а на входящие запросы от клиентов (requests) - средствами nginx. а также разграничение и масштабирование физически по серверам . Не доводя дело до программного уровня. Что бы не создавать бесполезную нагрузку. И не придумывать велосипед средствами языка програмирования. Предлагаю закрыть эту тему т.к задача решена. Как говорится подумал об вас.