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