gRPC Streaming 的具体保证是什么？

Question

我一直很难理解 gRPC 流的确切保证。主要是因为我听过/读到过与之相矛盾的故事。 我的问题如下： 如果我有一个流

[A, B, C]

发送到

Server X

，无论是服务器端流、客户端流还是 Bidi 流，是否有可能：

Server Y

只收到

Server Y

但

[A, C]

丢失了，而

B

或

Server X

没有注意到任何错误？我的假设是，由于 http2 是基于 TCP 构建的，因此所有元素必须至少传递到

Server Y

的内核。因此，如果没有崩溃或连接爆炸，我认为不可能丢失整个消息。 但有些同事告诉我事实并非如此，它只能保证它们是有序的，但中间可能会丢失元素。

任何人都可以阐明 gRPC 流的确切交付保证吗？ 任何进一步阅读有关此内容的链接也将不胜感激。 谢谢！

Answer 1

gRPC 的核心概念、架构和生命周期

确实说了这样的事情：

gRPC 保证单个 RPC 调用内的消息排序。

我同意“排序”，而不是“保留所有消息”。所以我能理解这个论点一些。但一般来说，如果 gRPC 中丢失了某些内容，那就是一个错误。如果

Server Y

被丢弃，则错误必须发生在 B 被传递之前，因为流是有序的（因此

C

永远不会被传递）。 gRPC 中唯一的无序行为是取消。您可以将流视为基于消息的 TCP 连接，尽管具有不同的关闭语义（即服务器不能半关闭，这是人们通常假设的行为）。请注意，如果服务器在客户端流式 RPC 中读取所有入站消息之前关闭（正常或错误）RPC，则剩余的入站消息将被丢弃。但是剩余的消息全部被丢弃，RPC 本身也完成了。所以这并不是什么令人惊讶的情况，除了 gRPC 允许服务器在没有实际看到所有消息的情况下响应 OK/成功。