<hadoop>reactor模式

这几天看hadoop，在RPC框架中用到了reactor模式，专门学习了一下。在此记录

reactor模式经典的说明是Doug Lea的 Scalable IO In Java

以Logging Server来分析Reactor模式，这个Logging Server的实现完全遵循这里对Reactor描述，因而放在这里以做参考。Logging Server中的Reactor模式实现分两个部分：Client连接到Logging Server和Client向Logging Server写Log。因而对它的描述分成这两个步骤。

1. Logging Server注册LoggingAcceptor到InitiationDispatcher。
2. Logging Server调用InitiationDispatcher的handle_events()方法启动。
3. InitiationDispatcher内部调用select()方法（Synchronous Event Demultiplexer），阻塞等待Client连接。
4. Client连接到Logging Server。
5. InitiationDisptcher中的select()方法返回，并通知LoggingAcceptor有新的连接到来。 
6. LoggingAcceptor调用accept方法accept这个新连接。
7. LoggingAcceptor创建新的LoggingHandler。(这个地方是重点，稍难理解，是accptor向新的eventHandler转变的地方)
8. 新的LoggingHandler注册到InitiationDispatcher中(同时也注册到Synchonous Event Demultiplexer中)，等待Client发起写log请求。

1. Client发送log到Logging server。
2. InitiationDispatcher监测到相应的Handle中有事件发生，返回阻塞等待，根据返回的Handle找到LoggingHandler，并回调LoggingHandler中的handle_event()方法。
3. LoggingHandler中的handle_event()方法中读取Handle中的log信息。
4. 将接收到的log写入到日志文件、数据库等设备中。
3.4步骤循环直到当前日志处理完成。
5. 返回到InitiationDispatcher等待下一次日志写请求。

EventHandler接口定义

对EventHandler的定义有两种设计思路：single-method设计和multi-method设计：
A single-method interface： 它将Event封装成一个Event Object，EventHandler只定义一个handle_event(Event event)方法。这种设计的好处是有利于扩展，可以后来方便的添加新的Event类型，然而在子类的实现中，需要判断不同的Event类型而再次扩展成 不同的处理方法，从这个角度上来说，它又不利于扩展。另外在Netty3的使用过程中，由于它不停的创建ChannelEvent类，因而会引起GC的不稳定。
A multi-method interface： 这种设计是将不同的Event类型在 EventHandler中定义相应的方法。这种设计就是Netty4中使用的策略，其中一个目的是避免ChannelEvent创建引起的GC不稳定， 另外一个好处是它可以避免在EventHandler实现时判断不同的Event类型而有不同的实现，然而这种设计会给扩展新的Event类型时带来非常 大的麻烦，因为它需要该接口。

关于Netty4对Netty3的改进可以参考这里：

ChannelHandler with no event object

In 3.x, every I/O operation created a  ChannelEvent object. For each read / write, it additionally created a new  ChannelBuffer. It simplified the internals of Netty quite a lot because it delegates resource management and buffer pooling to the JVM. However, it often was the root cause of GC pressure and uncertainty which are sometimes observed in a Netty-based application under high load.

4.0 removes event object creation almost completely by replacing the event objects with strongly typed method invocations. 3.x had catch-all event handler methods such as handleUpstream() and handleDownstream(), but this is not the case anymore. Every event type has its own handler method now:

Reactor模式参与者

1.Reactor 负责响应IO事件，一旦发生，广播发送给相应的Handler去处理,这类似于AWT的thread
2.Handler 是负责非堵塞行为，类似于AWT ActionListeners；同时负责将handlers与event事件绑定，类似于AWT addActionListener

如图：

Java的NIO为reactor模式提供了实现的基础机制，它的Selector当发现某个channel有数据时，会通过SlectorKey来告知我们，在此我们实现事件和handler的绑定。

我们来看看Reactor模式代码:

public class Reactor implements Runnable{
　　final Selector selector;
　　final ServerSocketChannel serverSocket;

　　Reactor(int port) throws IOException {
　　　　selector = Selector.open();
　　　　serverSocket = ServerSocketChannel.open();
　　　　InetSocketAddress address = new InetSocketAddress(InetAddress.getLocalHost(),port);
　　　　serverSocket.socket().bind(address);

　　　　serverSocket.configureBlocking(false);
　　　　//向selector注册该channel
　　　　 SelectionKey sk =serverSocket.register(selector,SelectionKey.OP_ACCEPT);

　　　　logger.debug("-->Start serverSocket.register!");

　　　　//利用sk的attache功能绑定Acceptor 如果有事情，触发Acceptor
　　　　sk.attach(new Acceptor());
　　　　logger.debug("-->attach(new Acceptor()!");
　　}


　　public void run() { // normally in a new Thread
　　　　try {
　　　　while (!Thread.interrupted())
　　　　{
　　　　　　selector.select();
　　　　　　Set selected = selector.selectedKeys();
　　　　　　Iterator it = selected.iterator();
　　　　　　//Selector如果发现channel有OP_ACCEPT或READ事件发生，下列遍历就会进行。
　　　　　　while (it.hasNext())
　　　　　　　　//来一个事件 第一次触发一个accepter线程
　　　　　　　　//以后触发SocketReadHandler
　　　　　　　　dispatch((SelectionKey)(it.next()));
　　　　　　　　selected.clear();
　　　　　　}
　　　　}catch (IOException ex) {
　　　　　　　　logger.debug("reactor stop!"+ex);
　　　　}
　　}

　　//运行Acceptor或SocketReadHandler
　　void dispatch(SelectionKey k) {
　　　　Runnable r = (Runnable)(k.attachment());
　　　　if (r != null){
　　　　　　// r.run();

　　　　}
　　}

　　class Acceptor implements Runnable { // inner
　　　　public void run() {
　　　　try {
　　　　　　logger.debug("-->ready for accept!");
　　　　　　SocketChannel c = serverSocket.accept();
　　　　　　if (c != null)
　　　　　　　　//调用Handler来处理channel
　　　　　　　　new SocketReadHandler(selector, c);
　　　　　　}
　　　　catch(IOException ex) {
　　　　　　logger.debug("accept stop!"+ex);
　　　　}
　　　　}
　　}
}

以上代码中巧妙使用了SocketChannel的attach功能，将Hanlder和可能会发生事件的channel链接在一起，当发生事件时，可以立即触发相应链接的Handler。
再看看Handler代码:

ublic class SocketReadHandler implements Runnable {
　　public static Logger logger = Logger.getLogger(SocketReadHandler.class);

　　private Test test=new Test();

　　final SocketChannel socket;
　　final SelectionKey sk;

　　 static final int READING = 0, SENDING = 1;
　　int state = READING;

　　public SocketReadHandler(Selector sel, SocketChannel c)
　　　　throws IOException {

　　　　socket = c;

　　　　socket.configureBlocking(false);
　　　　 sk = socket.register(sel, 0);

　　　　//将SelectionKey绑定为本Handler 下一步有事件触发时，将调用本类的run方法。
　　　　//参看dispatch(SelectionKey k)
　　　　sk.attach(this);

　　　　//同时将SelectionKey标记为可读，以便读取。
　　　　sk.interestOps(SelectionKey.OP_READ);
　　　　sel.wakeup();
　　}

　　public void run() {
　　　　try{
　　　　// test.read(socket,input);
　　　　　　readRequest() ;
　　　　}catch(Exception ex){
　　　　logger.debug("readRequest error"+ex);
　　　　}
　　}


/**
* 处理读取data
* @param key
* @throws Exception
*/
private void readRequest() throws Exception {

　　ByteBuffer input = ByteBuffer.allocate(1024);
　　input.clear();
　　try{

　　　　int bytesRead = socket.read(input);

　　　　......

　　　　//激活线程池 处理这些request
　　　　requestHandle(new Request(socket,btt));

　　　　.....


　　}catch(Exception e) {
　　}

}

注意在Handler里面又执行了一次attach，这样，覆盖前面的Acceptor，下次该Handler又有READ事件发生时，将直接触发Handler.从而开始了数据的读　处理　写　发出等流程处理。

将数据读出后，可以将这些数据处理线程做成一个线程池，这样，数据读出后，立即扔到线程池中，这样加速处理速度：

更进一步，我们可以使用多个Selector分别处理连接和读事件。

一个高性能的Java网络服务机制就要形成，激动人心的集群并行计算即将实现。

http://www.jdon.com/concurrent/reactor.htm