我正在尝试为以下场景找到架构。我正在构建一个REST服务，它可以执行一些可以快速批量计算的计算。假设计算1“项目”需要50ms，计算100“项目”需要60ms。
但是，客户端的性质是一次只需要处理一个项目。因此，如果我有100个并发客户端，并且我编写了发送一个项目并生成响应的典型请求处理程序，那么我最终将使用5000ms，但我知道我可以在60ms内计算相同的内容。
我正在尝试找到一种在这种情况下运行良好的架构。即，我希望能够合并来自许多独立请求的数据，批处理流程，并为每个客户生成等效响应。
如果你很好奇，有问题的服务是基于python + django + DRF的，但我很好奇这里有什么样的架构解决方案/模式，如果解决了这个问题已经有了。
答案 0 :(得分：1)
首先，您可以考虑反向代理检测所有特定于模式的查询，收集所有这些查询并将其发送到您的应用程序中的HTTP 1.1 管道（管道传输是一种发送大的方法一个接一个的查询数量，并在最后以相同的顺序接收所有HTTP响应，而不是在每次查询后等待响应。）
可是：
因此，好的想法是在应用程序端执行。您可以识别匹配的查询，并等待一小段时间（10毫秒？），以查看是否还有其他查询。您需要一种方法在此处与多个并行工作者进行通信（例如，您有50个应用程序工作者，其中10个已收到可在同一批处理中处理的查询）。这种通信方式可能是数据库（速度非常快）或某些共享内存，取决于所使用的技术。
然后，当花费太多时间（10毫秒？）或收到大量查询时，其中一个工作人员可以收集所有查询，运行批处理，并告诉其他所有工作人员有结果（在这里，你需要一个集中的通信点，比如PostgreSQL中的LISTEN / NOTIFY，共享内存，消息队列服务等。）。
最后，每个工作人员都负责发送正确的HTTP响应。
这里的关键是建立一个系统，其中你失去的时间试图分享请求处理比将多个查询一起批处理时保存的时间重要这次交通量低的情况应该保持合理（因为这里你总是会浪费时间等待什么）。当然，您还在系统上添加了一些复杂性，更难维护等。