Jetty Continuation实现原理和使用场景分析

bmwm3

Jetty Continuation实现原理和使用场景分析
　　Jetty continuation是什么？简单的说，就是用一个NIO模拟http同步连接。我们都知道http请求时同步的，就是说http request发送到server之后，server分配一个单独的线程处理这个请求，请求完成之后再返回response给请求端。这个过程中server处理线程一般是不释放，即使是什么都没有干。更关键的是承载http请求的tcp socket是阻塞式的。显而易见的是如果这个请求时间较长，不但server threads被占用而无法处理新请求，仅仅是并发连接数的问题就让人头疼。

Jetty Continuation
　　翻译一下Jetty Continuation的官方解释：“Continuation是一种可以使HTTP请求可以被暂时挂起，并且当挂起超时或非同步的事件发生时，被挂起的HTTP请求可以被重新恢复的机制”。这个机制的实现主要在SelectChannelConnector类中。网上不少朋友都分析了这个实现，Continuation.suspend()会抛出一个特殊的运行时异常：RetryRequest。这个异常将传播到servlet以外，然后通过过滤器传回，再由SelectChannelConnector捕获，将请求放入处于等待状态的Continuation队列中，此时HTTP连接并不关闭，而当前的线程却可以被放回线程池，供别的请求使用。我想这里应该被强调的一点就是：Continuation机制实际就是对HTTP协议执行NIO。
　　简单的看一下代码，这是SelectChannelConnector$RetryContinuation类，resume方法

       public void resume()
{
...
SelectSet selectSet = _endPoint.getSelectSet();
synchronized (selectSet)
{
this.cancel();   
}
_endPoint.scheduleIdle();  // TODO maybe not needed?
selectSet.addChange(this);
selectSet.wakeup();
}
}
　　可以看到resume（）方法调用了selectSet.wakeup()，而SelectSet调用了NIO selector的wakeup方法，

        public void wakeup()
{
Selector selector = _selector;
if (selector!=null)
selector.wakeup();
}
　　基于NIO，Jetty可以在一个非阻塞的socket中处理多个HTTP请求。

使用场景
　　我们都知道Jetty适合处理HTTP长连问题，比如网上讨论的很多的webim。我们已经讨论了Jetty实际上实现了HTTP层的NIO，那么还有更多别的场景也适合用Jetty解决。举个栗子，我有个朋友搞了一个http透明代理，用于做前端负载转发和均衡。这个代理逻辑很薄，但是它后端的处理比较重，就是说尽管透明代理什么都不干，但它的socket和线程却长期得不到释放，十分“浪费”。这种场景下，用Jetty Continuation就十分合适。
　　有一个误解是，凡是服务器“推”的长连接场景，都应该使用Jetty。其实不然，我们有一个streaming API的实现，从HTTP server推送海量数据。client端在HTTP请求里携带一个数据index，服务器根据这个index把之后产生的数据不间断的推送到client端，是典型的长连接。但是这里的长连接数量很少，而且是网络传输很重的操作，这个场景下，使用几个单独的socket，而不是多个处理复用socket，就十分合适。因此我们就使用了更简单的Tomcat服务器而没有使用Jetty。
　　总结，了解Continuation的原理可以使你更好的选择方案，而不是简单的引入过多用不上的逻辑，别忘了很多情况下，简单即是优雅。
　　

本文纯属原创，欢迎引用，请注明本博地址：

http://maoyidao.iteye.com/