Twitter Storm源代码分析之DRPC架构细节

作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://xumingming.sinaapp.com/765/twitter-storm-code-analysis-drpc-arch/

 

概述

在前一篇文章中我们介绍了Storm DRPC是怎么利用Storm提供的Tuple, Spout, Bolt, Topology这些原语封装出来的，可以说确实很精妙，那篇文章的重点是如何利用原语来实现DRPC的功能。这篇文章我们来看一看整个Storm 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()的时候就是要到这个池子里面来找结果
• 服务器端发现请求的结果来了之后把回客户端的结果池子里面去