DRPC架構怎么掌握

本篇內容介紹了“DRPC架構怎么掌握”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

架構解析

有圖有真相， 我們先看看DRPC的架構圖：

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

• Client: 真正使用DRPC服務的代碼

• DRPCServer: 從Client角度來看的DRPC服務器，就是它把DRPC所有的實現細節從Client的眼中隱藏了。

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

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

• 首先DRPCClient提交請求給DRPCServer

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

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

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

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

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

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

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

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

異步DRPC

Storm現在還不支持異步的DRPC, 不過要在上面的模型的基礎上去實現異步的DRPC應該是很簡單的，我畫了一下大致是這樣的：

和上面的同步DRPC相比改動很小：

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

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

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

• 服務器端發現請求的結果來了之后把回客戶端的結果池子里面去

“DRPC架構怎么掌握”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！