DRPC ,Distributed Remote Procedure Call
RPC本身是個成熟和古老的概念, Storm裡面引入DRPC主要是利用storm的實時計算能力來并行化CPU intensive的計算
DRPC, 隻是storm應用的一個場景, 并且storm提供相應的程式設計架構, 以友善程式員
提供DRPC server的實作, 并提供對DRPC場景經行封裝的Topology
對于storm, Topology内部其實是沒有任何差別的, 主要就是實作和封裝Topology和DRPC Server之間互動的spout和bolt
具體互動過程如下圖,
Storm封裝了這樣一個Topology實作LinearDRPCTopologyBuilder的topology builder
會使用<code>DRPCSpout</code>從DRPC伺服器接收函數調用流, 每個函數調用被DRPC伺服器标記了一個唯一的id.
這個topology然後計算結果, 在topology的最後一個叫做<code>ReturnResults</code>的bolt會連接配接到DRPC伺服器, 并且把這個調用的結果發送給DRPC伺服器(通過那個唯一的id辨別).
DRPC伺服器用那個唯一id來跟等待的用戶端比對上,喚醒這個用戶端并且把結果發送給它.
使用LinearDRPCTopologyBuilder
首先, 使用builder建立topology的時候, topology name要等于function name(PRC call)
其次, 這裡不需要指定spout, 因為已經做了封裝, 會自動從DRPC server讀取資料
再者, 所有bolt的輸出的第一個field必須是request-id, 最後一般bolt的輸出一定是(request-id, result)
最後, builder會自動将結果發給DRPC server
前面的例子, 無法說明為什麼要使用storm來實作RPC, 那個操作直接在RPC server上就可以完成
當隻有對并行計算和資料量有一定要求時, 才能展現出價值...
ReachTopology, 每個人發送的URL都會被所有follower收到, 是以要計算某URL的reach, 隻需要如下幾步,
找出所有發送該URL的tweeter, 取出他們的follower, 去重複, 計數
Let's look at a more complex example which really needs the parallelism a Storm cluster provides for computing the DRPC function.
The example we'll look at is computing the reach of a URL on Twitter.
The reach of a URL is the number of unique people exposed to a URL on Twitter. To compute reach, you need to:
Get all the people who tweeted the URL
Get all the followers of all those people
Unique the set of followers
Count the unique set of followers
首先對于LinearDRPCTopologyBuilder中, 沒有各個spout和bolt的id, 可能因為是線性的, 是以沒有必要顯式指明關系, 按加入順序就可以
GetTweeters(), 輸入(rpc-id, url), 輸出(rpc-id, tweeter)
GetFollowers(), 輸入(rpc-id, tweeter), 輸出(rpc-id, follower)
對于PartialUniquer仔細分析一下,
首先是基于id和follower的grouping, fieldsGrouping(new Fields("id", "follower")), 因為可能由多個RPC同時執行, 是以隻需要保證同一個RPC的followers被發到同一個task即可.
接着繼承BaseBatchBolt, 可以在finishBatch中emit結果
使用HashSet來存放follower, 保證不重複
目前LinearDRPCTopologyBuilder隻能handle線性的bolt workflow
<code>LinearDRPCTopologyBuilder</code> only handles "linear" DRPC topologies, where the computation is expressed as a sequence of steps (like reach). It's not hard to imagine functions that would require a more complicated topology with branching and merging of the bolts. For now, to do this you'll need to drop down into using <code>CoordinatedBolt</code> directly. Be sure to talk about your use case for non-linear DRPC topologies on the mailing list to inform the construction of more general abstractions for DRPC topologies.