2

我有一个 gRPC 服务，它接受来自客户端的流式消息。客户端以高速率向服务器发送有限序列消息。

结果是服务器缓冲了大量消息（> 1GB），并且它的内存使用量猛增，然后在处理它们时慢慢耗尽。

我发现即使我等待所有异步调用，客户端也会尽可能快地推送消息。我希望客户放慢速度。

我已经实现了客户端在发送下一条消息之前等待的显式 ack 响应，但是由于 http/2 已经内置了流控制语义，我觉得我有点重新发明轮子。

我有两个具体的问题。

  1. C# 实现会自动应用背压吗？例如，如果消费端在异步流上调用 MoveNext 的速度很慢，那么客户端是否需要更长的时间才能从其对 WriteAsync 的调用中返回？

  2. gRPC 的 C# 实现是否有任何可配置的方式来限制流式 rpc 调用的消息缓冲。例如，限制缓冲消息的数量或限制调用缓冲区中的空间量。

4

1 回答 1

2

正如 Jan 评论的那样，这个问题在 gRPC GitHub Repo 上得到了回答。

流控制有望在所有 gRPC 语言中工作，因为我们认为它是可扩展 RPC 系统的关键特性之一。

进一步来说：

  1. 如果一侧请求消息的速度很慢（MoveNext()），发送端最终将在发送时被“阻塞”（WriteAsync() 将需要更长的时间才能成功 - 并且您只能在每次调用时进行 WriteAsync() 操作） .

  2. 我相信可以通过 C-core 通道参数（C# 中的 ChannelOption）配置这些参数。

于 2018-01-23T17:29:43.777 回答