Java gRPC服务器对于长期流的有效实现

如何解决Java gRPC服务器对于长期流的有效实现

我想了解gRPC框架的一部分，该框架用于长期流的资源管理。 假设我们有无限的稀有事件（每秒钟一次），这些事件我们想通过grpc流传输给客户端。 这些事件是由服务器上的单个应用程序线程生成的。

我看到了两种可能的流事件实现：

1. 在rpc调用中旋转调用者线程，并通过（阻塞）队列与源进行通信
2. 将StreamObserver暴露给事件生成线程，并从那里填充所有客户端流。

选项一看似简单，但线程数却有点沉重-每个客户端一个线程用于稀疏流似乎是一种过大的杀伤力。每个线程占用一些堆占用调度程序，等等。

选项二看起来更加资源友好。但是，我在互联网上找不到任何材料来支持这种方法。我不确定gRPC服务器不会意外关闭ServerCall或Context，从而导致流突然关闭。否则可能会有我不知道的其他副作用。

所以我的问题是： 推荐使用长寿命流的方法是什么？ 是否有其他可能的方法来实现所描述的问题。 选项2是合法的还是一个应该坚持使用1个客户端1个线程的方法？

我试图用选项2创建一个原型，它似乎正在工作。 但是我仍然想得到答案。

解决方法

从gRPC的角度来看，两种方法都很好。方便时，您可以随意使用1个客户端，1个线程方法。对于流媒体情况，通常最好避免在调用者线程中旋转，但是您可以使用第二个线程来发送。那很正常。另一方面，将StreamObserver传递给单个线程进行管理具有资源优势，也是一种很好的方法。

当事件的生成速度比发送事件的速度快（即流控制）时，您应该考虑如何响应速度较慢的客户端。

您将需要将提供的StreamObserver转换为ServerCallStreamObserver以访问其他API。它提供setOnReadyHandler(Runnable)和isReady()用于检测速度较慢的客户端。 gRPC Java允许您即使尚未准备就绪也可以调用onNext(...)，但这样做会缓冲。

就绪处理程序是一个使用与调用方线程相同的线程的回调，因此，如果您调入调用方线程，则将无法接收该回调。这就是为什么对于流传输，通常最好避免在调用者线程中旋转。

使用专用的发送线程具有以下优点：生产者和使用者之间的队列清晰且分离。您可以选择队列大小，并确定该队列已满时该怎么办。在一个线程中直接与StreamObserver进行交互具有较少的资源使用。两种选择的复杂性各不相同。方法的“正确”选择是基于规模，资源考虑因素，服务的详细信息以及您的偏好。