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

Question

我在执行一元 RPC 的 gRPC 客户端上最大化我的 CPU。我想知道尝试用基本上持续整个应用程序生命周期的双向流 RPC（或它们的集合？）替换一元 RPC 是否有意义？我不知道双向流 RPC 是否适用于像这样的标准 1 请求/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 。