这是gRPC中双向流式RPC的意图吗？

Question

我正在使用一元RPC的gRPC客户端上最大化CPU。我想尝试用双向流式RPC（或一组？）替换一元RPC是否有意义，这种双向RPC在整个应用程序的生命周期中都可以持续使用？我无法确定双向流式RPC是否用于这样的标准1 request / 1响应通信。这样做的动机是避免创建新的TCP连接。

Answer 1

我无法确定双向流式RPC是否用于标准1请求/ 1响应通信

如果要使用请求-答复消息模式，只需使用一元请求-答复（RPC）。它是为该模式和语义设计的，例如重试是众所周知的。

这样做的动机是避免创建新的TCP连接。

gRPC使用HTTP / 2，因此所有一元RPC请求都已使用相同的TCP连接-因为HTTP / 2通过同一TCP连接多路复用所有请求。

我正在使用一元RPC的gRPC客户端上最大化CPU。

这听起来有点罕见。您是否可以更改自己的交流方式，例如在等待响应之前流式传输多个请求？替代批处理数据并很少发送更大的请求？还是可以详细说明您的消息模式？

Answer 2

就像@Jonas 建议的那样，为了更高的吞吐量而使用双向流是个坏主意。

Google 的 gRPC 团队反对它，但尽管如此，似乎很少有人认为理论上流应该具有更低的开销。但这似乎不是真的。

可能是因为流确保消息按发送顺序进行传递，因此在存在并发消息时会产生某种瓶颈。

对于较低的并发请求，两者都有相当的延迟。但是，对于更高的负载，一元调用的性能要高得多。

此处有详细分析：https://nshnt.medium.com/using-grpc-streams-for-unary-calls-cd64a1638c8a。