[b]Cometd & Jetty Continuations[/b]
Contents
一.Cometd
1.Cometd Server
Bayeux
Client
Channel
ContinuationCometdServlet
2.Cometd Client
二.Jetty NIO & Continuation
1.Jetty Server With NIO
2.Jetty Continuation
前言:随着web的不断发展,出现了诸如ajax,comet等技术,其实都是为了提高用户体验。在web并发量越来越高的今天,异步成了一个热点。servlet3.0也引入了异步处理的概念。
Comet是一种服务器端推的技术,所谓服务器端推也就是当有事件要通知给某个用户的时候,是由服务器端直接发送到用户的浏览器。
服务器端Push目前一般有两种方式,HTTP streaming和Long polling。详细的介绍可以看这里 http://en.wikipedia.org/wiki/Push_technology
有一个Comet的框架叫做Cometd,使用的方式为Long polling。它是使用了jetty continuations特性,jetty continuations使得异步的request成为可能,这里我们来讨论下为何需要jetty continuations呢?
比如我们的浏览器的一个请求发送到服务器端了,并进行长轮询,保持了连接不结束,直到一次长轮询timeout或者有事件发生,并接收到服务端推来的消息,所以在一次长轮询的过程中,大部分时间都是在等待,如果使用老式同步的方式进行编程的话,那么有多少个连接就需要多少个线程在那里,而大都数都是在等待,所以这无疑是系统资源的巨大浪费。
jetty continuations很好的解决了这一问题,当有请求过来之后,将连接的相关信息封装到一个continuation的对象中,通过调用continuation的suspend方法,然后返回,把当前线程交还到线程池,所以这个时候线程可以返回到线程池等待并处理其他新的请求。
当有事件要发给之前的某个请求的时候,再调用对应的continuation的resume方法,将原来的哪个请求重新发送到servelt进行处理,并将消息发送给客户端,然后客户端会重新进行一次长轮询。
下面我来由上而下详细讲述jetty continuation实现方式
一.Cometd
Cometd是一个Comet的框架,实现方式为基于jetty continuation的长轮询。
Cometd的消息都基于一个叫做Bayeux的消息协议
Bayeux的主要目的是支持使用ajax的客户端与服务器端之间灵敏,快速的信息交互。
Bayeux是一种用来在客户端和服务器端传输低延迟的异步消息(主要通过http)的一种协议。它定义的消息通过命名通道进行路由并且能够进行交互传 送:server -> client, client -> server 甚至 client -> client (当然还是需要通过server中转)。默认的,此通道已经引用了发布的路由语义,但同时也支持其它路由模块。
从服务器端向客户端异步发送的数据通常被叫做 “服务器推”(server-push)。这种使用ajax的web应用和服务器推技术的结合称作“Comet”。 Cometd是一个提供多种开发语言的Bayeux项目,由Dojo基金会提供支持。
1.Cometd Server
在服务器端推中,一个常见的应用场景便是,消息的生产者可以往一些消息channel中通过bayeux协议发送消息,服务器端对bayeux消息进行处理解析,发送到所有订阅了这个channel的消息消费者,消费者接收到这个消息之后便可以自己再做自己的处理。在这样的模型中于是出现了几个重要的概念:
Bayeux
这个在cometd框架中是ContinuationBayeux类,
bayeux对象在cometd运行的上下文中非常重要,可以说是一个核心对象,它管理着所有的clients和channel,并肩负着消息的处理和维护。
channel在cometd中是一个树形的结构,在bayeux对象中,保存着根channel(/),从根channel我们可以找到它的子channel
bayeux存在一个handle方法,对消息进行处理
Client
一个client对应着一个消息的生产者或者消费者,对应的类为ContinuationClient。
client中包含一个contiunation对象,以及对continuation对象进行操作的suspend和resume的方法
subscriptions保存着当前client的所有订阅的频道channel
client由一个clientId唯一标示,每一个client还对应着一个browserId。
client可以通过deliver方法来进行接受消息操作,接受消息无非就是将接收到的消息加入到自己的消息队列中,并将continuation对象进行resume,这样之前冻结的request重新发送到servlet进行处理。
Channel
channel在cometd中对应ChannelImpl类
channel中维护这一个subscribers的列表,用来保存订阅了当前channel的订阅者
channel还维护者自己的子channel
每一个channel都对应这一个channelId 也就是channel的路径字符串
ContinuationCometdServlet
Cometd Server运行时的入口为ContinuationCometdServlet
Handshake
客户端和服务器端建立连接之前需要先握手,在服务器端将客户端标识起来。一个请求过来如果cookie中没有broswer_id那么就生成一个broswer_id(相当于session_id 因为这些请求并非无状态的,需要在多次长轮询中记住请求是来自同一个客户端),并写到cookie中。握手的时候还会生成一个ContinuationClient对象,每一个ContinuationClient对象由一个client_id唯一标识。并在握手成功后将这个clientId作为消息的一部分发给客户端。由于握手的消息是属于元数据消息,所以在Bayeux中提供了所有元消息channel的Handler。这些handler最终将消息交给各种Transport去发送,Tranport对象 此类对象主要是用来处理消息的发送,比如JSONTransport或者JSONPTransport,这两个对象中都有response的引用,所以可以用来直接回复客户端。
Subscribe
订阅的主要作用是将订阅某个Channel的客户端所对应的ContinuationClient对象加入到对应的channel的subscribers列表中,并将所订阅的channel加入到ContinuationClient对象的subscriptions数组中。订阅成功之后就应该开始了long-pooling了,这个时候,服务器端会将当前的请求封装到一个Continuation中,并将Continuation对象设到ContinuationClient对象中,然后将ContinuationClient对象suspend,让出当前处理线程。
Publish
当一个客户端往一个channel中publish消息的时候,服务器端接收到这个message,有两种方式处理这个消息,一个是在相应的channel中广播这个消息,这个时候调用channel的push方法,对每一个订阅了当前channel及其子channel中的ContinuationClient进行消息分发,将消息复制到每一个ContinuationClient自己的消息队列中,并将ContinuationClient中的Continuation唤醒resume。这个时候之前暂停的request会被重新发送到servlet,并且servlet可以知道其状态,并进行消息的处理。还有一种消息的发送是直接调用某个ContinuationClient对象进行消息的发送。
2.Cometd Client
上面讲了服务器端的各种情况的处理,当然光有服务器端的处理是没有用的,还需要客户端的配合。
客户端既可以是后端的java程序,更多的时候是浏览器。
浏览器中采用Ajax的方式和服务器进行交互,cometd提供了基于dojo和jquery两个js框架的cometd-client
二.Jetty NIO & Continuation
在Cometd部分提及到当服务器端接收到来自客户端发来的消息,然后对消息进行处理。当然在web应用中,消息的接受最初都是由web容器来接受,这涉及到了socket的处理,这个时候web容器本身的io性能就非常重要了。
在传统的BIO服务器模型中,一个新的连接来了,就要创建一个线程来接受这个socket连接(一个连接一个线程),进行简单的封装后,分发给web容器的”线程池“,线程池会选择一个线程来处理连接请求并给予响应。
而在NIO的模型中,只需要一个线程便可以处理所有的连接,当有新的连接建立的时候,只需要将连接注册到selector中,直到某次检测到有请求了,便开始对请求进行处理,并将他们都交给”线程池“(所有的连接都是一个线程在处理,直到发现了请求,再将请求分发出去)。
在高效的Comet应用的最底层还需要一个高效的web容器。
1.Jetty Server With NIO
Jetty是一个纯java实现的非常轻量级的web容器,高度组件化,可以很方便的将各种组件进行组装,而且可以非常容易的将jetty嵌入到自己的应用中。
jetty运行时的核心类是Server类,这个类的配置一般在jetty.xml中配置,然后jetty自带的一个简单的ioc容器将server加载初始化。
下图主要描述了Jetty在NIO的模式下工作的情形,这里只说到将任务分配到ThreadPool,后面的ThreadPool的处理没有说,大家可以去看下源码。
在jetty中,web容器启动是从Server开始的,一个Server可以对应多个Connector,从名字就可以知道,Connector是来处理外部连接的,Connector的实现有多种,即可以是非阻塞的(如SelectChannelConnector),也可以是阻塞的(如BlockingChannelConnector,当然jetty中这个阻塞的已经使用nio优化过,性能应该比使用java io实现的好),
我们不能直接说谁的性能好,谁的性能不好,关键还是看应用场景,因为NIO实现的非阻塞的话,doSelect的过程是阻塞的。所以当并发量小,且请求可以快速得到响应的话,用阻塞的就可以很好的满足了,但是当并发量很大,且后端资源紧张,请求需要等待很长一段时间的(比如长轮询),那么NIO的性能肯定必传统的高很多很多倍。
这里稍微讲一下NIO的概念把,在NIO的Scoket通讯模型中,一个socket连接对应一个SocketChannel,SocketChannel可以将某个事件注册到某一个Selector上,然后对Selector进行select操作,当有请求来的时候,并可以通过Selector的selectedKeys()获得所有收到事件的channel,然后便可以对channel进行操作了。这个其实和linux中的select函数类似,只不过这里是面向对象的,在linux中,我们将需要监听的sockt连接加入到一个文件描述符的集合中FD_SET中,然后select函数对这个集合进行检测,根据得到的结果来判断某个fd对应的标志位是否为1来判断是否有数据。这样也就是一个线程可以同事处理多个连接。
换话题了,我们都知道请求最终都是在Servlet中被处理的,而Servlet得到的是request,response,这些对象什么时候出来的呢?不急,上面不是说到一个EndPoint(实现了Runnable接口)EndPoint对象在被初始化的时候就对其_connection成员进行了初始化,生成一个HttpConnection对象,newConnection的方法其实在SelectChannelConnector中被覆盖了。然后这个EndPoint对象不是被分配到ThreadPool了么,ThreadPool将其加入到队列中,当有空闲线程的时候,就对这个endPoint对象进行处理了,运行EndPoint的run方法,然后会调用自己的connection对象的handle方法,最终将connection对象交给Server的handler进行处理。Server本身继承自HandlerWrapper,自己的_handler是一个HandlerCollection的实例,HandlerCollection实例的配置在jetty.xml中有配置,在处理httpconnection对象的时候所配置的handler会依次被执行。
DefaultHandler中就涉及到上下文处理,然后交给各个项目的servlet进行处理。
2.Jetty Continuation
Jetty Continuation在jetty7的实现中也就8个类,非常的简洁。
ContinuationSupport类是产生Continuation对象的工厂类。它会根据当前服务器容器的类型选择不同类型的Continuation对象,比如支持jetty6版本的,还有支持servlet3.0版本(对servlet3.0异步处理进行了封装),还有一个阻塞的Continuation实现FauxContinuation。
原文地址:http://geeklu.com/2010/07/cometd-jetty-continuations/
Contents
一.Cometd
1.Cometd Server
Bayeux
Client
Channel
ContinuationCometdServlet
2.Cometd Client
二.Jetty NIO & Continuation
1.Jetty Server With NIO
2.Jetty Continuation
前言:随着web的不断发展,出现了诸如ajax,comet等技术,其实都是为了提高用户体验。在web并发量越来越高的今天,异步成了一个热点。servlet3.0也引入了异步处理的概念。
Comet是一种服务器端推的技术,所谓服务器端推也就是当有事件要通知给某个用户的时候,是由服务器端直接发送到用户的浏览器。
服务器端Push目前一般有两种方式,HTTP streaming和Long polling。详细的介绍可以看这里 http://en.wikipedia.org/wiki/Push_technology
有一个Comet的框架叫做Cometd,使用的方式为Long polling。它是使用了jetty continuations特性,jetty continuations使得异步的request成为可能,这里我们来讨论下为何需要jetty continuations呢?
比如我们的浏览器的一个请求发送到服务器端了,并进行长轮询,保持了连接不结束,直到一次长轮询timeout或者有事件发生,并接收到服务端推来的消息,所以在一次长轮询的过程中,大部分时间都是在等待,如果使用老式同步的方式进行编程的话,那么有多少个连接就需要多少个线程在那里,而大都数都是在等待,所以这无疑是系统资源的巨大浪费。
jetty continuations很好的解决了这一问题,当有请求过来之后,将连接的相关信息封装到一个continuation的对象中,通过调用continuation的suspend方法,然后返回,把当前线程交还到线程池,所以这个时候线程可以返回到线程池等待并处理其他新的请求。
当有事件要发给之前的某个请求的时候,再调用对应的continuation的resume方法,将原来的哪个请求重新发送到servelt进行处理,并将消息发送给客户端,然后客户端会重新进行一次长轮询。
下面我来由上而下详细讲述jetty continuation实现方式
一.Cometd
Cometd是一个Comet的框架,实现方式为基于jetty continuation的长轮询。
Cometd的消息都基于一个叫做Bayeux的消息协议
Bayeux的主要目的是支持使用ajax的客户端与服务器端之间灵敏,快速的信息交互。
Bayeux是一种用来在客户端和服务器端传输低延迟的异步消息(主要通过http)的一种协议。它定义的消息通过命名通道进行路由并且能够进行交互传 送:server -> client, client -> server 甚至 client -> client (当然还是需要通过server中转)。默认的,此通道已经引用了发布的路由语义,但同时也支持其它路由模块。
从服务器端向客户端异步发送的数据通常被叫做 “服务器推”(server-push)。这种使用ajax的web应用和服务器推技术的结合称作“Comet”。 Cometd是一个提供多种开发语言的Bayeux项目,由Dojo基金会提供支持。
1.Cometd Server
在服务器端推中,一个常见的应用场景便是,消息的生产者可以往一些消息channel中通过bayeux协议发送消息,服务器端对bayeux消息进行处理解析,发送到所有订阅了这个channel的消息消费者,消费者接收到这个消息之后便可以自己再做自己的处理。在这样的模型中于是出现了几个重要的概念:
Bayeux
这个在cometd框架中是ContinuationBayeux类,
bayeux对象在cometd运行的上下文中非常重要,可以说是一个核心对象,它管理着所有的clients和channel,并肩负着消息的处理和维护。
channel在cometd中是一个树形的结构,在bayeux对象中,保存着根channel(/),从根channel我们可以找到它的子channel
bayeux存在一个handle方法,对消息进行处理
Client
一个client对应着一个消息的生产者或者消费者,对应的类为ContinuationClient。
client中包含一个contiunation对象,以及对continuation对象进行操作的suspend和resume的方法
subscriptions保存着当前client的所有订阅的频道channel
client由一个clientId唯一标示,每一个client还对应着一个browserId。
client可以通过deliver方法来进行接受消息操作,接受消息无非就是将接收到的消息加入到自己的消息队列中,并将continuation对象进行resume,这样之前冻结的request重新发送到servlet进行处理。
Channel
channel在cometd中对应ChannelImpl类
channel中维护这一个subscribers的列表,用来保存订阅了当前channel的订阅者
channel还维护者自己的子channel
每一个channel都对应这一个channelId 也就是channel的路径字符串
ContinuationCometdServlet
Cometd Server运行时的入口为ContinuationCometdServlet
Handshake
客户端和服务器端建立连接之前需要先握手,在服务器端将客户端标识起来。一个请求过来如果cookie中没有broswer_id那么就生成一个broswer_id(相当于session_id 因为这些请求并非无状态的,需要在多次长轮询中记住请求是来自同一个客户端),并写到cookie中。握手的时候还会生成一个ContinuationClient对象,每一个ContinuationClient对象由一个client_id唯一标识。并在握手成功后将这个clientId作为消息的一部分发给客户端。由于握手的消息是属于元数据消息,所以在Bayeux中提供了所有元消息channel的Handler。这些handler最终将消息交给各种Transport去发送,Tranport对象 此类对象主要是用来处理消息的发送,比如JSONTransport或者JSONPTransport,这两个对象中都有response的引用,所以可以用来直接回复客户端。
Subscribe
订阅的主要作用是将订阅某个Channel的客户端所对应的ContinuationClient对象加入到对应的channel的subscribers列表中,并将所订阅的channel加入到ContinuationClient对象的subscriptions数组中。订阅成功之后就应该开始了long-pooling了,这个时候,服务器端会将当前的请求封装到一个Continuation中,并将Continuation对象设到ContinuationClient对象中,然后将ContinuationClient对象suspend,让出当前处理线程。
Publish
当一个客户端往一个channel中publish消息的时候,服务器端接收到这个message,有两种方式处理这个消息,一个是在相应的channel中广播这个消息,这个时候调用channel的push方法,对每一个订阅了当前channel及其子channel中的ContinuationClient进行消息分发,将消息复制到每一个ContinuationClient自己的消息队列中,并将ContinuationClient中的Continuation唤醒resume。这个时候之前暂停的request会被重新发送到servlet,并且servlet可以知道其状态,并进行消息的处理。还有一种消息的发送是直接调用某个ContinuationClient对象进行消息的发送。
2.Cometd Client
上面讲了服务器端的各种情况的处理,当然光有服务器端的处理是没有用的,还需要客户端的配合。
客户端既可以是后端的java程序,更多的时候是浏览器。
浏览器中采用Ajax的方式和服务器进行交互,cometd提供了基于dojo和jquery两个js框架的cometd-client
二.Jetty NIO & Continuation
在Cometd部分提及到当服务器端接收到来自客户端发来的消息,然后对消息进行处理。当然在web应用中,消息的接受最初都是由web容器来接受,这涉及到了socket的处理,这个时候web容器本身的io性能就非常重要了。
在传统的BIO服务器模型中,一个新的连接来了,就要创建一个线程来接受这个socket连接(一个连接一个线程),进行简单的封装后,分发给web容器的”线程池“,线程池会选择一个线程来处理连接请求并给予响应。
而在NIO的模型中,只需要一个线程便可以处理所有的连接,当有新的连接建立的时候,只需要将连接注册到selector中,直到某次检测到有请求了,便开始对请求进行处理,并将他们都交给”线程池“(所有的连接都是一个线程在处理,直到发现了请求,再将请求分发出去)。
在高效的Comet应用的最底层还需要一个高效的web容器。
1.Jetty Server With NIO
Jetty是一个纯java实现的非常轻量级的web容器,高度组件化,可以很方便的将各种组件进行组装,而且可以非常容易的将jetty嵌入到自己的应用中。
jetty运行时的核心类是Server类,这个类的配置一般在jetty.xml中配置,然后jetty自带的一个简单的ioc容器将server加载初始化。
下图主要描述了Jetty在NIO的模式下工作的情形,这里只说到将任务分配到ThreadPool,后面的ThreadPool的处理没有说,大家可以去看下源码。
在jetty中,web容器启动是从Server开始的,一个Server可以对应多个Connector,从名字就可以知道,Connector是来处理外部连接的,Connector的实现有多种,即可以是非阻塞的(如SelectChannelConnector),也可以是阻塞的(如BlockingChannelConnector,当然jetty中这个阻塞的已经使用nio优化过,性能应该比使用java io实现的好),
我们不能直接说谁的性能好,谁的性能不好,关键还是看应用场景,因为NIO实现的非阻塞的话,doSelect的过程是阻塞的。所以当并发量小,且请求可以快速得到响应的话,用阻塞的就可以很好的满足了,但是当并发量很大,且后端资源紧张,请求需要等待很长一段时间的(比如长轮询),那么NIO的性能肯定必传统的高很多很多倍。
这里稍微讲一下NIO的概念把,在NIO的Scoket通讯模型中,一个socket连接对应一个SocketChannel,SocketChannel可以将某个事件注册到某一个Selector上,然后对Selector进行select操作,当有请求来的时候,并可以通过Selector的selectedKeys()获得所有收到事件的channel,然后便可以对channel进行操作了。这个其实和linux中的select函数类似,只不过这里是面向对象的,在linux中,我们将需要监听的sockt连接加入到一个文件描述符的集合中FD_SET中,然后select函数对这个集合进行检测,根据得到的结果来判断某个fd对应的标志位是否为1来判断是否有数据。这样也就是一个线程可以同事处理多个连接。
换话题了,我们都知道请求最终都是在Servlet中被处理的,而Servlet得到的是request,response,这些对象什么时候出来的呢?不急,上面不是说到一个EndPoint(实现了Runnable接口)EndPoint对象在被初始化的时候就对其_connection成员进行了初始化,生成一个HttpConnection对象,newConnection的方法其实在SelectChannelConnector中被覆盖了。然后这个EndPoint对象不是被分配到ThreadPool了么,ThreadPool将其加入到队列中,当有空闲线程的时候,就对这个endPoint对象进行处理了,运行EndPoint的run方法,然后会调用自己的connection对象的handle方法,最终将connection对象交给Server的handler进行处理。Server本身继承自HandlerWrapper,自己的_handler是一个HandlerCollection的实例,HandlerCollection实例的配置在jetty.xml中有配置,在处理httpconnection对象的时候所配置的handler会依次被执行。
DefaultHandler中就涉及到上下文处理,然后交给各个项目的servlet进行处理。
2.Jetty Continuation
Jetty Continuation在jetty7的实现中也就8个类,非常的简洁。
ContinuationSupport类是产生Continuation对象的工厂类。它会根据当前服务器容器的类型选择不同类型的Continuation对象,比如支持jetty6版本的,还有支持servlet3.0版本(对servlet3.0异步处理进行了封装),还有一个阻塞的Continuation实现FauxContinuation。
原文地址:http://geeklu.com/2010/07/cometd-jetty-continuations/