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/