Learning About Coment And Polling
信息传递的时候机制有推（push）和拉（pull）两种方式。
推，顾名思义就是客户端（web or client）与服务器建立连接后，直接把请求发给服务器，并等待响应。具体到短彩业务里就是本地建立了短信包后，直接发给服务器进行业务处理，再转给网关进行发送。期间客户端处于等待响应状态，直到发送成功，网关返回信息给客户端。
拉，则是定时的轮询，每间隔一段时间发送一次请求，看是否有新的消息需要进行处理。具体到短彩业务里就是短信包建立以后服务器把包信息保存到数据库里，保存成功就返回客户端成功响应。再对该表进行轮询，定时把没有发送的短信包发给网关。
由于短彩发送过程中涉及到三个环节：客户端 –> 服务器 –> 网关。三个环节各有推拉，现在采用的设计是全“拉”的方式来发送信息。这样处理的优点是异常处理简单，没有发送成功的信息会一直出现在待发送列表里，没超时的话网关一直拉就好了。缺点则是时效性差，现有设置每2分钟轮询一次，一条信息从建立到发送最长可能需要4分钟。不过对于现有业务（短彩信群发），时效性要求不是那么高，也就可以接受了。另外，采用拉的方式对服务器的资源存在某种意义上的牺牲，不是每次轮询都有待处理结果的，对于没有结果的轮询，算不算另一种浪费？
而采用“推”的方式发送信息，优点是时效性好，资源消耗小。服务器只用保持一个跟客户端的长连接，即可啥也不干，等着请求过来再处理。缺点是异常较为复杂，只有一次性的请求，如果失败了如何进行“重发”、“补发”就成为处理的重点。
“推”的方式没用过，不过想象一下流程应该是这样的：
实际应用中，可以考虑“推”和“拉”结合的方式。
不过像微博这种，用轮询的话会不会消耗很大呢？不懂。。。
永久链接：https://dylanvivi.github.com/posts/Learning-About-Comet-polling.html