本文介紹了Java GRPC服務器對長壽命流的有效實現的處理方法，對大家解決問題具有一定的參考價值，需要的朋友們下面隨著小編來一起學習吧！
問題描述
我想了解GRPC框架的一部分，用于長期流的資源管理。
假設我們有無限的罕見事件源(大約每秒一次)，我們希望通過GRPC流的方式將這些事件流到客戶端。
這些事件由服務器上的單個應用程序線程生成。
我看到兩種可能的事件流實現：
-
在RPC調用中調入調用者線程，并通過(阻塞)隊列與源進行通信
向事件生成線程公開StreamWatch，并從那里填充所有客戶端流。
選項一看起來很簡單，但線程計數有點重-稀疏流的每個客戶端一個線程似乎有點過頭了。每個線程占用一些堆，占用調度程序，等等。
選項2看起來對資源更友好。然而，我在互聯網上找不到任何支持這種方法的材料。我不確定GRPC服務器不會意外關閉ServerCall或上下文，從而導致流突然關閉?；蛘呖赡苓€有其他一些我不知道的副作用。
所以我的問題是：
推薦的實現長壽命流的方法是什么？
是否有任何其他可能的方法來實現所描述的問題。
選項2是合法的，還是應該堅持使用1個客戶端1線程方法？
我嘗試使用選項2創建一個原型，它似乎起作用了。
但我仍然希望得到答案。
推薦答案
從GRPC的角度來看，這兩種方法都很好。在方便的時候，您可以自由地使用一個客戶端、一個線程的方法。對于流的情況，通常最好避免在調用方線程中旋轉，但您可以使用第二個線程來發送；這是很正常的。另一方面，將StreamObserver傳遞給單個線程進行管理會帶來資源上的好處，也是一種很好的方法。
當生成事件的速度快于發送事件的速度(即，流控制)時，您應該考慮如何響應速度較慢的客戶端。
您需要將提供的StreamObserver轉換為ServerCallStreamObserver以訪問其他接口。提供檢測慢客戶端的setOnReadyHandler(Runnable)和isReady()。GRPC Java允許您在尚未準備好的情況下調用onNext(...)，但這樣做將會緩沖。
On-Ready處理程序是一個回調函數，它使用與調用者線程相同的線程，因此如果您在調用者線程中旋轉，您將無法接收該回調。這就是為什么對于流，通常最好避免在調用方線程中旋轉。
使用專用發送線程的優點是隊列清晰，生產者和消費者之間可以分離。您可以選擇隊列大小，并決定在該隊列已滿時執行什么操作。在一個線程中直接與StreamObserver交互會占用較少的資源。這兩種選擇的復雜程度各不相同。選擇正確的方法取決于規模、資源考慮因素、服務細節和您的首選項。
這篇關于Java GRPC服務器對長壽命流的有效實現的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，
