如何实现无损 grpc-streaming 调用？答案

【问题标题】：How to implement lossless grpc-streaming calls?如何实现无损 grpc-streaming 调用？
【发布时间】：2019-11-25 12:26:04
【问题描述】：

我在 java 中使用 grpc-streaming。我有一个持久的开放流，客户端和服务器同时通信。当我调用onNext 发送消息时，grpc 会在内部缓冲消息，并将其通过网络异步发送。现在，如果流在发送数据的过程中丢失，则调用onError。我想知道什么是正确的做法：

目前，我正在考虑在应用层实现一个“ack”机制，对于接收到的每 x 个项目，接收者会发送回一个 ack 消息。然后为了实现重试，我需要在发送方缓冲项目，并且只有在收到 ack 时才将它们从缓冲区中删除。另外，在接收方，我需要实现一种机制来忽略收到的重复项。

示例： 假设我们每发送 100 个项目就发送一个 ack。我们在第 3 批 (200-300) 上收到 ack，然后在发送项目 300-400 时收到错误。我们再次尝试发送项目 300-400 但客户端已成功收到 300-330 并且它将再次接收它们。因此，客户端需要忽略前 30 项。

可以在应用层实现这一点。但是，我想知道是否有更好的实践/框架可以解决这个问题。

【问题讨论】：

【解决方案1】：

经常使用的术语是保证交付来描述从一个地方到另一个地方没有丢失的交付数据。

您的用例类似于尝试通过 UDP 等尽力而为的交付传输层提供有保证的交付。通常的方法是确认每个数据包，尽管您可以按照您的建议设计一个在更高级别进行检查的方案。

您通常还希望使用某种形式的滑动窗口，这意味着您不必在发送下一个数据包之前等待上一个 ack - 这有助于避免延迟。

在这个答案中有一个很好的关于 UDP 的方法的概述：https://stackoverflow.com/a/15630015/334402

对于您的情况，您将收到 RPC 调用的响应，该响应实际上是确认 - 使用滑动窗口可以让您在收到前一个确认之前进行下一个调用。

您的重复交付示例也很常见 - 避免重复计算或混淆的一种常见方法是获取数据包编号并简单地丢弃任何重复的数据包。

【讨论】：