假设一个 gRPC 客户端向 gRPC 服务器发出两个请求 R1 和 R2，一个接一个（假设没有任何明显的时间间隔，即 R2 是在 R1 仍未被服务时发出的）。此外，假设 R1 比 R2 花费更多的时间。 在这种情况下，我应该先期待 R2 的响应，因为它需要更少的时间，还是应该先期待 R1 的响应，因为这个请求是在 R2 之前提出的？会发生什么，为什么？ 据我观察，我认为请求是以 FCFS 方式提供的，因此，R1 的响应将首先被客户端收到，然后是 R2，但我不确定。
【问题讨论】：
标签： web protocol-buffers grpc rpc grpc-python
理论上，没有什么会阻止服务器和客户端并行处理 gRPC 请求。 GRPC 连接是通过 HTTP/2 建立的，可以一次处理多个请求。所以是的 - 如果服务器不使用某些特定的同步或限制机制，那么请求将是重叠的进程。如果服务器资源或策略不允许，则应一一处理。我还可以添加请求可以有一个超时，之后它将被取消。如此长的等待可能会导致取消和不处理。
【讨论】：
所有请求都应该并行处理。以 Java 实现的 gRPC 架构为例，它分为 2 个“部分”：
事件循环在一个线程工作组中运行——它类似于我们对反应式实现所必须的。每个核心一个线程来处理传入的请求。
请求处理在一个专用线程中完成，该线程默认使用 CachedThreadPool 系统创建。
对于像 Javascript 这样的单线程语言，我不确定它们是如何做到的，但我猜它是在同一个线程中完成的，因此它最终会排队请求。
【讨论】：