DRPC架構(gòu)怎么掌握

本篇內(nèi)容介紹了“DRPC架構(gòu)怎么掌握”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

架構(gòu)解析

有圖有真相， 我們先看看DRPC的架構(gòu)圖：

從上面的圖中看，整個DRPC分為了3個部分：

• Client: 真正使用DRPC服務(wù)的代碼

• DRPCServer: 從Client角度來看的DRPC服務(wù)器，就是它把DRPC所有的實現(xiàn)細節(jié)從Client的眼中隱藏了。

• Storm: 這里的Storm是指真正實現(xiàn)DRPC功能的storm的Spout, Bolt, 比如JoinResult, ReturnResults等等。

這里比較有意思的一點是對于DRPCServer來說，Client和Storm都是“客戶端”，只是干的工作不同，我們下面通過來分析下整個請求提交，返回的流程來看看它們各自都干了啥：

• 首先DRPCClient提交請求給DRPCServer

• DRPCServer首先給這個請求產(chǎn)生一個request-id, 然后把它丟到一個 request-id -> request池子里面

• DRPCServer在把request放入池子里面的時候，會同時生成一個Semaphore, 并且把這個Semaphore把放到一個 request-id -> semaphore池子里面去

• 同時它調(diào)用semaphore.acquire()來等在這個semaphore上面等待結(jié)果的到來。

• Storm組件從 request-id -> request池子中獲取需要處理的請求

• 通過DRPCSpout, PreapreRequest, JoinResult, ReturnResults一幫家伙去處理這個請求。

• 把處理完的請求結(jié)果發(fā)回到DRPCServer的 request-id -> result池子里面去。

• 同時會通過request-id去 request-id -> semaphore池子里面取出這個請求所對應(yīng)的semaphore, 并且調(diào)用semaphore.release()來釋放這個semaphore

• semaphore被釋放之后,DRPCServer上面阻塞的等待線程得以繼續(xù)執(zhí)行，去 request-id -> result池子里面把結(jié)果取出來，返回給等待的客戶端。

異步DRPC

Storm現(xiàn)在還不支持異步的DRPC, 不過要在上面的模型的基礎(chǔ)上去實現(xiàn)異步的DRPC應(yīng)該是很簡單的，我畫了一下大致是這樣的：

和上面的同步DRPC相比改動很?。?/p>

• 請求提交之后，服務(wù)器不會等在Semaphore上， 而是立即返回給客戶端一個Future對象。

• 這個Future對象帶了request-id的信息

• 在Client端維護一個 request-id -> result的池子, 客戶端將來調(diào)用future.get()的時候就是要到這個池子里面來找結(jié)果

• 服務(wù)器端發(fā)現(xiàn)請求的結(jié)果來了之后把回客戶端的結(jié)果池子里面去

“DRPC架構(gòu)怎么掌握”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！