原文地址：http://storm.apache.org/documentation/Distributed-RPC.html
分布式RPC的目的是在storm进行大量的实时计算时，能够并行的调用storm上的函数。Storm topology可以将函数参数作为输入Stream，并且将被调用方法产生的结果作为返回发送出去。
与其说DRPC是storm的一个特点，不如说它只是storm基本概念如steams，spouts，bolts和topologies的一种表达方式。DRPC可以独立于storm作为一个库发布，但在和storm捆绑在一起时将会非常有用。
高级概述
分布式RPC被“DRPC server”实现（storm包中已经有了对应的实例）。DRPC server协调接收一个RPC请求并将这个请求发送给storm topology，然后接收storm topology算出的结果，再将结果发送给等待中的客户端。从客户端的视角来看，分布式RPC调用过程跟普通的RPC调用过程一样。举例：这里有一个客户端调用“reach”方法，输入参数是http://twitter.com，然后得到计算结果的例子。
DRPCClient client = new DRPCClient("drpc-host", 3772);
String result = client.execute("reach", "http://twitter.com");
这个DRPC的工作流可以描述为：
一个客户端向DRPC Server发送了想要调用的方法名称和方法参数。实现了这个方法的topology用一个DRPCSpout从DRPC Server接收了函数调用Stream。每个远程方法在DRPC Server上都有一个唯一的ID。Topology计算出结果之后，使用一个ReturnResults的bolt连接DPRC Server后，将结果交给它。DRPC Server根据方法ID匹配出结果，然后唤醒等待的客户端，将结果发送给客户端
LinearDRPCTopologyBuilder（线性）
Storm中有一个LinearDRPCTopologyBuilder 的topology 生成，已经自动实现了DPRC调用过程中的绝大部分。包括：
1：配置spout
2：将结果返回给DPRC Server
3：为bolt提供了简单的tuple之间的聚合操作
让我们看一个简单的例子，这里有一个DPRC topology的实现，他可以给输入的参数后面添加一个“！”。
public static class ExclaimBolt extends BaseBasicBolt {
public void execute(Tuple tuple, BasicOutputCollector collector) {
String input = tuple.getString(1);
collector.emit(new Values(tuple.getValue(0), input + "!"));
}
public void declareOutputFields(OutputFieldsDeclarer declarer) {
declarer.declare(new Fields("id", "result"));
}
}
public static void main(String[] args) throws Exception {
LinearDRPCTopologyBuilder builder = new LinearDRPCTopologyBuilder("exclamation");
builder.addBolt(new ExclaimBolt(), 3);
// ...
}
就像我们看到的，代码非常简单。当我们创建一个LinearDRPCTopologyBuilder时，你告诉它实现了DRPC功能的topology的名字。一个DRPC server可以配置很多topology名称，这些名称不能重复。第一个bolt（不在代码中，应该是LinearDRPCTopologyBuilder内部的—译者注）会接受2个tuples，第一个属性是请求id，第二个是方法的参数。LinearDRPCTopologyBuilder中最后一个bolt返回了2个tuples的输出Stream，Stream的格式为[id, result]，当然了，过程中产生的所有tuple的第一个属性都是请求id。
在这个例子中，ExclaimBolt只是简单的在tuple的第二种属性上添加了一个“！”。LinearDRPCTopologyBuilder完成了连接DRPC server并返回结果的其他过程。
本地DRPC模式
DRPC可以在本地运行，例子：
LocalDRPC drpc = new LocalDRPC();
LocalCluster cluster = new LocalCluster();
cluster.submitTopology("drpc-demo", conf, builder.createLocalTopology(drpc));
System.out.println("Results for ‘hello‘:" + drpc.execute("exclamation", "hello"));
cluster.shutdown();
drpc.shutdown();
第一步，创建一个LocalDRPC对象。这个队形模拟DPRC server的运行，就像LocalCluster模拟集群运行一样。然后你创建一个LocalCluster在本地运行topology。LinearDRPCTopologyBuilder有独立的方法分布创建本地topology和远程topology。本地运行的LocalDRPC不需要绑定端口，因为在本地topology不需要端口来传递对象。这就是为什么createLocalTopology将LocalDRPC作为输入。
启动之后，你就可以看到DRPC调用过程在本地执行。
远程DRPC模式
在实际的集群上使用DRPC也非常简单，只需要三步：
1：启动DRPC server
2：配置DRPC server地址
3：将DRPC topology提交到storm集群
启动DRPC server就行启动Nimbus或UI一样简单
bin/storm drpc
接下来，你需要为storm集群配置DRPC的地址，才能DRPCSpout让知道在哪里读取方法调用。可以在storm.yaml中配置或者通过topology配置。在storm.yaml中配置如下
drpc.servers:
- "drpc1.foo.com"
- "drpc2.foo.com"
最后，你要通过StormSubmitter启动DPRC topology，就想启动任何topology一样。远程模式运行上面的例子你可以：
StormSubmitter.submitTopology("exclamation-drpc", conf, builder.createRemoteTopology());
createRemoteTopology用来为storm集群创建topology。
一个更复杂的例子
上面那个感叹号例子用来熟悉DPRC的概念还是过于简单。让我们看一个更复杂的例子，一个真正需要通过并行运行storm来计算的DRPC方法。例子就是计算Twitter上的URL的reach。
URL的reach就是这个URL暴漏给多少用户。为了计算reach，你需要：
1：获取这个URL的所有twitter
2：获取这些twitter的follower
3：去掉重复的follower
4：计算每个URL的follower
一个真实的计算需要数千次的数据库交互和上百万的flowwer记录的计算。这是非常非常碉堡的计算。但正如你所看到的，基于storm实现这个功能却非常的简单。在单台机器上，reach要花上数分钟来计算；但是在storm集群上，你可以在数秒钟就计算出最难算的URL的reach。
在storm-starter上有一个reach topology（here）样例，这里告诉你如何定义一个reach topology。
LinearDRPCTopologyBuilder builder = new LinearDRPCTopologyBuilder("reach");
builder.addBolt(new GetTweeters(), 3);
builder.addBolt(new GetFollowers(), 12)
.shuffleGrouping();
builder.addBolt(new PartialUniquer(), 6)
.fieldsGrouping(new Fields("id", "follower"));
builder.addBolt(new CountAggregator(), 2)
.fieldsGrouping(new Fields("id"));
这个topology计算一共需要四步：
1:GetTweeters获取了tweeted这个URL的用户。它将输入stream[id, url]转换成了一个输出Stream[id, tweeter]。每一个URL映射了多个用户tuple。
2：获取了每一个tweeter的followers（粉丝）。它将输入stream[id, tweeter]转换成了一个输出Stream [id, follower]。经过这个过程，由于一个follower是同时tweet了同一个URL的多个用户的粉丝，就会产生一些重复的follower tuple。
3.PartialUniquer将follower Stream按照follower和id分组，保证同一个follower会进入同一个task。所以每一个PartialUniquer 的task都会接收到相互独立的follower集合。当PartialUniquer接收了所有根据request id分配给它的follower tuples，它就会将去重之后的follower集合的数量发射出去。
4.最终，CountAggregator接收了每一个PartialUniquer task发射的数量，并且通过计算总和来完成reach的计算过程。
下面来看一下PartialUniquer bolt：
public class PartialUniquer extends BaseBatchBolt {
BatchOutputCollector _collector;
Object _id;
Set<String> _followers = new HashSet<String>();
@Override
public void prepare(Map conf, TopologyContext context, BatchOutputCollector collector, Object id) {
_collector = collector;
_id = id;
}
@Override
public void execute(Tuple tuple) {
_followers.add(tuple.getString(1));
}
@Override
public void finishBatch() {
_collector.emit(new Values(_id, _followers.size()));
}
@Override
public void declareOutputFields(OutputFieldsDeclarer declarer) {
declarer.declare(new Fields("id", "partial-count"));
}
}
PartialUniquer通过继承BaseBatchBolt实现了IBatchBolt接口。批处理bolt提供了一流的API可以将批量的tuples当作一个批次来处理。每一个request id都会创建一个batch bolt实例，而storm负责在适当的时候清理这些实例。
每当PartialUniquer在execute方法中接收到一个follower tuple，它就将follower放到request id对应的set集合中。
当发射到这个bolt的所有tuples都被处理之后，batch bolts中的finishBatch方法将会被调用。 PartialUniquer发射了一个包含follower数量的tuple。
在后台，CoordinatedBolt用来判断bolt是否全部接受了指定request id的所有tuple。CoordinatedBolt利用直接Stream来管理这次协调。
这个topology的剩余部分就显而易见了。就像你看到的，reach计算的每一步都是并行计算，而且实现DRPC topology是多么的简单。
Non-linear（非线性）DRPC topologies
LinearDRPCTopologyBuilder只能处理线下的DRPC topologies：整个计算可以分割为多个独立的顺序步骤。它很难处理包含有bolt分支和bolt合并的复杂topology。目前，为了实现复杂的功能，你只能通过直接使用CoordinatedBolt。
LinearDRPCTopologyBuilder如何工作
DRPCSpout发射了[args, return-info].return-info中包含DRPC的地址和端口，就像DRPC的id一样。
构建一个topology包含：
- DRPCSpout
- PrepareRequest（准备请求：产生一个request id并为return-info和参数分别创建一个Stream）
- CoordinatedBolt wrappers and direct groupings（CoordinatedBolt封装和直接分组）
- JoinResult（将result-info加入结果）
- ReturnResult（连接DRPC server 并返回结果）
LinearDRPCTopologyBuilder是一个非常好storm高级抽象的例子
高级
KeyedFairBolt封装同时处理多个请求
如何直接使用CoordinatedBolt