我有一个用例，其中许多客户端需要不断向服务器发送大量指标(几乎是永久的)。服务器需要存储这些事件，并在以后处理它们。我不希望服务器对这些事件有任何响应。
我正在考虑为此使用grpc。最初，我认为客户端流可以做( like how envoy does )，但问题是客户端流不能确保在应用程序级别的可靠交付(即，如果流在两者之间关闭，则发送的消息实际上是由服务器)，我负担不起。
我的思考过程是，我应该使用双向流、服务器流中的 ack 或多个一元 rpc 调用(可能在重复字段中对事件进行批处理以提高性能)。
这些哪个会更好？
最佳答案
the issue is that client side streaming cannot ensure reliable delivery at application level (i.e. if the stream closed in between, how many messages that were sent were actually processed by the server) and I can't afford this
这意味着您需要回应。即使响应只是一个确认，从 gRPC 的角度来看，它仍然是一个响应。
一般方法应该是“使用一元”，除非可以通过流解决足够大的问题以克服其复杂性成本。我讨论过这个 at 2018 CloudNativeCon NA (视频有幻灯片和 YouTube 的链接)。
例如，如果您有多个后端，那么每个一元 RPC 可能会发送到不同的后端。这可能会导致这些各种后端同步自身的高开销。流式 RPC 在开始时选择一个后端并继续使用相同的后端。因此，流式传输可能会降低后端同步的频率，并在服务实现中实现更高的性能。但是当发生错误时，流式传输会增加复杂性，在这种情况下，它会导致 RPC 变得长期存在，从而使负载平衡更加复杂。因此，您需要权衡流/长生命周期 RPC 增加的复杂性是否为您的应用程序提供了足够大的好处。
我们通常不建议使用流式 RPC 来获得更高的 gRPC 性能。确实，在流上发送消息比新的一元 RPC 更快，但改进是固定的，并且具有更高的复杂性。相反，我们建议使用流式 RPC，因为它可以提供更高的应用程序(您的代码)性能或更低的应用程序复杂性。
关于stream - 多个一元 rpc 调用与 grpc 中长时间运行的双向流？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56766921/