hadoop 2.6 源码解读之RPC Server 类高性能设计
2018-04-10 17:11
603 查看
hadoop 2.6 采用 谷歌protocol buffer作为通信协议,但是protocol buffer 相对于Thrift ,需要自己实现一套底层通信框架。
hadoop Server类及其相关类,采用java NIO 及 多reactor 模式,外加多线程,实现了服务端高并发通信,构建了强有力的分布式基础设施。
今天剖析下其代码实现。
hadoop 为提高效率,使用了三类reactor :
1、用于监听连接的 selector (一个)
2、用于监听读事件的 readSelector (每个reader 线程一个)
3、用于监听写事件的 writeSelector (一个)
如Reader 线程
hadoop Server类及其相关类,采用java NIO 及 多reactor 模式,外加多线程,实现了服务端高并发通信,构建了强有力的分布式基础设施。
今天剖析下其代码实现。
多reactor
java NIO 服务端 reactor 模式实现的关键是 Selector 类对象,Selector 监控需要观察的事件,并返回就绪的 Set < SelectionKey>,然后进行处理。hadoop 为提高效率,使用了三类reactor :
1、用于监听连接的 selector (一个)
2、用于监听读事件的 readSelector (每个reader 线程一个)
3、用于监听写事件的 writeSelector (一个)
多线程
服务端所用的线程池并非是ExecutorService,而是构造的线程数组如Reader 线程
for (int i = 0; i < readThreads; i++) { Reader reader = new Reader( "Socket Reader #" + (i + 1) + " for port " + port); readers[i] = reader; reader.start(); }
服务端使用了四组线程
Listener:
单个线程,用于监听连接,持有selector ,然后从 Reader[]线程组内挑选一个线程接受监听好的SelectionKeyReader[]:
reader 线程组负责读取连接上的读请求,并传递给 Handler线程组,每个线程持有一个readSelectorHandler[]:
hander 线程组负责处理请求并返回响应,未能成功返回的响应交ResponderResponder:
持有一个writeSelector,监听写事件线程之间的通信
reader hander ,这两个线程组,通过callQueue进行数据交互,callQueue是两个线程类的外部类Server类的成员//外部类 Server类的成员 CallQueueManager< Call > callQueue
相关文章推荐
- Hadoop RPC的机制分析和源码解读
- hadoop 2.6 源码 解读之NameNodeRpcServer启动及request处理
- hadoop源码研读之路(六)----RPC的Client端和Server端
- 高性能server分析 - Hadoop的RpcServer
- Hadoop RPC源码阅读-服务端Server
- Hadoop源码分析之一(RPC机制之Server)
- Hadoop RPC源码分析之Server
- Hadoop源码分析之一(RPC机制之Server)
- 细水长流Hadoop源码分析(3)RPC Server初始化启动过程
- Hadoop之RPC Server源码分析
- hadoop源码研读之路(六)----RPC的Client端和Server端
- Hadoop RPC源码解析——Server类(一)
- Hadoop源码分析之一(RPC机制之Server)
- Hadoop RPC源码解析——Server类(二)
- spring 源码解读与设计详解: 7 BeanDefinitionParserDelegate深入解读
- hadoop源码解读——Configured
- 别人家SDK的设计模式——Android Retrofit库源码解读
- hadoop的RPC机制源码分析
- [Hadoop源码解读](二)MapReduce篇之Mapper类
- python uiautomator 源码学习(三) josonRPCServer-DUT Side