app开发之IM链接通信的技术选项.docxVIP

app开发之 IM 通信技术选型 为什么要Comet??常规的轮询方式缺点：大量客户端产生了大量的传输浪费。每个客户端都必须有规律的请求服务器来获得更改，这是服务器资源的一个?重担。最坏的情况是程序很少更新，例如Ajax邮件收件箱。在这种情况下，大量的客户端轮询是多余的，服务器仅仅简单的响应没有数据。可以通过增加轮询间隔时间来减轻服务器负荷，但是这引入了服务器事件和客户端知晓之间的延迟。当然，一个合理的折衷方案可以?多数程序适用，并且轮询的工作方式也可以接受。?Comet的优势：客户端不会产生轮询方式特有的传输浪费，一旦事件发生，就会被发布到客户端。?但是维持长连接也消耗了服务器资源。当servlet位置持久的请求在等候状态时，servlet独占一个线程。这样传统的servlet引擎就限制了?Comet的伸缩性，因为客户端的数量会迅速超过服务器栈可以有效处理的线程的数量。? 目前实现Comet 的三种方式。 Tomcat 6.0 Advanced IO and Tomcat 这个特性需要APR 或者NIO HTTP connectors,经典的 java.io HTTP connector 和 AJP connectors 不支持此特性。这个方案可以处理大并发量的访问。很好的解决了链接长时间处于idle 状态的应用场景。 服务器端的处理请求的服务类必须实现org.apache.catalina.CometProcessor? 接口，导致了应用依赖tomcat容器。 Jetty continuations Jetty 容器使用了很轻量级的技术实现了comet，jetty 利用的机制是continuations。实现思路相当简单，请求会被容器挂起，至到某个时刻重新被容器继续执行。 当请求挂起时，占用的容器线程会被释放。 Servlet3.0 异步处理支持：有了该特性，Servlet 线程不再需要一直阻塞，直到业务处理完毕才能再输出响应，最后才结束该 Servlet 线程。在接收到请求之后，Servlet 线程可以将耗时的操作委派给另一个线程来完成，自己在不生成响应的情况下返回至容器。针对业务处理较耗时的情况，这将大大减少服务器资源的占用，并且提高并发处理速度。目前已经有GlassFish v3、Tomcat 7.0、Jetty 8.0 等web容器支持 Servlet 3.0 标准。 代码示例： @WebServlet(asyncSupported=true, asyncTimeout=5000) public class WeatherServlet extends HttpServlet { Private MessageSender messageSender; @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { AsyncContext async = request.startAsync(request, response); messageSender.setConnection(async); Weatherman weatherman = new Weatherman(95118, 32444); async.start (weatherman); } } Jeety 与Tomcat 相同点： ???Tomcat和Jetty都是一种Servlet引擎，他们都支持标准的servlet规范和JavaEE的规范。 不同点 1.??????架构比较 Jetty的架构比Tomcat的更为简单 Jetty的架构是基于Handler来实现的，主要的扩展功能都可以用Handler来实现，扩展简单。 Tomcat的架构是基于容器设计的，进行扩展是需要了解Tomcat的整体设计结构，不易扩展。 ? 2.??????性能比较 Jetty和Tomcat性能方面差异不大 Jetty可以同时处理大量连接而且可以长时间保持连接，适合于web聊天应用等等。 Jetty的架构简单，因此作为服务器，Jetty可以按需加载组件，减少不需要的组件，减少了服务器内存开销，从而提高服务器性能。 Jetty默认采用NIO结束在处理I/O请求上更占优势，在处理静态资源时，性能较高 Tomcat适合处理少数非常繁忙的链接，也就是说链接生命周期短的话，Tomcat的总体性能更高。 Tomcat默认采用BIO处理I/O请求，在处理静态资