如何在C#中设计并行web api？

Question

我正在尝试设计一个可以从外部服务器获取数据但有限制的web api。我想知道如何最好的设计它是有效率的。

我的api有一个接受输入的endpoint。它是一个类似于[e-mail]的域名。然后，我的endpoint对域进行http调用以获得一个身份验证令牌，然后使用用户名对该域进行另一次调用以获得一些返回给客户端的数据。但是，我的api可以接受多个用户名（逗号分隔，如？users=[e-mail],[e-mail])。我的web服务器知道每个域的最大并行连接数是多少以获取数据。

所以问题是如何组织数据，使我可以最大化并行计算，但保持在极限之内。

以下是我的想法：

首先解析用户列表并将其分组。然后有一个静态字典。键是域，值是有2个队列的自定义对象。这两个队列都包含任务列表（来自Async/Await）。但是，第一个队列最大长度将是该域的限制值。

?users=[e-mail], [e-mail], [e-mail], [e-mail]

dictionary = {
    "D.com" : [
         [],
         ["[e-mail]", "[e-mail]", "[e-mail]"]
     ],
     "A.com" : [
         [],
         ["[e-mail]"]
     ]
}

然后，我可以每秒运行一段代码，循环所有字典值，用第二个队列中的任务对象填充第一个队列（例如，从第二个队列中移除并放入第一个），使其在限制范围内。

任务一旦进入第一个队列，就会使用parallel.invoke()执行，然后当任务完成时，它就会从第一个队列中删除（除非某个请求正在等待它，下一段将对此进行解释）。

我这样做是因为如果向我的endpoint发出了另一个api请求，并且使用了第一个请求中的一些名称，我希望重用它。因此，如果它在第一个队列中，我将对该任务调用await。

当一个任务完成时，我需要知道没有其他人在任务中等待该用户，在这种情况下，将其从第一个队列中删除。此外，如果客户机断开连接，它应该删除对该客户机的用户部分的监视。

有人知道这是不是一个好方法吗？

Answer 1

由于它是并行的，您马上就知道您可能需要使用system.collections.concurrent，而且由于您需要键/值查找（用户标识符/HTTP响应），您需要一个ConcurrentDictionary。而且由于有一个供所有用户使用的公共缓存，您将希望将其存储在一个静态变量中，该变量对所有线程和所有HTTP请求都可用。

这里有一个简单的例子：

public class MyCacheClass
{
    //Store the list of users/requests
    static private ConcurrentDictionary<string, Task<HttpResponseMessage>> _cache = new ConcurrentDictionary<string, Task<HttpResponseMessage>>();

    //Get from the ConcurrentDictionary or add if it's not there
    public async Task<HttpResponseMessage> GetUser(string key)
    {
        return await _cache.GetOrAdd(key, GetResponse(key));
    }

    //You just to implement this method, potentially in a subclass, to get the data
    protected virtual async Task<HttpResponseMessage> GetResponse(string key)
    {
        var httpClient = new HttpClient();
        var url = string.Format(@"http://www.google.com?q={0}", key);
        return await httpClient.GetAsync(url);
    }
}

然后要获取一个用户的信息，只需调用：

var o = new MyCacheClass();
var userInfo = await o.GetUser(userID);

注意：如果您要在生产系统上使用这样的代码，您可能会考虑在一段时间后或缓存达到一定大小时添加一些清除或修剪缓存的方法。否则，您的解决方案可能无法按您需要的方式扩展。