对多个受限制的 api 请求使用什么设计模式？答案

【问题标题】：what design pattern to use for multiple throttled api requests?对多个受限制的 api 请求使用什么设计模式？
【发布时间】：2011-03-09 23:06:52
【问题描述】：

我正在编写一个使用多个具有节流限制的 Web 服务的网站。 IE。亚马逊是每秒 1 个请求，另一个是 5000/天，另一个是 x/分钟。

当用户做某事时，我需要触发对上述服务的一个或多个请求，并在可用时将结果返回（给浏览器）。

解决方案需要灵活，以便我可以轻松添加/删除服务。

我想到了一个 FIFO 排队系统，但一些较晚的请求实际上可能在较早的请求之前有资格处理。

我要求提供一种设计模式，但非常欢迎任何合适的技术建议，尤其是 .NET。

谢谢！

【问题讨论】：

标签： .net queue design-patterns throttling

【解决方案1】：

我不确定我是否完全理解您看到的问题所在。来自

某些较晚的请求实际上可能有资格在较早的请求之前进行处理。

我推断您担心现在无法满足但可能很快会处理的缓冲请求。

您收到了一个请求，例如

 { Amazon, X }

并且由于（比如说）X 限制现在无法满足该请求。

我的第一个问题是，请求是否独立，即我可以立即处理亚马逊请求并将 X 请求排队吗？如果是这样，那么每个服务的简单 FIFO 队列肯定会完成这项工作。您可能需要有一个最大大小的队列（鉴于 HTTP 请求超时，您不能等待数小时）。

如果您打算推迟发出亚马逊请求，直到可以发出 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

就我个人而言，我会从更简单的事情开始：如果由于达到任何一项服务限制而无法立即满足请求，请拒绝该请求。

【讨论】：

【解决方案2】：

感谢您的评论。基本上我不想拒绝请求，我想将它们排队并在处理完毕后显示给用户。有点像订购系统。

0:00:01 亚马逊请求进入 -> 下一个可用插槽在 2 秒后 (0:00:03)

0:00:02 x 请求进入 -> 下一个可用于此服务的时隙是 5 秒 (0:00:07)

0:00:03 亚马逊请求进来 -> 下一个可用插槽在 2 秒后 (0:00:05)

我需要一个队列系统，它会首先拉出 2 个亚马逊请求。我想我的问题在于是否为每个服务和任何非常适合节流的通用技术（即服务代理）创建单独的队列，如果不是，我最终将创建自己的节流/排队系统，这就是为什么我由于上面的示例，它不是 FIFO，因此正在寻找常见的设计模式（即生产者/消费者或其他东西）。

到目前为止，它看起来像是每个服务的 FIFO 队列，具有自己的限制，看起来像是前进的方式。

【讨论】：