какой шаблон проектирования использовать для нескольких дросселированных запросов API? - PullRequest
Новая
       27

какой шаблон проектирования использовать для нескольких дросселированных запросов API?

0 голосов
/ 30 июня 2010

Я пишу веб-сайт, который использует несколько веб-сервисов с ограничениями газа. То есть Amazon - 1 запрос в секунду, другой - 5000 в день, другой - х / минута.

Когда пользователь что-то делает, мне нужно вызвать один или несколько запросов к вышеперечисленным службам и вернуть результаты (в браузер), если они доступны.

Решение должно быть гибким, чтобы я мог легко добавлять / удалять сервисы.

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

Я прошу шаблон проектирования, но любые подходящие технологические предложения приветствуются, особенно .NET.

Спасибо!

Ответы [ 2 ]

0 голосов
/ 02 июля 2010

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

0: 00: 01 приходит запрос Amazon -> следующий слот доступен через 2 секунды (0:00:03)

0: 00: 02 xприходит запрос -> следующий слот, доступный для этой услуги, составляет 5 секунд (0:00:07)

0: 00: 03 Запрос Amazon поступает -> следующий слот доступен через 2 секунды (0:00:05)

Мне нужна система очередей, которая сначала вытянет 2 запроса amazon.Я предполагаю, что мой вопрос заключается в том, создавать ли отдельные очереди для каждой службы и какой-либо общей технологии (т. Е. Service Broker), которая хорошо подходит для регулирования, если нет, то в конечном итоге я создам свою собственную систему регулирования / организации очередей, поэтому яискал общие шаблоны проектирования (т. е. производитель / потребитель или что-то в этом роде), поскольку это не FIFO из-за приведенного выше примера.

До сих пор это выглядело как очередь FIFO для каждого сервиса, с собственным регулированием, выглядит какспособ двигаться вперед.

0 голосов
/ 30 июня 2010

Я не уверен, что полностью понял, где вы видите проблему.Начиная с

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

Я предполагаю, что вы обеспокоены буферизацией запросов, которые не могут быть удовлетворены сейчас, но могутработал в ближайшее время.

Вы получили запрос, такой как 

 { Amazon, X }

, и из-за (скажем) регулирования X не может удовлетворить этот запрос прямо сейчас.

Мой первыйВопрос заключается в том, являются ли запросы независимыми, то есть я могу немедленно обработать запрос Amazon и поставить X-запрос в очередь?Если так, то простая очередь FIFO для каждого сервива, безусловно, сделает эту работу.Вероятно, вам понадобится максимальный размер очереди (учитывая, что время ожидания HTTP-запросов не может длиться часами).

Если вы думаете об отсрочке выдачи запроса 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

Лично я бы начал с чего-то гораздо более простого: если запрос не может быть удовлетворен прямо сейчас, потому что достигнут какой-либо один предел обслуживания, просто отклоните запрос.

...