Comet & Jetty Continuations

      Comet是一种服务器端推的技术，所谓服务器端推也就是当有事件要通知给某个用户的时候，是由服务器端直接发送到用户的浏览器。服务器端Push目前一般有两种方式，HTTP Streaming和Long Polling。

      Comet中文如果直译叫做彗星，其实是比较形象的一种说法。Comet在某些场景下也被叫做Http Streaming。Comet作为一种技术手段，其实是指在客户端和服务端建立连接后，可以由服务端主动发起请求将数据推送给客户端，而客户端根据推送的数据增量迭代的更新展示。因此服务端的数据推送就好比彗星一样不定时的传送到了客户端 。

优缺点及应用场景

        在Servlet3.0规范中已经将Comet作为基本内容涵盖在内，很多支持Servlet 3.0的容器也都已经支持了这些特性，后面会具体的谈到。但是这些特性其实也是在一些特定场景下才会体现出其价值，同时也存在着自身的不足之处。

        Comet与传统的处理模式最大的特点就在于http通道的长连接和服务端主动推送，基于事件模型。对于客户端频繁要去获取状态数据或者消息数据的场景下，通过传统的请求方式来轮询会极大消耗服务端的资源（带宽和业务处理能力），同时反复建立数据连接也会造成服务端和客户端性能的消耗。但另一方面，其实这两个特点也会成为缺点，保持长连接会导致大量的连接资源消耗（如果没有数据传输的话），另一方面服务端如果数据推送过于频繁，会导致客户端崩溃。

        对于Comet和传统Http请求处理的取舍，需要考虑这些因素：

1．  是否是单个客户端反复需要请求服务端获取数据或者状态的场景。是则继续2的判断，否则考虑使用传统的方式。

2．  客户端数目多少。如果客户端数目不多，则直接采用Comet，否则考虑第三点。

3．  单个客户端对于服务端请求的频度。（主要是由服务端数据状态变化的频度来决定），频度高，则考虑才用Comet，因为如果频度高，那么长连接的利用率就会高，则长连接带来的消耗就可以忽略。

       对于服务端数据推送过多导致客户端崩溃，可以通过在服务端做数据合并或者在客户端丢弃数据的方式来提升性能。（建议在服务端处理，减少带宽和两方的性能消耗）

       最后就是Comet的编程模型基于事件模式和Http长连接，那么首先需要选择新版本的容器，例如Tomcat7或者jetty6以上或者glassfish的新版本，其次服务端开发需要符合事件模型驱动的设计，客户端也需要支持长连接的数据增量推送处理和展示。另一方面确保你的网络方面在做LB的时候不会由于Http长连接过多导致LB性能大幅度下降，同时客户端网络如果质量不好也会间接导致服务端Load上升。

Async Request Process

      Arp优势就在于能够最大限度优化容器或者Socket连接处理能力，优化资源分配，提高并发处理能力。劣势在于编程习惯不符合常规的模式，对框架的要求高（异步协同，线程和资源管理等，由此带来的复杂度会导致可用性会受到影响）。

Jetty

      Jetty中的异步处理叫做Continuation，这里不是基于事件驱动模型的，而是通过Continuation这个对象来suspend/resume请求处理线程，同时它的suspend/resume也不是和传统的wait/notify一样，在阻塞的地方直接挂起或者被唤醒。它的resume其实又再次模拟了请求，会二次进入服务处理流程，同时第一次和第二次请求数据是不共享的（可以通过attachment来传递数据）。就这么看来，其实在suspend的时候所有的资源都被释放了，仅仅只是保存了请求来源信息在队列中，在后续被唤醒的时候再次模拟请求，由业务代码在实现中判断是否是第一次进入，并且在不同进入时请求处理过程做差异化实现，最终将不同的逻辑通过不同阶段的重入判断来分阶段处理。

Tomcat

         Tomcat采用的与Jetty不同的设计方式，它的Comet是事件驱动的。每一个传统的Servlet需要实现CometProcessor接口，这个接口就需要实现类似于原来Servlet的service的event方法，event方法会在各种事件发生的时候被激发，event当前主要包含了整个处理的生命周期（begin,close,error,read）。

         需要注意的是在Tomcat配置connector的时候必须选择apr或者nio的connector，否则是不生效的。可以看到，就和NIO一样，对于连接建立，数据可读，都是基于事件触发，将业务和具体的连接分开，提高在业务处理较慢的情况下，服务器的吞吐能力。这种设计是比较贴近于NIO的设计思想的。