亚洲视频在线观看地址,亚洲人成77777在线播放网站不卡,国产亚洲免费的视频看

Netty3架构解析

DLevin — Fri, 04 Sep 2015 01:40:00 GMT

前记

很早以前��有读Netty源码的打��了�Q�然而第一�ơ尝试的时候从Netty4开始，一直抓不到核心的框架流�E�，后来因�ؓ其他事情忙着��放下了。这�ơ趁着休假重新捡�v�q�个��骨��_��因�ؓNetty3现在�q�在被很多项目��用，因而这�ơ决定先从Netty3入手�Q�瞬间发现Netty3的代码比Netty4中规中矩的多�Q�很多概念在代码本��n中都有清晰的表达�Q�所以半天就把整个框架的骨架搞清楚了。再�?a >Netty4对Netty3的改�q��ȝ��Q�回去读Netty4的源码，反而觉得轻松了�Q�一�U�豁然开朗的感觉�?br />
记得��d��读Jetty源码的时候，因�ؓ代码太庞大，�q�且自己的HTTP Server的了解太��，因而只能自底向上的一个一个模块的叠加�Q�直到最后把所以的模块�q�接在一赯��看清它的真正核心骨架。现在读源码�Q�开始习惯先把骨架理清，然后延��C��同的器官、血肉而看清整个�h体�?br />
本文从Reactor模式在Netty3中的应用�Q�引出Netty3的整体架构以及控制流�E�；然而除了Reactor模式�Q�Netty3�q�在ChannelPipeline中��用了Intercepting Filter模式�Q�这个模式也在Servlet的Filter中成功��用，因而本文还会从Intercepting Filter模式出发详细介绍ChannelPipeline的设计理��c��本文假设读者已�l�对Netty有一定的了解�Q�因而不会包含过多入门介�l�，以及帮Netty做宣传的文字�?br />

Netty3中的Reactor模式

Reactor模式在Netty中应用非常成功，因而它也是在Netty中受大肆宣传的模式，关于Reactor模式可以详细参考本人的另一��文�?a href="http://www.tkk7.com/DLevin/archive/2015/09/02/427045.html">《Reactor模式详解�?/a>�Q�对Reactor模式的实现是Netty3的基本骨�Ӟ��因而本��节会详�l�介�l�Reactor模式如何应用Netty3中�?br />
如果诅R��Reactor模式详解》，我们知道Reactor模式由Handle、Synchronous Event Demultiplexer、Initiation Dispatcher、Event Handler、Concrete Event Handler构成�Q�在Java的实现版本中�Q�Channel对应Handle�Q�Selector对应Synchronous Event Demultiplexer�Q��ƈ且Netty3�q��用了两层Reactor�Q�Main Reactor用于处理Client的连接请求，Sub Reactor用于处理和Client�q�接后的��d��h��Q�关于这个概念还可以参考Doug Lea的这��PPT�Q?a >Scalable IO In Java�Q�。所以我们先要解决Netty3中��用什么类实现所有的上述模块�q�把他们联系在一��L��Q�以NIO实现方式��Z��Q?br />
模式是一�U�抽象，但是在实��C��Q�经�怼�因�ؓ语言�Ҏ��、框架和性能需要而做一些改变，因而Netty3对Reactor模式的实现有一套自��q��设计�Q?br />1. ChannelEvent�Q?/strong>Reactor是基于事件编�E�的�Q�因而在Netty3中��用ChannelEvent抽象的表达Netty3内部可以产生的各�U�事�Ӟ��所有这些事件对象在Channels帮助�c�M��产生�Q��ƈ且由它将事�g推入到ChannelPipeline中，ChannelPipeline构徏ChannelHandler��道�Q�ChannelEvent��经�q�个��道实现所有的业务逻辑处理。ChannelEvent对应的事件有�Q�ChannelStateEvent表示Channel状态的变化事�g�Q�而如果当前Channel存在Parent Channel�Q�则该事件还会传递到Parent Channel的ChannelPipeline中，如OPEN、BOUND、CONNECTED、INTEREST_OPS�{�，该事件可以在各种不同实现的Channel、ChannelSink中��生；MessageEvent表示从Socket中读取数据完成、需要向Socket写数据或ChannelHandler对当前Message解析(如Decoder、Encoder)后触发的事�g�Q�它由NioWorker、需要对Message做进一步处理的ChannelHandler产生�Q�WriteCompletionEvent表示写完成而触发的事�g�Q�它由NioWorker产生�Q�ExceptionEvent表示在处理过�E�中出现的Exception�Q�它可以发生在各个构件中�Q�如Channel、ChannelSink、NioWorker、ChannelHandler中；IdleStateEvent由IdleStateHandler触发�Q�这也是一个ChannelEvent可以无缝扩展的例子。注�Q�在Netty4后，已经没有ChannelEvent�c�，所有不同事仉��用对应方法表达，�q�也意味�q�ChannelEvent不可扩展�Q�Netty4采用在ChannelInboundHandler中加入userEventTriggered()�Ҏ��来实现这�U�扩展，具体可以参�?a >�q�里�?br />2. ChannelHandler�Q?/strong>在Netty3中，ChannelHandler用于表示Reactor模式中的EventHandler。ChannelHandler只是一个标记接口，它有两个子接口：ChannelDownstreamHandler和ChannelUpstreamHandler�Q�其中ChannelDownstreamHandler表示从用户应用程序流向Netty3内部直到向Socket写数据的��道�Q�在Netty4中改名�ؓChannelOutboundHandler�Q�ChannelUpstreamHandler表示数据从Socket�q�入Netty3内部向用户应用程序做数据处理的管道，在Netty4中改名�ؓChannelInboundHandler�?br />3. ChannelPipeline�Q?/strong>用于��理ChannelHandler的管道，每个Channel一个ChannelPipeline实例�Q�可以运行过�E�中动态的向这个管道中��d��、删除ChannelHandler�Q�由于实现的限制�Q�在最末端的ChannelHandler向后��d��或删除ChannelHandler不一定在当前执行��程中�v效，参�?a >�q�里�Q�。ChannelPipeline内部�l�护一个ChannelHandler的双向链表，它以Upstream(Inbound)方向为正向，Downstream(Outbound)方向为方向。ChannelPipeline采用Intercepting Filter模式实现�Q�具体可以参�?a href="http://www.tkk7.com/DLevin/archive/2015/09/03/427086.html">�q�里�Q�这个模式的实现在后一节中�q�是详细介绍�?br />4. NioSelector�Q?/strong>Netty3使用NioSelector来存放Selector�Q�Synchronous Event Demultiplexer�Q�，每个��C�生的NIO Channel都向�q�个Selector注册自己以让�q�个Selector监听�q�个NIO Channel中发生的事�g�Q�当事�g发生�Ӟ��调用帮助�c�Channels中的�Ҏ��生成ChannelEvent实例�Q�将该事件发送到�q�个Netty Channel对应的ChannelPipeline中，而交�l�各�U�ChannelHandler处理。其中在向Selector注册NIO Channel�Ӟ��Netty Channel实例以Attachment的�Ş式传入，该Netty Channel在其内部的NIO Channel事�g发生�Ӟ��会以Attachment的�Ş式存在于SelectionKey中，因而每个事件可以直接从�q�个Attachment中获取相关链的Netty Channel�Q��ƈ从Netty Channel中获取与之相兌��的ChannelPipeline�Q�这个实现和Doug Lea�?a >Scalable IO In Java一模一栗��另外Netty3�q�采用了Scalable IO In Java中相同的Main Reactor和Sub Reactor设计�Q�其中NioSelector的两个实玎ͼ�Boss即�ؓMain Reactor�Q�NioWorker为Sub Reactor。Boss用来处理新连接加入的事�g�Q�NioWorker用来处理各个�q�接对Socket的读写事�Ӟ��其中Boss通过NioWorkerPool获取NioWorker实例�Q�Netty3模式使用RoundRobin方式攑֛�NioWorker实例。更形象一点的�Q�可以通过Scalable IO In Java的这张图表达�Q?br />
若与Ractor模式对应�Q�NioSelector中包含了Synchronous Event Demultiplexer�Q�而ChannelPipeline中管理着所有EventHandler�Q�因而NioSelector和ChannelPipeline共同构成了Initiation Dispatcher�?br />5. ChannelSink�Q?/strong>在ChannelHandler处理完成所有逻辑需要向客户端写响应数据�Ӟ��一般会调用Netty Channel中的write�Ҏ��Q�然而在�q�个write�Ҏ��实现中，它不是直接向其内部的Socket写数据，而是交给Channels帮助�c�，内部创徏DownstreamMessageEvent�Q�反向从ChannelPipeline的管道中��过去，直到�W�一个ChannelHandler处理完毕�Q�最后交�l�ChannelSink处理�Q�以避免��d��写而媄响程序的吞吐量。ChannelSink��这个MessageEvent提交�l�Netty Channel中的writeBufferQueue�Q�最后NioWorker会等到这个NIO Channel已经可以处理写事件时无阻塞的向这个NIO Channel写数据。这��是上图的send是从SubReactor直接出发的原因�?br />6. Channel�Q?/strong>Netty有自��q��Channel抽象�Q�它是一个资源的容器�Q�包含了所有一个连接涉及到的所有资源的饮用�Q�如��装NIO Channel、ChannelPipeline、Boss、NioWorkerPool�{�。另外它�q�提供了向内部NIO Channel写响应数据的接口write、连�?�l�定到某个地址的connect/bind接口�{�，个�h感觉虽然对Channel本��n来说�Q�因为它��装了NIO Channel�Q�因而这些接口定义在�q�里是合理的�Q�但是如果考虑到Netty的架构，它的Channel只是一个资源容器，有这个Channel实例��可以得到和它相关的基本所有资源，因而这�U�write、connect、bind动作不应该再由它负责�Q�而是应该由其他类来负责，比如在Netty4中就在ChannelHandlerContext��d��了write�Ҏ��Q�虽然netty4�q�没有删除Channel中的write接口�?br />
Netty3中的Intercepting Filter模式
如果说Reactor模式是Netty3的骨�Ӟ��那么Intercepting Filter模式则是Netty的中枢。Reactor模式主要应用在Netty3的内部实玎ͼ�它是Netty3��h��良好性能的基��Q�而Intercepting Filter模式则是ChannelHandler�l�合实现一个应用程序逻辑的基��Q�只有很好的理解了这个模式才能��用好Netty�Q�甚臌��得心应手�?br />
关于Intercepting Filter模式的详�l�介�l�可以参�?a href="http://www.tkk7.com/DLevin/archive/2015/09/03/427086.html">�q�里�Q�本节主要介�l�Netty3中对Intercepting Filter模式的实玎ͼ�其实��是DefaultChannelPipeline对Intercepting Filter模式的实现。在上文有提到Netty3的ChannelPipeline是ChannelHandler的容器，用于存储与管理ChannelHandler�Q�同时它在Netty3中也起到桥梁的作用，卛_��是连接Netty3内部到所有ChannelHandler的桥梁。作为ChannelPipeline的实现者DefaultChannelPipeline�Q�它使用一个ChannelHandler的双向链表来存储�Q�以DefaultChannelPipelineContext作�ؓ节点�Q?br />
public interface ChannelHandlerContext {
    Channel getChannel();
    ChannelPipeline getPipeline();
    String getName();
    ChannelHandler getHandler();
    boolean canHandleUpstream();
    boolean canHandleDownstream();
    void sendUpstream(ChannelEvent e);
    void sendDownstream(ChannelEvent e);
    Object getAttachment();
    void setAttachment(Object attachment);
}

private final class DefaultChannelHandlerContext implements ChannelHandlerContext {
    volatile DefaultChannelHandlerContext next;
    volatile DefaultChannelHandlerContext prev;
    private final String name;
    private final ChannelHandler handler;
    private final boolean canHandleUpstream;
    private final boolean canHandleDownstream;
    private volatile Object attachment;
.....
}
在DefaultChannelPipeline中，它存储了和当前ChannelPipeline相关联的Channel、ChannelSink以及ChannelHandler链表的head、tail�Q�所有ChannelEvent通过sendUpstream、sendDownstream为入口流�l�整个链表：
public class DefaultChannelPipeline implements ChannelPipeline {
    private volatile Channel channel;
    private volatile ChannelSink sink;
    private volatile DefaultChannelHandlerContext head;
    private volatile DefaultChannelHandlerContext tail;
......
    public void sendUpstream(ChannelEvent e) {
        DefaultChannelHandlerContext head = getActualUpstreamContext(this.head);
        if (head == null) {
            return;
        }
        sendUpstream(head, e);
    }

    void sendUpstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
        try {
            ((ChannelUpstreamHandler) ctx.getHandler()).handleUpstream(ctx, e);
        } catch (Throwable t) {
            notifyHandlerException(e, t);
        }
    }

    public void sendDownstream(ChannelEvent e) {
        DefaultChannelHandlerContext tail = getActualDownstreamContext(this.tail);
        if (tail == null) {
            try {
                getSink().eventSunk(this, e);
                return;
            } catch (Throwable t) {
                notifyHandlerException(e, t);
                return;
            }
        }
        sendDownstream(tail, e);
    }

    void sendDownstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
        if (e instanceof UpstreamMessageEvent) {
            throw new IllegalArgumentException("cannot send an upstream event to downstream");
        }
        try {
            ((ChannelDownstreamHandler) ctx.getHandler()).handleDownstream(ctx, e);
        } catch (Throwable t) {
            e.getFuture().setFailure(t);
            notifyHandlerException(e, t);
        }
    }
对Upstream事�g�Q�向后找到所有实��C��ChannelUpstreamHandler接口的ChannelHandler�l�成链（getActualUpstreamContext()�Q?/span>�Q�而对Downstream事�g�Q�向前找到所有实��C��ChannelDownstreamHandler接口的ChannelHandler�l�成链（getActualDownstreamContext()�Q�：
    private DefaultChannelHandlerContext getActualUpstreamContext(DefaultChannelHandlerContext ctx) {
        if (ctx == null) {
            return null;
        }
        DefaultChannelHandlerContext realCtx = ctx;
        while (!realCtx.canHandleUpstream()) {
            realCtx = realCtx.next;
            if (realCtx == null) {
                return null;
            }
        }
        return realCtx;
    }
    private DefaultChannelHandlerContext getActualDownstreamContext(DefaultChannelHandlerContext ctx) {
        if (ctx == null) {
            return null;
        }
        DefaultChannelHandlerContext realCtx = ctx;
        while (!realCtx.canHandleDownstream()) {
            realCtx = realCtx.prev;
            if (realCtx == null) {
                return null;
            }
        }
        return realCtx;
    }
在实际实现ChannelUpstreamHandler或ChannelDownstreamHandler�Ӟ��调用 ChannelHandlerContext中的sendUpstream或sendDownstream�Ҏ��控制流�E�交�l�下一�? ChannelUpstreamHandler或下一个ChannelDownstreamHandler�Q�或调用Channel中的write�Ҏ��发�? 响应消息�?br />
public class MyChannelUpstreamHandler implements ChannelUpstreamHandler {
    public void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
        // handle current logic, use Channel to write response if needed.
        // ctx.getChannel().write(message);
        ctx.sendUpstream(e);
    }
}

public class MyChannelDownstreamHandler implements ChannelDownstreamHandler {
    public void handleDownstream(
            ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
        // handle current logic
        ctx.sendDownstream(e);
    }
}
当ChannelHandler向ChannelPipelineContext发送事件时�Q�其内部从当前ChannelPipelineContext节点出发扑ֈ�下一个ChannelUpstreamHandler或ChannelDownstreamHandler实例�Q��ƈ向其发送ChannelEvent�Q�对于Downstream链，如果到达铑ְ��Q�则��ChannelEvent发送给ChannelSink�Q?br />
public void sendDownstream(ChannelEvent e) {
    DefaultChannelHandlerContext prev = getActualDownstreamContext(this.prev);
    if (prev == null) {
      try {
            getSink().eventSunk(DefaultChannelPipeline.this, e);
        } catch (Throwable t) {
            notifyHandlerException(e, t);
        }
    } else {
        DefaultChannelPipeline.this.sendDownstream(prev, e);
    }
}

public void sendUpstream(ChannelEvent e) {
    DefaultChannelHandlerContext next = getActualUpstreamContext(this.next);
    if (next != null) {
        DefaultChannelPipeline.this.sendUpstream(next, e);
    }
}
正是因�ؓ�q�个实现�Q�如果在一个末��ChannelUpstreamHandler中先�U�除自己�Q�在向末��添加一个新的ChannelUpstreamHandler�Q�它是无效的�Q�因为它的next已经在调用前��固定设�|��ؓnull了�?br />
ChannelPipeline作�ؓChannelHandler的容器，它还提供了各�U�增、删、改ChannelHandler链表中的�Ҏ��Q�而且如果某个ChannelHandler�q�实��C��LifeCycleAwareChannelHandler�Q�则该ChannelHandler在被��d��q�ChannelPipeline或从中删除时都会得到同志�Q?br />
public interface LifeCycleAwareChannelHandler extends ChannelHandler {
    void beforeAdd(ChannelHandlerContext ctx) throws Exception;
    void afterAdd(ChannelHandlerContext ctx) throws Exception;
    void beforeRemove(ChannelHandlerContext ctx) throws Exception;
    void afterRemove(ChannelHandlerContext ctx) throws Exception;
}

public interface ChannelPipeline {
    void addFirst(String name, ChannelHandler handler);
    void addLast(String name, ChannelHandler handler);
    void addBefore(String baseName, String name, ChannelHandler handler);
    void addAfter(String baseName, String name, ChannelHandler handler);
    void remove(ChannelHandler handler);
    ChannelHandler remove(String name);
    <T extends ChannelHandler> T remove(Class<T> handlerType);
    ChannelHandler removeFirst();
    ChannelHandler removeLast();
    void replace(ChannelHandler oldHandler, String newName, ChannelHandler newHandler);
    ChannelHandler replace(String oldName, String newName, ChannelHandler newHandler);
    <T extends ChannelHandler> T replace(Class<T> oldHandlerType, String newName, ChannelHandler newHandler);
    ChannelHandler getFirst();
    ChannelHandler getLast();
    ChannelHandler get(String name);
    <T extends ChannelHandler> T get(Class<T> handlerType);
    ChannelHandlerContext getContext(ChannelHandler handler);
    ChannelHandlerContext getContext(String name);
    ChannelHandlerContext getContext(Class extends ChannelHandler> handlerType);
    void sendUpstream(ChannelEvent e);
    void sendDownstream(ChannelEvent e);
    ChannelFuture execute(Runnable task);
    Channel getChannel();
    ChannelSink getSink();
    void attach(Channel channel, ChannelSink sink);
    boolean isAttached();
    List<String> getNames();
    Map<String, ChannelHandler> toMap();
}

在DefaultChannelPipeline的ChannelHandler链条的处理流�E��ؓ�Q?br />
参考：
《Netty主页�?/a>
《Netty源码解读�Q�四�Q�Netty与Reactor模式�?/a>
《Netty代码分析�?/a>
Scalable IO In Java
Intercepting Filter Pattern

DLevin 2015-09-04 09:40 发表评论

Intercepting Filter模式详解

DLevin — Thu, 03 Sep 2015 14:14:00 GMT

问题描述
在服务器�~�程中，通常需要处理多�U�不同的��h��Q�在正式处理��h��之前�Q�需要对��h��做一些预处理�Q�如�Q?br />
�U�录每个Client的每�ơ访问信息�?/li>
对Client�q�行认证和授权检查（Authentication and Authorization�Q��?/li>
��查当前Session是否合法�?/li>
��查Client的IP地址是否可信赖或不可信赖�Q�IP地址白名单、黑名单�Q��?/li>
��h��数据是否先要解压或解码�?/li>
是否支持Client��h��的类型、Browser版本�{��?/li>
��d��性能监控信息�?/li>
��d��调试信息�?/li>
保证所有异帔R��被正��捕获到�Q�对未预料到的异常做通用处理�Q�防止给Client看到内部堆栈信息�?br />
在响应返回给客户端之前，有时候也需要做一些预处理再返回：
对响应消息编码或压羃�?/li>
为所有响应添加公共头、尾�{�消息�?/li>
�q�一步Enrich响应消息�Q�如��d��公共字段、Session信息、Cookie信息�Q�甚臛_��全改变响应消息等�?/li>
如何实现�q�样的需求，同时保持可扩展性、可重用性、可配置、移植性？
问题解决
要实现这�U�需求，最直观的方法就是在每个��h��处理�q�程中添加所有这些逻辑�Q��ؓ了减��代码重复，可以��所有这些检查提取成�Ҏ��Q�这样在每个处理�Ҏ��中调用即可：
public Response service1(Request request) {
    validate(request);
    request = transform(request);
    Response response = process1(request);
    return transform(response);
}
此时�Q�如果出现service2�Ҏ��Q�依焉��要拷贝service1中的实现�Q�然后将process1换成process2卛_��。这个时候我们发现很多重复代码，�l�箋对它重构�Q�比如提取公共逻辑到基�c�L��模版�Ҏ��Q�这�U��用��承的方式会引起子�c�d��父类的耦合�Q�如果要让某些模块变的可配置需要有太多的判断逻辑�Q�代码变的臃肿；因而可以更�q�一步，��所有处理逻辑抽象��Z��个Processor接口�Q�然后��用Decorate模式�Q�即引用优于�l�承�Q�：
public interface Processor {
    Response process(Request request);
}
public class CoreProcessor implements Processor {
    public Response process(Request request) {
        // do process/calculation
    }
}
public class DecoratedProcessor implements Processor {
    private final Processor innerProcessor;
    public DecoratedProcessor(Processor processor) {
        this.innerProcessor = processor;
    }

    public Response process(Request request) {
        request = preProcess(request);
        Response response = innerProcessor.process(request);
        response = postProcess(response);
        return response;
    }

    protected Request preProcess(Request request) {
        return request;
    }
    protected Response postProcess(Response response) {
        return response;
    }
}

public void Transformer extends DecoratedProcessor {
    public Transformer(Processor processor) {
        super(processor);
    }

    protected Request preProcess(Request request) {
        return transformRequest(request);
    }
    protected Response postProcess(Response response) {
        return transformResponse(response);
    }
}
此时�Q�如果需要在真正的处理逻辑之前加入其他的预处理逻辑�Q�只需要��承DecoratedProcessor�Q�实现preProcess或postProcess�Ҏ��Q�分别在��h��处理之前和请求处理之后横向切入一些逻辑�Q�也��是所谓的AOP�~�程�Q�面向切面的�~�程�Q�然后只需要根据需求构��个链条：
Processor processor = new MissingExceptionCatcher(new Debugger(new Transformer(new CoreProcessor());
Response response = processor.process(request);
......
�q�已�l�是相对比较好的设计了，每个Processor只需要关注自��q��实现逻辑卛_��Q�代码变的简�z�；�q�且每个Processor各自独立�Q�可重用性好�Q�测试方便；整条链上能实现的功能只是取决于链的构造，因而只需要有一�U�方法配�|�链的构造即可，可配�|�性也变得灉|��Q�然而很多时候引用是一�U�静态的依赖�Q�而无法满��_��态的需求。要构造这条链�Q�每个前�|�Processor需要知道其后的Processor�Q�这在某些情况下�q�不是在起初��q��道的。此�Ӟ��我们需要引入Intercepting Filter模式来实现动态的改变条链�?br />
Intercepting Filter模式
在前文已�l�构��Z��一条由引用而成的Processor链，然而这是一条静态链�Q��ƈ且需要一开始就能构造出�q�条链，��Z��解决�q�个限制�Q�我们可以引入一个ProcessorChain来维护这条链�Q��ƈ且这条链可以动态的构徏�?br />
有多�U�方式可以实现�ƈ控制�q�个链：
在存储上�Q�可以��用数�l�来存储所有的Processor�Q�Processor在数�l�中的位�|�表�C��个Processor在链条中的位�|�；也可以用链表来存储所有的Processor�Q�此时Processor在这个链表中的位�|�即是在链中的位�|��?/li>
在抽象上�Q�可以所有的逻辑都封装在Processor中，也可以将核心逻辑使用Processor抽象�Q�而外围逻辑使用Filter抽象�?/li>
在流�E�控制上�Q�一般通过在Processor实现�Ҏ��中直接��用ProcessorChain实例(通过参数掺入)来控制流�E�，利用�Ҏ��调用的进栈出栈的�Ҏ��实现preProcess()和postProcess()处理�?/li>
在实际中使用�q�个模式的有�Q�Servlet的Filter机制、Netty的ChannelPipeline中、Structs2中的Interceptor中都实现了这个模式�?br />
Intercepting Filter模式在Servlet的Filter中的实现�Q�Jetty版本�Q?/h2>其中Servlet的Filter在Jetty的实��C��使用数组存储Filter�Q�Filter末尾可以使用Servlet实例处理真正的业务逻辑�Q�在��程控制上，使用FilterChain的doFilter�Ҏ��来实现。如FilterChain在Jetty中的实现�Q?br />
public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException
    // pass to next filter
    if (_filter < LazyList.size(_chain)) {
        FilterHolder holder= (FilterHolder)LazyList.get(_chain, _filter++);
        Filter filter= holder.getFilter();
        filter.doFilter(request, response, this);
        return;
    }

    // Call servlet
    HttpServletRequest srequest = (HttpServletRequest)request;
    if (_servletHolder != null) {
        _servletHolder.handle(_baseRequest,request, response);
    }
}
�q�里�Q�_chain实际上是一个Filter的ArrayList�Q�由FilterChain调用doFilter()启动调用�W�一个Filter的doFilter()�Ҏ��Q�在实际的Filter实现中，需要手动的调用FilterChain.doFilter()�Ҏ��来启动下一个Filter的调用，利用�Ҏ��调用的进栈出栈的�Ҏ��实现Request的pre-process和Response的post-process处理。如果不调用FilterChain.doFilter()�Ҏ��Q�则表示不需要调用之后的Filter�Q�流�E�从当前Filter�q�回�Q�在它之前的Filter的FilterChain.doFilter()调用之后的逻辑反向处理直到�W�一个Filter处理完成而返回�?br />
public class MyFilter implements Filter {
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // pre-process ServletRequest
        chain.doFilter(request, response);
        // post-process Servlet Response
    }
}
整个Filter铄��处理��程如下�Q?br />
Intercepting Filter模式在Netty3中的实现
Netty3在DefaultChannelPipeline中实��C��Intercepting Filter模式�Q�其中ChannelHandler是它的Filter。在Netty3的DefaultChannelPipeline中，使用一个以ChannelHandlerContext��点的双向链表来存储ChannelHandler�Q�所有的横切面逻辑和实际业务逻辑都用ChannelHandler表达�Q�在控制��程上��用ChannelHandlerContext的sendDownstream()和sendUpstream()�Ҏ��来控制流�E�。不同于Servlet的Filter�Q�ChannelHandler有两个子接口�Q�ChannelUpstreamHandler和ChannelDownstreamHandler分别用来��h��q�入时的处理��程和响应出��L��的处理流�E�。对于Client的请求，从DefaultChannelPipeline的sendUpstream()�Ҏ��入口�Q?br />
public void sendDownstream(ChannelEvent e) {
    DefaultChannelHandlerContext tail = getActualDownstreamContext(this.tail);
    if (tail == null) {
        try {
            getSink().eventSunk(this, e);
            return;
        } catch (Throwable t) {
            notifyHandlerException(e, t);
            return;
        }
    }
    sendDownstream(tail, e);
}
void sendDownstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
    if (e instanceof UpstreamMessageEvent) {
        throw new IllegalArgumentException("cannot send an upstream event to downstream");
    }
    try {
        ((ChannelDownstreamHandler) ctx.getHandler()).handleDownstream(ctx, e)
     } catch (Throwable t) {
        e.getFuture().setFailure(t);
        notifyHandlerException(e, t);
    }
}
如果有响应消息，该消息从DefaultChannelPipeline的sendDownstream()�Ҏ��为入口：
public void sendUpstream(ChannelEvent e) {
    DefaultChannelHandlerContext head = getActualUpstreamContext(this.head);
    if (head == null) {
        return;
    }
    sendUpstream(head, e);
}
void sendUpstream(DefaultChannelHandlerContext ctx, ChannelEvent e) {
    try {
        ((ChannelUpstreamHandler) ctx.getHandler()).handleUpstream(ctx, e);
    } catch (Throwable t) {
        notifyHandlerException(e, t);
    }
}
在实际实现ChannelUpstreamHandler或ChannelDownstreamHandler�Ӟ��调用ChannelHandlerContext中的sendUpstream或sendDownstream�Ҏ��控制流�E�交�l�下一个ChannelUpstreamHandler或下一个ChannelDownstreamHandler�Q�或调用Channel中的write�Ҏ��发送响应消息�?br />
public class MyChannelUpstreamHandler implements ChannelUpstreamHandler {
    public void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
        // handle current logic, use Channel to write response if needed.
        // ctx.getChannel().write(message);
        ctx.sendUpstream(e);
    }
}

public class MyChannelDownstreamHandler implements ChannelDownstreamHandler {
    public void handleDownstream(
            ChannelHandlerContext ctx, ChannelEvent e) throws Exception {
        // handle current logic
        ctx.sendDownstream(e);
    }
}
当ChannelHandler向ChannelPipelineContext发送事件时�Q�其内部从当前ChannelPipelineContext 节点出发扑ֈ�下一个ChannelUpstreamHandler或ChannelDownstreamHandler实例�Q��ƈ向其发�? ChannelEvent�Q�对于Downstream链，如果到达铑ְ��Q�则��ChannelEvent发送给ChannelSink�Q?br />
public void sendDownstream(ChannelEvent e) {
    DefaultChannelHandlerContext prev = getActualDownstreamContext(this.prev);
    if (prev == null) {
      try {
            getSink().eventSunk(DefaultChannelPipeline.this, e);
        } catch (Throwable t) {
            notifyHandlerException(e, t);
        }
    } else {
        DefaultChannelPipeline.this.sendDownstream(prev, e);
    }
}

public void sendUpstream(ChannelEvent e) {
    DefaultChannelHandlerContext next = getActualUpstreamContext(this.next);
    if (next != null) {
        DefaultChannelPipeline.this.sendUpstream(next, e);
    }
}
正是因�ؓ�q�个实现�Q�如果在一个末��ChannelUpstreamHandler中先�U�除自己�Q�在向末��添加一个新的ChannelUpstreamHandler�Q�它是无效的�Q�因为它的next已经在调用前��固定设�|��ؓnull了�?br />
在DefaultChannelPipeline的ChannelHandler链条的处理流�E��ؓ�Q?br />
在这个实��C��Q�不像Servlet的Filter实现利用�Ҏ��调用栈的�q�出栈来完成pre-process和post-process�Q�而是在进�ȝ��铑֒�出来的链各自调用handleUpstream()和handleDownstream()�Ҏ��Q�这样会引�v调用栈其实是两条铄��d��Q�因而需要注意这条链的总长度。这样做的好处是�q�条ChannelHandler的链不依赖于�Ҏ��调用栈，而是在DefaultChannelPipeline内部本��n的链�Q�因而在handleUpstream()或handleDownstream()可以随时��执行流�E��{发给其他�U�程或线�E�池�Q�只需要保留ChannelPipelineContext引用�Q�在处理完成后用�q�个ChannelPipelineContext重新向这条链的后一个节点发送ChannelEvent�Q�然而由于Servlet的Filter依赖于方法的调用栈，因而方法返回意味着所有执行完成，�q�种限制在异步编�E�中会引起问题，因而Servlet�?.0后引入了Async的支持�?br />
Intercepting Filter模式的缺�?/h2>��单提一下这个模式的�~�点�Q?br />1. 相对传统的编�E�模型，�q�个模式有一定的学习曲线�Q�需要很好的理解该模式后才能灉|��的应用它来编�E��?br />2. 需要划分不同的逻辑��C��同的Filter中，�q�有些时候�ƈ不是那么�Ҏ��?br />3. 各个Filter之间�׃�n数据��变得困难。在Netty3中可以自定义自己的ChannelEvent来实现自定义消息的传输，或者��用ChannelPipelineContext的Attachment字段来实现消息传输，而Servlet中的Filter则没有提供类似的机制�Q�如果不是可以配�|�的数据在Config中传递，其他时候的数据�׃�n需要其他机刉��合完成�?br />
参�?/h2>Core J2EE Pattern - Intercepting Filter

DLevin 2015-09-03 22:14 发表评论

Reactor模式详解

DLevin — Wed, 02 Sep 2015 07:14:00 GMT

前记
�W�一�ơ听到Reactor模式是三�q�前的某个晚上，一个室友突然跑�q�来问我什么是Reactor模式�Q�我上网查了一下，很多人都是给出NIO中的 Selector的例子，而且��是NIO里Selector多�\复用模型�Q�只是给它�v了一个比较fancy的名字而已�Q�虽然它引入了EventLoop�? 念，�q�对我来说是新的概念�Q�但是代码实现却是一��L��Q�因而我�q�没有很在意�q�个模式。然而最�q�开始读Netty源码�Q�而Reactor模式是很多介�l�Netty的文章中被大肆宣传的模式�Q�因而我再次问自己，什么是Reactor模式�Q�本文就是对�q�个问题关于我的一些理解和��试着来解�{��?br />

什么是Reactor模式
要回�{�这个问题，首先当然是求助Google或Wikipedia�Q�其中Wikipedia上说�Q?#8220;The reactor design pattern is an event handling pattern for handling service requests delivered concurrently by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to associated request handlers.”。从�q�个描述中，我们知道Reactor模式首先�?strong>事�g驱动的，有一个或多个�q�发输入源，有一个Service Handler�Q�有多个Request Handlers�Q�这个Service Handler会同步的��输入的��h��Q�Event�Q�多路复用的分发�l�相应的Request Handler。如果用图来表达�Q?br />
从结构上�Q�这有点�c�M��生��者消费者模式，��x��一个或多个生��者将事�g攑օ�一个Queue中，而一个或多个消费者主动的从这个Queue中Poll事�g来处理；而Reactor模式则�ƈ没有Queue来做�~�冲�Q�每当一个Event输入到Service Handler之后�Q�该Service Handler会主动的�Ҏ��不同的Event�c�d��其分发�l�对应的Request Handler来处理�?br />
更学术的�Q�这��文章（Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events�Q�上��_��“The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. Each service in an application may consistent of several methods and is represented by a separate event handler that is responsible for dispatching service-specific requests. Dispatching of event handlers is performed by an initiation dispatcher, which manages the registered event handlers. Demultiplexing of service requests is performed by a synchronous event demultiplexer. Also known as Dispatcher, Notifier”。这�D�|��q�和Wikipedia上的描述�c�M��Q�有多个输入源，有多个不同的EventHandler�Q�RequestHandler�Q�来处理不同的请求，Initiation Dispatcher用于��理EventHander�Q�EventHandler首先要注册到Initiation Dispatcher中，然后Initiation Dispatcher�Ҏ��输入的Event分发�l�注册的EventHandler�Q�然而Initiation Dispatcher�q�不监听Event的到来，�q�个工作交给Synchronous Event Demultiplexer来处理�?br />
Reactor模式�l�构
在解决了什么是Reactor模式后，我们来看看Reactor模式是由什么模块构成。图是一�U�比较简�z��Ş象的表现方式�Q�因而先上一张图来表辑֐�个模块的名称和他们之间的关系�Q?br />
Handle�Q?/strong>��x��作系�l�中的句柄，是对资源在操作系�l�层面上的一�U�抽象，它可以是打开的文件、一个连�?Socket)、Timer�{�。由于Reactor模式一般��用在�|�络�~�程中，因而这里一般指Socket Handle�Q�即一个网�l�连接（Connection�Q�在Java NIO中的Channel�Q�。这个Channel注册到Synchronous Event Demultiplexer中，以监听Handle中发生的事�g�Q�对ServerSocketChannnel可以是CONNECT事�g�Q�对SocketChannel可以是READ、WRITE、CLOSE事�g�{��?br />Synchronous Event Demultiplexer�Q?/strong>��d��{�待一�p�d��的Handle中的事�g到来�Q�如果阻塞等待返回，卌��C�在�q�回的Handle中可以不��d��的执行返回的事�g�c�d��。这个模块一般��用操作系�l�的select来实现。在Java NIO中用Selector来封装，当Selector.select()�q�回�Ӟ��可以调用Selector的selectedKeys()�Ҏ��获取Set�Q�一个SelectionKey表达一个有事�g发生的Channel以及该Channel上的事�g�c�d��。上囄��“Synchronous Event Demultiplexer ---notifies--> Handle”的流�E�如果是对的�Q�那内部实现应该是select()�Ҏ��在事件到来后会先讄��Handle的状态，然后�q�回。不了解内部实现机制�Q�因而保留原图�?br />Initiation Dispatcher�Q?/strong>用于��理Event Handler�Q�即EventHandler的容器，用以注册、移除EventHandler�{�；另外�Q�它�q�作为Reactor模式的入口调用Synchronous Event Demultiplexer的select�Ҏ��以阻塞等待事件返回，当阻塞等待返回时�Q�根据事件发生的Handle��其分发�l�对应的Event Handler处理�Q�即回调EventHandler中的handle_event()�Ҏ��?br />Event Handler�Q?/strong>定义事�g处理�Ҏ��Q�handle_event()�Q�以供InitiationDispatcher回调使用�?br />Concrete Event Handler�Q?/strong>事�gEventHandler接口�Q�实现特定事件处理逻辑�?br />
Reactor模式模块之间的交�?/h2> ��单描�q�C��下Reactor各个模块之间的交互流�E�，先从序列囑ּ�始：

1. 初始化InitiationDispatcher�Q��ƈ初始化一个Handle到EventHandler的Map�?br />2. 注册EventHandler到InitiationDispatcher中，每个EventHandler包含对相应Handle的引用，从而徏立Handle到EventHandler的映��（Map�Q��?br />3. 调用InitiationDispatcher的handle_events()�Ҏ��以启动Event Loop。在Event Loop中，调用select()�Ҏ��Q�Synchronous Event Demultiplexer�Q�阻塞等待Event发生�?br />4. 当某个或某些Handle的Event发生后，select()�Ҏ��q�回�Q�InitiationDispatcher�Ҏ��q�回的Handle扑ֈ�注册的EventHandler�Q��ƈ回调该EventHandler的handle_events()�Ҏ��?br />5. 在EventHandler的handle_events()�Ҏ��中还可以向InitiationDispatcher中注册新的Eventhandler�Q�比如对AcceptorEventHandler来，当有新的client�q�接�Ӟ��它会产生新的EventHandler以处理新的连接，�q�注册到InitiationDispatcher中�?br />
Reactor模式实现
�?a >Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events中，一直以Logging Server来分析Reactor模式�Q�这个Logging Server的实现完全遵循这里对Reactor描述�Q�因而放在这里以做参考。Logging Server中的Reactor模式实现分两个部分：Client�q�接到Logging Server和Client向Logging Server写Log。因而对它的描述分成�q�两个步骤�?br />Client�q�接到Logging Server

1. Logging Server注册LoggingAcceptor到InitiationDispatcher�?br />2. Logging Server调用InitiationDispatcher的handle_events()�Ҏ��启动�?br />3. InitiationDispatcher内部调用select()�Ҏ��Q�Synchronous Event Demultiplexer�Q�，��d��{�待Client�q�接�?br />4. Client�q�接到Logging Server�?br />5. InitiationDisptcher中的select()�Ҏ��q�回�Q��ƈ通知LoggingAcceptor有新的连接到来�?
6. LoggingAcceptor调用accept�Ҏ��accept�q�个新连接�?br />7. LoggingAcceptor创徏新的LoggingHandler�?br />8. 新的LoggingHandler注册到InitiationDispatcher�?同时也注册到Synchonous Event Demultiplexer�?�Q�等待Client发�v写log��h��?br />Client向Logging Server写Log

1. Client发送log到Logging server�?br />2. InitiationDispatcher监测到相应的Handle中有事�g发生�Q�返回阻塞等待，�Ҏ��q�回的Handle扑ֈ�LoggingHandler�Q��ƈ回调LoggingHandler中的handle_event()�Ҏ��?br />3. LoggingHandler中的handle_event()�Ҏ��中读取Handle中的log信息�?br />4. ��接收到的log写入到日志文件、数据库�{�设备中�?br />3.4步骤循环直到当前日志处理完成�?br />5. �q�回到InitiationDispatcher�{�待下一�ơ日志写��h��?br />
�?a >Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events有对Reactor模式的C++的实现版本，多年不用C++�Q�因而略�q��?nbsp;
Java NIO对Reactor的实�?/h2>在Java的NIO中，对Reactor模式有无�~�的支持�Q�即使用Selector�c�d��装了操作�pȝ��提供的Synchronous Event Demultiplexer功能。这个Doug Lea已经�?a >Scalable IO In Java中有非常深入的解释了�Q�因而不再赘�q�ͼ�另外�q�篇文章对Doug Lea�?a >Scalable IO In Java有一些简单解释，臛_��它的代码格式比Doug Lea的PPT要整�z�一些�?br />
需要指出的是，不同�q�里使用InitiationDispatcher来管理EventHandler�Q�在Doug Lea的版本中使用SelectionKey中的Attachment来存储对应的EventHandler�Q�因而不需要注册EventHandler�q�个步骤�Q�或者设�|�Attachment��是�q�里的注册。而且在这��文章中�Q�Doug Lea从单�U�程的Reactor、Acceptor、Handler实现�q�个模式出发�Q�演化�ؓ��Handler中的处理逻辑多线�E�化�Q�实现类似Proactor模式�Q�此时所有的IO操作�q�是单线�E�的�Q�因而再演化��Z��个Main Reactor来处理CONNECT事�g(Acceptor)�Q�而多个Sub Reactor来处理READ、WRITE�{�事�?Handler)�Q�这些Sub Reactor可以分别再自��q��U�程中执行，从而IO操作也多�U�程化。这个最后一个模型正是Netty中��用的模型。�ƈ且在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events�?.5 Determine the Number of Initiation Dispatchers in an Application中也有相应的描述�?br />
EventHandler接口定义
对EventHandler的定义有两种设计思�\�Q�single-method设计和multi-method设计�Q?br />A single-method interface�Q?/strong>它将Event��装成一个Event Object�Q�EventHandler只定义一个handle_event(Event event)�Ҏ��。这�U�设计的好处是有利于扩展�Q�可以后来方便的��d��新的Event�c�d��Q�然而在子类的实��C��Q�需要判断不同的Event�c�d��而再�ơ扩展成不同的处理方法，从这个角度上来说�Q�它又不利于扩展。另外在Netty3的��用过�E�中�Q�由于它不停的创建ChannelEvent�c�，因而会引�vGC的不�E�_��?br />A multi-method interface�Q?/strong>�q�种设计是将不同的Event�c�d��? EventHandler中定义相应的�Ҏ��。这�U�设计就是Netty4中��用的�{�略�Q�其中一个目的是避免ChannelEvent创徏引�v的GC不稳定，另外一个好处是它可以避免在EventHandler实现时判断不同的Event�c�d��而有不同的实玎ͼ�然而这�U�设计会�l�扩展新的Event�c�d��时带来非�? 大的�ȝ��Q�因为它需要该接口�?br />
关于Netty4对Netty3的改�q�可以参�?a >�q�里�Q?br />
ChannelHandler with no event objectIn 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:
��Z��么��用Reactor模式
归功与Netty和Java NIO对Reactor的宣传，本文慕名而学习的Reactor模式�Q�因而已�l�默认Reactor��h��非常优秀的性能�Q�然而慕名归慕名�Q�到�q�里�Q�我�q�是要不得不问自己Reactor模式的好处在哪里�Q�即��Z��么要使用�q�个Reactor模式�Q�在Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events中是�q�么说的�Q?br />
Reactor Pattern优点

Separation of concerns: The Reactor pattern decouples application-independent demultiplexing and dispatching mechanisms from application-specific hook method functionality. The application-independent mechanisms become reusable components that know how to demultiplex events and dispatch the appropriate hook methods defined by Event Handlers. In contrast, the application-specific functionality in a hook method knows how to perform a particular type of service.

Improve modularity, reusability, and configurability of event-driven applications: The pattern decouples application functionality into separate classes. For instance, there are two separate classes in the logging server: one for establishing connections and another for receiving and processing logging records. This decoupling enables the reuse of the connection establishment class for different types of connection-oriented services (such as file transfer, remote login, and video-on-demand). Therefore, modifying or extending the functionality of the logging server only affects the implementation of the logging handler class.

Improves application portability: The Initiation Dispatcher’s interface can be reused independently of the OS system calls that perform event demultiplexing. These system calls detect and report the occurrence of one or more events that may occur simultaneously on multiple sources of events. Common sources of events may in- clude I/O handles, timers, and synchronization objects. On UNIX platforms, the event demultiplexing system calls are called select and poll [1]. In the Win32 API [16], the WaitForMultipleObjects system call performs event demultiplexing.

Provides coarse-grained concurrency control: The Reactor pattern serializes the invocation of event handlers at the level of event demultiplexing and dispatching within a process or thread. Serialization at the Initiation Dispatcher level often eliminates the need for more complicated synchronization or locking within an application process.

�q�些貌似是很多模式的共性：解耦、提升复用性、模块化、可�U�L��性、事仉��动、细力度的�ƈ发控制等�Q�因而�ƈ不能很好的说明什么，特别是它鼓吹的对性能的提升，�q�里�q�没有体现出来。当然在�q�篇文章的开头有描述�q�另一�U�直观的实现�Q�Thread-Per-Connection�Q�即传统的实玎ͼ�提到了这个传�l�实现的以下问题�Q?br />
Thread Per Connection�~�点

Efficiency: Threading may lead to poor performance due to context switching, synchronization, and data movement [2];

Programming simplicity: Threading may require complex concurrency control schemes;

Portability: Threading is not available on all OS platforms.
对于性能�Q�它其实��是�W�一点关于Efficiency的描�q�ͼ�即线�E�的切换、同步、数据的�U�d��会引��h��能问题。也��是说从性能的角度上�Q�它最大的提升��是减少了性能的��用，即不需要每个Client对应一个线�E�。我的理解，其他业务逻辑处理很多时候也会用到相同的�U�程�Q�IO��d��操作相对CPU的操作还是要慢很多，即��Reactor机制中每�ơ读写已�l�能保证非阻塞读写，�q�里可以减少一些线�E�的使用�Q�但是这减少的线�E��用对性能有那么大的媄响吗�Q�答案貌似是肯定的，�q�篇论文(SEDA: Staged Event-Driven Architecture - An Architecture for Well-Conditioned, Scalable Internet Service)寚w��着�U�程的增长带来性能降低做了一个统计：

在这个统计中�Q�每个线�E�从��盘中读8KB数据�Q�每个线�E�读同一个文�Ӟ��因而数据本�w�是�~�存在操作系�l�内部的�Q�即减少IO的媄响；所有线�E�是事先分配的，不会有线�E�启动的影响�Q�所有�Q务在��试内部产生�Q�因而不会有�|�络的媄响。该�l�计数据�q�行环境�Q�Linux 2.2.14�Q?GB内存�Q?-way 500MHz Pentium III。从图中可以看出�Q�随着�U�程的增长，吞吐量在�U�程��Cؓ8个左右的时候开始线性下降，�q�且�?4个以后而迅速下降，其相应事件也在线�E�达�?56个后指数上升。即1+1<2�Q�因为线�E�切换、同步、数据移动会有性能损失�Q�线�E�数增加��C��定数量时�Q�这�U�性能影响效果会更加明显�?br />
对于�q�点�Q�还可以参�?a >C10K Problem�Q�用以描�q�同时有10K个Client发�v�q�接的问题，�?010�q�的时候已�l�出�?0M Problem了�?br />
当然也有��Q?a >Threads are expensive are no longer valid.在不久的��来可能又会发生不同的变化，或者这个变化正在、已�l�发生着�Q�没有做�q�比较仔�l�的��试�Q�因而不敢随便断�a�什么，然而本��点，即�ɾU�程变的影响�q�没有以前那么大�Q��用Reactor模式�Q�甚��x��SEDA模式来减��线�E�的使用�Q�再加上其他解耦、模块化、提升复用性等优点�Q�还是值得使用的�?br />
Reactor模式的缺�?/h2>Reactor模式的缺点貌��g��是显而易见的�Q?br />1. 相比传统的简单模型，Reactor增加了一定的复杂性，因而有一定的门槛�Q��ƈ且不易于调试�?br />2. Reactor模式需要底层的Synchronous Event Demultiplexer支持�Q�比如Java中的Selector支持�Q�操作系�l�的select�pȝ��调用支持�Q�如果要自己实现Synchronous Event Demultiplexer可能不会有那么高效�?br />3. Reactor模式在IO��d��数据时还是在同一个线�E�中实现的，即��使用多个Reactor机制的情况下�Q�那些共享一个Reactor的Channel如果出现一个长旉��的数据读写，会媄响这个Reactor中其他Channel的相应时��_��比如在大文�g传输�Ӟ��IO操作��׃��影响其他Client的相应时��_��因而对�q�种操作�Q��用传�l�的Thread-Per-Connection或许是一个更好的选择�Q�或则此时��用Proactor模式�?br />
参�?/h2> Reactor Pattern WikiPedia
Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events
Scalable IO In Java
C10K Problem WikiPedia

DLevin 2015-09-02 15:14 发表评论

DLevin — Sat, 22 Aug 2015 11:40:00 GMT

前言
�q�是《深入HBase架构解析�Q�一�Q��?/a>的箋�Q�不多废话，�l�箋。。。�?br />
HBase�ȝ��实现
通过前文的描�q�ͼ�我们知道在HBase写时�Q�相同Cell(RowKey/ColumnFamily/Column相同)�q�不保证在一��P��甚至删除一个Cell也只是写入一个新的Cell�Q�它含有Delete标记�Q�而不一定将一个Cell真正删除了，因而这��引起了一个问题，如何实现�ȝ��问题�Q�要解决�q�个问题�Q�我们先来分析一下相同的Cell可能存在的位�|�：首先�Ҏ��写入的Cell�Q�它会存在于MemStore中；然后对之前已�l�Flush到HDFS中的Cell�Q�它会存在于某个或某些StoreFile(HFile)中；最后，对刚��d��q�的Cell�Q�它可能存在于BlockCache中。既然相同的Cell可能存储在三个地方，在读取的时候只需要扫瞄这三个地方�Q�然后将�l�果合�ƈ卛_��(Merge Read)�Q�在HBase中扫瞄的��序依次是：BlockCache、MemStore、StoreFile(HFile)。其中StoreFile的扫瞄先会��用Bloom Filter�q��o那些不可能符合条件的HFile�Q�然后��用Block Index快速定位Cell�Q��ƈ��其加蝲到BlockCache中，然后从BlockCache中读取。我们知道一个HStore可能存在多个StoreFile(HFile)�Q�此旉��要扫瞄多个HFile�Q�如果HFile�q�多又是会引��h��能问题�?br />
Compaction
MemStore每次Flush会创建新的HFile�Q�而过多的HFile会引赯��的性能问题�Q�那么如何解册��个问题呢�Q�HBase采用Compaction机制来解册��个问题，有点�c�M��Java中的GC机制�Q��v初Java不停的申请内存而不释放�Q�增加性能�Q�然而天下没有免费的午餐�Q�最�l�我们还是要在某个条件下��L��集垃圾，很多时候需要Stop-The-World�Q�这�U�Stop-The-World有些时候也会引起很大的问题�Q�比如参考本人写�?a href="http://www.tkk7.com/DLevin/archive/2015/08/01/426418.html">�q�篇文章�Q�因而设计是一�U�权衡，没有完美的。还是类似Java中的GC�Q�在HBase中Compaction分�ؓ两种�Q�Minor Compaction和Major Compaction�?br />
Minor Compaction是指选取一些小的、相�ȝ��StoreFile��他们合�q�成一个更大的StoreFile�Q�在�q�个�q�程中不会处理已�l�Deleted或Expired的Cell。一�ơMinor Compaction的结果是更少�q�且更大的StoreFile。（�q�个是对的吗�Q�BigTable中是�q�样描述Minor Compaction�?span style="font-size: 10.000000pt; font-family: 'Times'">�Q�As write operations execute, the size of the memtable in- creases. When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS. This minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. Incom- ing read and write operations can continue while com- pactions occur. 也就是说它将memtable的数据flush的一个HFile/SSTable�U�Cؓ一�ơMinor Compaction�Q?/li>
Major Compaction是指��所有的StoreFile合�ƈ成一个StoreFile�Q�在�q�个�q�程中，标记为Deleted的Cell会被删除�Q�而那些已�l�Expired的Cell会被丢弃�Q�那些已�l�超�q�最多版本数的Cell会被丢弃。一�ơMajor Compaction的结果是一个HStore只有一个StoreFile存在。Major Compaction可以手动或自动触发，然而由于它会引起很多的IO操作而引��h��能问题�Q�因而它一般会被安排在周末、凌晨等集群比较闲的旉��?br />
更�Ş象一点，如下面两张图分别表示Minor Compaction和Major Compaction�?br />
HRegion Split
最初，一个Table只有一个HRegion�Q�随着数据写入增加�Q�如果一个HRegion到达一定的大小�Q�就需要Split成两个HRegion�Q�这个大��由hbase.hregion.max.filesize指定�Q�默认�ؓ10GB。当split�Ӟ��两个新的HRegion会在同一个HRegionServer中创建，它们各自包含父HRegion一半的数据�Q�当Split完成后，父HRegion会下�U�，而新的两个子HRegion会向HMaster注册上线�Q�处于负载均衡的考虑�Q�这两个新的HRegion可能会被HMaster分配到其他的HRegionServer中。关于Split的详�l�信息，可以参考这��文章：《Apache HBase Region Splitting and Merging�?/a>�?br />
HRegion负蝲均衡
在HRegion Split后，两个新的HRegion最初会和之前的父HRegion在相同的HRegionServer上，��Z��负蝲均衡的考虑�Q�HMaster可能会将其中的一个甚至两个重新分配的其他的HRegionServer中，此时会引��h��些HRegionServer处理的数据在其他节点上，直到下一�ơMajor Compaction��数据从�q�端的节点移动到本地节点�?br />

HRegionServer Recovery
当一台HRegionServer宕机�Ӟ��׃��它不再发送Heartbeat�l�ZooKeeper而被监测刎ͼ�此时ZooKeeper会通知HMaster�Q�HMaster会检��到哪台HRegionServer宕机�Q�它��宕机的HRegionServer中的HRegion重新分配�l�其他的HRegionServer�Q�同时HMaster会把宕机的HRegionServer相关的WAL拆分分配�l�相应的HRegionServer(��拆分出的WAL文�g写入对应的目的HRegionServer的WAL目录中，�q��ƈ写入对应的DataNode中）�Q�从而这些HRegionServer可以Replay分到的WAL来重建MemStore�?br />

HBase架构��单�ȝ��
在NoSQL中，存在著名的CAP理论�Q�即Consistency、Availability、Partition Tolerance不可全得�Q�目前市��Z��基本上的NoSQL都采用Partition Tolerance以实现数据得水��^扩展�Q�来处理Relational DataBase遇到的无法处理数据量太大的问题，或引��L��性能问题。因而只有剩下C和A可以选择。HBase在两者之间选择了Consistency�Q�然后��用多个HMaster以及支持HRegionServer的failure监控、ZooKeeper引入作�ؓ协调者等各种手段来解决Availability问题�Q�然而当�|�络的Split-Brain(Network Partition)发生�Ӟ��它还是无法完全解决Availability的问题。从�q�个角度上，Cassandra选择了A�Q�即它在�|�络Split-Brain时还是能正常写，而��用其他技术来解决Consistency的问题，如读的时候触发Consistency判断和处理。这是设计上的限制�?br />
从实��C��的优点：
HBase采用��Z��致性模型，在一个写�q�回后，保证所有的读都��d��相同的数据�?/li>
通过HRegion动态Split和Merge实现自动扩展�Q��ƈ使用HDFS提供的多个数据备份功能，实现高可用性�?/li>
采用HRegionServer和DataNode�q�行在相同的服务器上实现数据的本地化�Q�提升读写性能�Q��ƈ减少�|�络压力�?/li>
内徏HRegionServer的宕��动恢复。采用WAL来Replay�q�未持久化到HDFS的数据�?/li>
可以无缝的和Hadoop/MapReduce集成�?br />
实现上的�~�点�Q?br />
WAL的Replay�q�程可能会很慢�?/li>
��N��恢复比较复杂�Q�也会比较慢�?/li>
Major Compaction会引起IO Storm�?/li>
。。。�?br />
参考：
https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx
http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable
http://hbase.apache.org/book.html
http://www.searchtb.com/2011/01/understanding-hbase.html
http://research.google.com/archive/bigtable-osdi06.pdf

DLevin 2015-08-22 19:40 发表评论

DLevin — Sat, 22 Aug 2015 09:44:00 GMT

前记
公司内部使用的是MapR版本的Hadoop生态系�l�，因而从MapR的官�|�看��C��q�篇文文章：An In-Depth Look at the HBase Architecture�Q�原本想��译全文�Q�然而如果翻译就需要各�U�咬文嚼字，太麻烦，因而本文大部分使用了自��q��语言�Q��ƈ且加入了其他资源的参考理解以及本��p��源码时对其的理解�Q�属于半��译、半原创吧�?br />
HBase架构�l�成
HBase采用Master/Slave架构搭徏集群�Q�它隶属于Hadoop生态系�l�，�׃��下类型节点组成：HMaster节点、HRegionServer节点、ZooKeeper集群�Q�而在底层�Q�它��数据存储于HDFS中，因而涉及到HDFS的NameNode、DataNode�{�，��M��l�构如下�Q?br />
其中HMaster节点用于�Q?br />

��理HRegionServer�Q�实现其负蝲均衡�?/li>
��理和分配HRegion�Q�比如在HRegion split时分配新的HRegion�Q�在HRegionServer退出时�q�移其内的HRegion到其他HRegionServer上�?/li>
实现DDL操作�Q�Data Definition Language�Q�namespace和table的增删改�Q�column familiy的增删改�{�）�?/li>
��理namespace和table的元数据�Q�实际存储在HDFS上）�?/li>
权限控制�Q�ACL�Q��?/li>
HRegionServer节点用于�Q?br />

存放和管理本地HRegion�?/li>
��d��HDFS�Q�管理Table中的数据�?/li>
Client直接通过HRegionServer��d��数据�Q�从HMaster中获取元数据�Q�找到RowKey所在的HRegion/HRegionServer后）�?/li>
ZooKeeper集群是协调系�l?/strong>�Q�用于：

存放整个 HBase集群的元数据以及集群的状态信息�?/li>
实现HMaster��M��节点的failover�?/li>
HBase Client通过RPC方式和HMaster、HRegionServer通信�Q�一个HRegionServer可以存放1000个HRegion�Q�底层Table数据存储于HDFS中，而HRegion所处理的数据尽量和数据所在的DataNode在一��P��实现数据的本地化�Q�数据本地化�q�不是总能实现�Q�比如在HRegion�U�d��(如因Split)�Ӟ��需要等下一�ơCompact才能�l�箋回到本地化�?br />
本着半翻译的原则�Q�再贴一个《An In-Depth Look At The HBase Architecture》的架构图：

�q�个架构图比较清晰的表达了HMaster和NameNode都支持多个热备䆾�Q��用ZooKeeper来做协调�Q�ZooKeeper�q�不是云般神�U�，它一般由三台机器�l�成一个集��，内部使用PAXOS��法支持三台Server中的一台宕机，也有使用五台机器的，此时则可以支持同时两台宕机，既少于半数的宕机�Q�然而随着机器的增加，它的性能也会下降�Q�RegionServer和DataNode一般会攑֜�相同的Server上实现数据的本地化�?br />
HRegion
HBase使用RowKey��表水��^切割成多个HRegion�Q�从HMaster的角度，每个HRegion都纪录了它的StartKey和EndKey�Q�第一个HRegion的StartKey为空�Q�最后一个HRegion的EndKey为空�Q�，�׃��RowKey是排序的�Q�因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。HRegion由HMaster分配到相应的HRegionServer中，然后由HRegionServer负责HRegion的启动和��理�Q�和Client的通信�Q�负责数据的�?使用HDFS)。每个HRegionServer可以同时��理1000个左右的HRegion�Q�这个数字怎么来的�Q�没有从代码中看到限�Ӟ��N��是出于经验？��过1000个会引�v性能问题�Q?strong>来回�{�这个问�?/strong>�Q�感觉这�?000的数字是从BigTable的论文中来的�Q? Implementation节）�Q�Each tablet server manages a set of tablets(typically we have somewhere between ten to a thousand tablets per tablet server)�Q��?br />

HMaster
HMaster没有单点故障问题�Q�可以启动多个HMaster�Q�通过ZooKeeper的Master Election机制保证同时只有一个HMaster��Z��Active状态，其他的HMaster则处于热备䆾状态。一般情况下会启动两个HMaster�Q�非Active的HMaster会定期的和Active HMaster通信以获取其最新状态，从而保证它是实时更新的�Q�因而如果启动了多个HMaster反而增加了Active HMaster的负担。前文已�l�介�l�过了HMaster的主要用于HRegion的分配和��理�Q�DDL(Data Definition Language�Q�既Table的新建、删除、修改等)的实现等�Q�既它主要有两方面的职责�Q?br />

协调HRegionServer

启动时HRegion的分配，以及负蝲均衡和修复时HRegion的重新分配�?/li>
监控集群中所有HRegionServer的状�?通过Heartbeat和监听ZooKeeper中的状�?�?br />

Admin职能

创徏、删除、修改Table的定义�?br />

ZooKeeper�Q�协调�?/h2> ZooKeeper为HBase集群提供协调服务�Q�它��理着HMaster和HRegionServer的状�?available/alive�{?�Q��ƈ且会在它们宕机时通知�l�HMaster�Q�从而HMaster可以实现HMaster之间的failover�Q�或对宕机的HRegionServer中的HRegion集合的修�?��它们分配给其他的HRegionServer)。ZooKeeper集群本��n使用一致性协�?PAXOS协议)保证每个节点状态的一致性�?br />

How The Components Work Together
ZooKeeper协调集群所有节点的�׃�n信息�Q�在HMaster和HRegionServer�q�接到ZooKeeper后创建Ephemeral节点�Q��ƈ使用Heartbeat机制�l�持�q�个节点的存�zȝ��态，如果某个Ephemeral节点实效�Q�则HMaster会收到通知�Q��ƈ做相应的处理�?br />
另外�Q�HMaster通过监听ZooKeeper中的Ephemeral节点(默认�Q?hbase/rs/*)来监控HRegionServer的加入和宕机。在�W�一个HMaster�q�接到ZooKeeper时会创徏Ephemeral节点(默认�Q?hbasae/master)来表�C�Active的HMaster�Q�其后加�q�来的HMaster则监听该Ephemeral节点�Q�如果当前Active的HMaster宕机�Q�则该节�Ҏ��失，因而其他HMaster得到通知�Q�而将自��n转换成Active的HMaster�Q�在变�ؓActive的HMaster之前�Q�它会创建在/hbase/back-masters/下创��q��Ephemeral节点�?br />
HBase的第一�ơ读�?/h3> 在HBase 0.96以前�Q�HBase有两个特�D�的Table�Q?ROOT-�?META.�Q�如BigTable中的设计�Q�，其中-ROOT- Table的位�|�存储在ZooKeeper�Q�它存储�?META. Table的RegionInfo信息�Q��ƈ且它只能存在一个HRegion�Q��?META. Table则存储了用户Table的RegionInfo信息�Q�它可以被切分成多个HRegion�Q�因而对�W�一�ơ访问用户Table�Ӟ��首先从ZooKeeper中读�?ROOT- Table所在HRegionServer�Q�然后从该HRegionServer中根据请求的TableName�Q�RowKey��d��.META. Table所在HRegionServer�Q�最后从该HRegionServer中读�?META. Table的内容而获取此�ơ请求需要访问的HRegion所在的位置�Q�然后访问该HRegionSever获取��h��的数据，�q�需要三�ơ请求才能找到用户Table所在的位置�Q�然后第四次��h��开始获取真正的数据。当然�ؓ了提升性能�Q�客��L��会缓�?ROOT- Table位置以及-ROOT-/.META. Table的内宏V��如下图所�C�：

可是即��客户端有�~�存�Q�在初始阶段需要三�ơ请求才能直到用户Table真正所在的位置也是性能低下的，而且真的有必要支持那么多的HRegion吗？或许对Google�q�样的公司来说是需要的�Q�但是对一般的集群来说好像�q�没有这个必要。在BigTable的论文中��_��每行METADATA存储1KB左右数据�Q�中�{�大��的Tablet(HRegion)�?28MB左右�Q?层位�|�的Schema设计可以支持2^34个Tablet(HRegion)。即使去�?ROOT- Table�Q�也�q�可以支�?^17(131072)个HRegion�Q?如果每个HRegion�q�是128MB�Q�那��是16TB�Q�这个貌��g��够大�Q�但是现在的HRegion的最大大��都会设�|�的比较大，比如我们讄��?GB�Q�此时支持的大小则变成了4PB�Q�对一般的集群来说已经够了�Q�因而在HBase 0.96以后��L��?ROOT- Table�Q�只剩下�q�个�Ҏ��的目录表叫做Meta Table(hbase:meta)�Q�它存储了集��中所有用户HRegion的位�|�信息，而ZooKeeper的节点中(/hbase/meta-region-server)存储的则直接是这个Meta Table的位�|�，�q�且�q�个Meta Table如以前的-ROOT- Table一��h��不可split的。这��P��客户端在�W�一�ơ访问用户Table的流�E�就变成了：

从ZooKeeper(/hbase/meta-region-server)中获取hbase:meta的位�|�（HRegionServer的位�|�）�Q�缓存该位置信息�?/li>
从HRegionServer中查询用户Table对应��h��的RowKey所在的HRegionServer�Q�缓存该位置信息�?/li>
从查询到HRegionServer中读取Row�?/li>
从这个过�E�中�Q�我们发现客户会�~�存�q�些位置信息�Q�然而第二步它只是缓存当前RowKey对应的HRegion的位�|�，因而如果下一个要查的RowKey不在同一个HRegion中，则需要��l�查询hbase:meta所在的HRegion�Q�然而随着旉��的推�U�，客户端缓存的位置信息��来��多�Q�以至于不需要再�ơ查找hbase:meta Table的信息，除非某个HRegion因�ؓ宕机或Split被移动，此时需要重新查询�ƈ且更新缓存�?br />

hbase:meta�?/h3> hbase:meta表存储了所有用户HRegion的位�|�信息，它的RowKey是：tableName,regionStartKey,regionId,replicaId�{�，它只有info列族�Q�这个列族包含三个列�Q�他们分别是�Q�info:regioninfo列是RegionInfo的proto格式�Q�regionId,tableName,startKey,endKey,offline,split,replicaId�Q�info:server格式�Q�HRegionServer对应的server:port�Q�info:serverstartcode格式是HRegionServer的启动时间戳�?br />

HRegionServer详解
HRegionServer一般和DataNode在同一台机器上�q�行�Q�实现数据的本地性。HRegionServer包含多个HRegion�Q�由WAL(HLog)、BlockCache、MemStore、HFile�l�成�?br />

WAL即Write Ahead Log�Q�在早期版本中称为HLog�Q�它是HDFS上的一个文�Ӟ��如其名字所表示的，所有写操作都会先保证将数据写入�q�个Log文�g后，才会真正更新MemStore�Q�最后写入HFile中。采用这�U�模式，可以保证HRegionServer宕机后，我们依然可以从该Log文�g中读取数据，Replay所有的操作�Q�而不至于数据丢失。这个Log文�g会定期Roll出新的文件而删除旧的文�?那些已持久化到HFile中的Log可以删除)。WAL文�g存储�?hbase/WALs/${HRegionServer_Name}的目录中(�?.94之前�Q�存储在/hbase/.logs/目录�?�Q�一般一个HRegionServer只有一个WAL实例�Q�也��是说一个HRegionServer的所有WAL写都是串行的(��像log4j的日志写也是串行�?�Q�这当然会引��h��能问题�Q�因而在HBase 1.0之后�Q�通过HBASE-5699实现了多个WAL�q�行�?MultiWAL)�Q�该实现采用HDFS的多个管道写�Q�以单个HRegion为单位。关于WAL可以参考Wikipedia�?a >Write-Ahead Logging。顺便吐槽一句，英文版的�l�基癄��竟然能毫无压力的正常讉K��了，�q�是某个GFW的疏忽还是以后的常态？

BlockCache是一个读�~�存�Q�即“引用局部�?#8221;原理�Q�也应用于CPU�Q?a >分空间局部性和旉��局部�?/a>�Q�空间局部性是指CPU在某一时刻需要某个数据，那么有很大的概率在一下时��d��需要的数据在其附近�Q�时间局部性是指某个数据在被访问过一�ơ后�Q�它有很大的概率在不久的��来会被再次的访问）�Q�将数据预读取到内存中，以提升读的性能。HBase中提供两�U�BlockCache的实玎ͼ�默认on-heap LruBlockCache和BucketCache(通常是off-heap)。通常BucketCache的性能要差于LruBlockCache�Q�然而由于GC的媄响，LruBlockCache的�g�q�会变的不稳定，而BucketCache�׃��是自��q��理BlockCache�Q�而不需要GC�Q�因而它的�g�q�通常比较�E�_��Q�这也是有些时候需要选用BucketCache的原因。这��文�?a >BlockCache101对on-heap和off-heap的BlockCache做了详细的比较�?/li>
HRegion是一个Table中的一个Region在一个HRegionServer中的表达。一个Table可以有一个或多个Region�Q�他们可以在一个相同的HRegionServer上，也可以分布在不同的HRegionServer上，一个HRegionServer可以有多个HRegion�Q�他们分别属于不同的Table。HRegion由多个Store(HStore)构成�Q�每个HStore对应了一个Table在这个HRegion中的一个Column Family�Q�即每个Column Family��是一个集中的存储单元�Q�因而最好将��h��相近IO�Ҏ��的Column存储在一个Column Family�Q�以实现高效��d��(数据局部性原理，可以提高�~�存的命中率)。HStore是HBase中存储的核心�Q�它实现了读写HDFS功能�Q�一个HStore�׃��个MemStore �?个或多个StoreFile�l�成�?br />

MemStore是一个写�~�存(In Memory Sorted Buffer)�Q�所有数据的写在完成WAL日志写后�Q�会写入MemStore中，由MemStore�Ҏ��一定的��法��数据Flush到地层HDFS文�g�?HFile)�Q�通常每个HRegion中的每个 Column Family有一个自��q��MemStore�?/li>
HFile(StoreFile) 用于存储HBase的数�?Cell/KeyValue)。在HFile中的数据是按RowKey、Column Family、Column排序�Q�对相同的Cell(卌��三个值都一�?�Q�则按timestamp倒序排列�?/li>

虽然上面�q�张囑ֱ�现的是最新的HRegionServer的架�?但是�q�不是那么的�_��)�Q�但是我一直比较喜�Ƣ看以下�q�张图，即��它展现的应该�?.94以前的架构�?br />

HRegionServer中数据写��程图解
当客��L��发�v一个Put��h��Ӟ��首先它从hbase:meta表中查出该Put数据最�l�需要去的HRegionServer。然后客��L��Put��h��发送给相应的HRegionServer�Q�在HRegionServer中它首先会将该Put操作写入WAL日志文�g�?Flush到磁盘中)�?br />
写完WAL日志文�g后，HRegionServer�Ҏ��Put中的TableName和RowKey扑ֈ�对应的HRegion�Q��ƈ�Ҏ��Column Family扑ֈ�对应的HStore�Q��ƈ��Put写入到该HStore的MemStore中。此时写成功�Q��ƈ�q�回通知客户端�?br />
MemStore Flush
MemStore是一个In Memory Sorted Buffer�Q�在每个HStore中都有一个MemStore�Q�即它是一个HRegion的一个Column Family对应一个实例。它的排列顺序以RowKey、Column Family、Column的顺序以及Timestamp的倒序�Q�如下所�C�：

每一�ơPut/Delete��h��都是先写入到MemStore中，当MemStore满后会Flush成一个新的StoreFile(底层实现是HFile)�Q�即一个HStore(Column Family)可以�?个或多个StoreFile(HFile)。有以下三种情况可以触发MemStore的Flush动作�Q?strong>需要注意的是MemStore的最��Flush单元是HRegion而不是单个MemStore。据说这是Column Family有个数限制的其中一个原因，估计是因为太多的Column Family一起Flush会引��h��能问题�Q�具体原因有待考证�?br />
当一个HRegion中的所有MemStore的大��d��过了hbase.hregion.memstore.flush.size的大��，默认128MB。此时当前的HRegion中所有的MemStore会Flush到HDFS中�?/li>
当全局MemStore的大��超�q�了hbase.regionserver.global.memstore.upperLimit的大��，默认40�Q�的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，Flush��序是MemStore大小的倒序�Q�一个HRegion中所有MemStore��d��作�ؓ该HRegion的MemStore的大��还是选取最大的MemStore作�ؓ参考？有待考证�Q�，直到��M��的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit�Q�默�?8%的内存��用量�?/li>
当前HRegionServer中WAL的大��超�q�了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的数量，当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，Flush使用旉��序�Q�最早的MemStore先Flush直到WAL的数量少于hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs�?a >�q�里说这两个�怹�的默认大��是2GB�Q�查代码�Q�hbase.regionserver.max.logs默认值是32�Q�而hbase.regionserver.hlog.blocksize是HDFS的默认blocksize�Q?2MB。但不管怎么��P��因�ؓ�q�个大小��过限制引�v的Flush不是一件好事，可能引�v长时间的延迟�Q�因而这��文章给的徏议：“Hint: keep hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs just a bit above hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE.”。�ƈ且需要注意，�q�里�l�的描述是有错的(虽然它是官方的文�?�?br />
在MemStore Flush�q�程中，�q�会在尾部追加一些meta数据�Q�其中就包括Flush时最大的WAL sequence��|��以告诉HBase�q�个StoreFile写入的最新数据的序列�Q�那么在Recover时就直到从哪里开始。在HRegion启动�Ӟ��q�个sequence会被��d��Q��ƈ取最大的作�ؓ下一�ơ更新时的�v始sequence�?br />
HFile格式
HBase的数据以KeyValue(Cell)的�Ş式顺序的存储在HFile中，在MemStore的Flush�q�程中生成HFile�Q�由于MemStore中存储的Cell遵��@相同的排列顺序，因而Flush�q�程是顺序写�Q�我们直到磁盘的��序写性能很高�Q�因��Z��需要不停的�U�d��盘指针�?br />
HFile参考BigTable的SSTable和Hadoop�?a >TFile实现�Q�从HBase开始到现在�Q�HFile�l�历了三个版本，其中V2�?.92引入�Q�V3�?.98引入。首先我们来看一下V1的格式：

V1的HFile由多个Data Block、Meta Block、FileInfo、Data Index、Meta Index、Trailer�l�成�Q�其中Data Block是HBase的最��存储单元，在前文中提到的BlockCache��是��Z��Data Block的缓存的。一个Data Block�׃��个魔数和一�p�d��的KeyValue(Cell)�l�成�Q�魔数是一个随机的数字�Q�用于表�C��是一个Data Block�c�d��Q�以快速监��这个Data Block的格式，防止数据的破坏。Data Block的大��可以在创徏Column Family时设�|?HColumnDescriptor.setBlockSize())�Q�默认值是64KB�Q�大��L��Block有利于顺序Scan�Q�小号Block利于随机查询�Q�因而需要权衡。Meta块是可选的�Q�FileInfo是固定长度的块，它纪录了文�g的一些Meta信息�Q�例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY�{�。Data Index和Meta Index�U�录了每个Data块和Meta块的其实炏V��未压羃时大��、Key(起始RowKey�Q?�{�。Trailer�U�录了FileInfo、Data Index、Meta Index块的起始位置�Q�Data Index和Meta Index索引的数量等。其中FileInfo和Trailer是固定长度的�?br />
HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项�Q��ƈ且有固定的结构。我们来看看里面的具体结构：

开始是两个固定长度的数��|��分别表示Key的长度和Value的长度。紧接着是Key�Q�开始是固定长度的数��|��表示RowKey的长度，紧接着�? RowKey�Q�然后是固定长度的数��|��表示Family的长度，然后是Family�Q�接着是Qualifier�Q�然后是两个固定长度的数��|��表示Time Stamp和Key Type�Q�Put/Delete�Q�。Value部分没有�q�么复杂的结构，��是�U��a的二�q�制数据了�?strong>随着HFile版本�q�移�Q�KeyValue(Cell)的格式�ƈ未发生太多变化，只是在V3版本�Q�尾部添加了一个可选的Tag数组�?br />
HFileV1版本的在实际使用�q�程中发现它占用内存多，�q�且Bloom File和Block Index会变的很大，而引起启动时间变�ѝ��其中每个HFile的Bloom Filter可以增长�?00MB�Q�这在查询时会引��h��能问题�Q�因为每�ơ查询时需要加载�ƈ查询Bloom Filter�Q?00MB的Bloom Filer会引起很大的延迟�Q�另一个，Block Index在一个HRegionServer可能会增长到��d��6GB�Q�HRegionServer在启动时需要先加蝲所有这些Block Index�Q�因而增加了启动旉��。�ؓ了解册��些问题，�?.92版本中引入HFileV2版本�Q?br />
在这个版本中�Q�Block Index和Bloom Filter��d��C��Data Block中间�Q�而这�U�设计同时也减少了写的内存��用量�Q�另外，��Z��提升启动速度�Q�在�q�个版本中还引入了�g�q�读的功能，卛_��HFile真正被��用时才对其进行解析�?br />
FileV3版本基本和V2版本相比�Q��ƈ没有太大的改变，它在KeyValue(Cell)层面上添加了Tag数组的支持；�q�在FileInfo�l�构中添加了和Tag相关的两个字�D�c��关于具体HFile格式演化介绍�Q�可以参�?a >�q�里�?br />
对HFileV2格式具体分析�Q�它是一个多层的�c�B+树烦引，采用�q�种设计�Q�可以实现查找不需要读取整个文�Ӟ��

Data Block中的Cell都是升序排列�Q�每个block都有它自��q��Leaf-Index�Q�每个Block的最后一个Key被放入Intermediate-Index中，Root-Index指向Intermediate-Index。在HFile的末��还有Bloom Filter用于快速定位那么没有在某个Data Block中的Row�Q�TimeRange信息用于�l�那些��用时间查询的参考。在HFile打开�Ӟ��q�些索引信息都被加蝲�q�保存在内存中，以增加以后的��d��性能�?br />
�q�篇��先写到�q�里�Q�未完待�l�。。。�?br />

参考：
https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx
http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable
http://hbase.apache.org/book.html
http://www.searchtb.com/2011/01/understanding-hbase.html
http://research.google.com/archive/bigtable-osdi06.pdf

DLevin 2015-08-22 17:44 发表评论

亚洲视频在线观看地址,亚洲人成77777在线播放网站不卡,国产亚洲免费的视频看

Netty3架构解析

前记

Netty3中的Reactor模式

Netty3中的Intercepting Filter模式

参考：

Intercepting Filter模式详解

问题描述

问题解决

Intercepting Filter模式

Intercepting Filter模式在Netty3中的实现

参�?/h2>Core J2EE Pattern - Intercepting FilterDLevin 2015-09-03 22:14 发表评论

Reactor模式详解

前记

什么是Reactor模式

Reactor模式�l�构

Reactor模式实现

EventHandler接口定义

��Z��么��用Reactor模式

参�?/h2> Reactor Pattern WikiPedia Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events Scalable IO In Java C10K Problem WikiPedia DLevin 2015-09-02 15:14 发表评论

前言

HBase�ȝ��实现

Compaction

HRegion Split

HRegion负蝲均衡

HRegionServer Recovery

HBase架构���单�ȝ��

参考：

前记

HBase架构�l�成

HRegion

HMaster

How The Components Work Together

HRegionServer详解

HRegionServer中数据写���程图解

MemStore Flush

HFile格式

参考：

参�?/h2>Core J2EE Pattern - Intercepting Filter

DLevin 2015-09-03 22:14 发表评论

参�?/h2> Reactor Pattern WikiPedia
Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events
Scalable IO In Java
C10K Problem WikiPedia

DLevin 2015-09-02 15:14 发表评论

HBase架构��单�ȝ��

HRegionServer中数据写��程图解