Какой рисунок дизайна для использования для нескольких запросов на дроссельные API?
-
01-10-2019 - |
Вопрос
Я пишу веб-сайт, который использует несколько веб-сервисов с ограничениями дроссельной заслонки. IE Amazon - 1 запрос в секунду, другой 5000 / день другой - х / минута.
Когда пользователь делает что-то, мне нужно срабатывать один или несколько запросов к вышеуказанным сервисам и возвращать результаты (в браузер), когда доступно.
Решением необходимо быть гибким, поэтому я легко могу добавлять / удалять сервисы.
Я подумал о системе очередной очереди FIFO, но некоторые более поздние запросы могут иметь право на обработку до предыдущих.
Я прошу образец дизайна, но любые подходящие предложения технологий очень приветствуются, особенно .NET.
Спасибо!
Решение 2
Спасибо за ваш комментарий. По сути, я не хочу отклонить запросы, я хочу покинуть их и отображать обратно к пользователю, когда они были обработаны. Вид как система упорядочения.
0:00:01 Amazon Project входит -> Доступно следующий слот в течение 2 секунд (0:00:03)
0:00:02 X запрос приходит -> Следующий слот Доступно для этой услуги, 5 секунд (0:00:07)
0:00:03 Amazon Project входит -> Доступно следующий слот в течение 2 секунд (0:00:05)
Мне нужна система очередей, которая вытягивает 2 запроса Amazon. Я думаю, что мой вопрос заключается в том, будет ли создавать отдельные очереди для каждой службы и любых общих технологий (т. Е. Сервисный брокер), которая хорошо подходит для дросселирования, если нет, я в конечном итоге создаю свою собственную систему дросселинга / очереди, которая в том, почему я Искал общие шаблоны дизайна (то есть производителя / потребителя или что-то в этом роде), поскольку это не FIFO из-за вышеуказанного примера.
До сих пор он выглядит как очередь FIFO для каждой службы, с собственным дросселем выглядит как путь, чтобы двигаться вперед.
Другие советы
Я не уверен, что я полностью понял, где вы видите проблему. От
Некоторые поздние запросы могут быть фактически могут иметь право на обработку до предыдущих.
Я вывод, что вы обеспокоены буферизацией запросов, которые не могут быть удовлетворены сейчас, но могут работать в ближайшее время.
Вы получили запрос, такой как
{ Amazon, X }
И из-за (сказать) X дросселирование не может удовлетворить этот запрос прямо сейчас.
Мой первый вопрос будет, являются независимыми запросами, то есть я могу ли я обработать запрос Amazon сразу и в очереди x запрос? Если это так, то простая очередь FIFO для каждой слуги, безусловно, будет выполнять работу. Возможно, вам, вероятно, понадобится максимальный размер очереди (учитывая, что HTTP-запросы Timeout, вы не можете дождаться часов).
Если вы имеете в виду, отсрочка выдачи запроса Amazon, пока невозможно выдать запрос X, то все становится все сложнее. Я думаю, что вы повлияли на проблему планирования встречи. Вам нужно найти слот, когда Amazon и X бесплатны. Таким образом, вы можете иметь какой-то список очередей, каждая очередь предназначена для запросов, которые будут удовлетворены тем временем для службы.
Amazon(3 per sec)
09:05:31 - request A, B, C
09:05:32 - request D, E, F
09:05:33 - request G - - <=== slots available
--- <=== times and slots available
X (2 per min)
09:05 - request M, N
09:06 - request O <=== slot available
Вот наш {Amazon, x} имеет слот доступен в 09:06
Amazon(3 per sec)
09:05:31 - request A, B, C
09:05:32 - request D, E, F
09:05:33 - request G - - <=== slots available
--- <=== times and slots available
09:06:01 - request P
X (2 per min)
09:05 - request M, N
09:06 - request O, P
Лично я начал с чего-то намного проще: если запрос не может быть удовлетворен довольным, потому что любой предел обслуживания достигнут, просто отклонил запрос.