IM解决方案

  曾今做过web im ，总结下目前我所了解到的web im解决方案。做 web im ，有2个难题，一个是http长链接，一个是服务端，互相搭配起来也很多，比如：

 

1.pushlet + map pushlet基于事件模式的，是个js库，这个我架了个demo，感觉深入比较复杂，当时略过。服务端就是自己搞个线程安全的map处理业务逻辑，主要是发消息，所有在线人员

 

2. dwr ，服务端和上面的类似。只是长链接是dwr做的。

 

3. flash 的 xmlsocket + mina ，基于 flash的，我当时还做了个demo，后来因为考虑浏览器支持放弃了。

 

以上1和2方案，我认识的有几个目前还在这么做，特别是企业系统的，也是09年左右用的最多的方案。

 

3. dwr + openfire 这个是我去年做webim提出的一个解决方案，将dwr的 scriptsessionid和 openfire的监听器绑定，当onMessage的时候就推消息。当时最多差不多有个1000人聊天，dwr可以HOLD住，后来也不知道有多高了。

 

4.自己用多线程写长链接 + openfire，这是去年项目里面替换dwr的方案，由一位同事写的，还是比较猛的。

当时pv 4W，还是很稳定的。其实发现openfire还是很能抗的，他一般不会出啥问题。

 

5. servlet3.0 + jms  这个服务端变成了 jms，利用发布，订阅帮我们处理转发，servlet3.0来长链接。

 

6. servlet3.0(springmvc) 去年这个时候springmvc3.2打算封装servlet3.0，有个DeferredResult

根据官方的demo，这个DeferredResult，是这个意思，比如A发起一次长链接，就创建一个，放到一个map，里面。这个时候B发消息给A，B从map里面get到A对应的DeferredResult，然后给他setResult，那么A马上收到消息。然后A再回调下，从map移除

deferredResult.onCompletion(new Runnable() {

@Override

public void run() {

System.err.println("onCompletion");

rs.remove(deferredResult);

}

 

});

如果再让我做webim，我会考虑这个方案，再和openfire结合起来，现在都过去几年了servlet3.0的容器也越来越成熟了。

 

6. websotck 系 /nodejs/ stock.io 去年调研im的时候看到过nodejs这个新东西，发现很猛，但是基于webstock直接放弃了，后来才知道Socket.IO这个东西会跨浏览器，如果没有html5支持就用flash的。

 

 

7. Python 系  Tornado ，这个facebook出品，号称直接秒杀1W并发高性能框架，在异步IO相当之给力，如果我再拾Python，这个会优先考虑。

 

总体看来还是web的长链接和服务端，而且随着技术的更新，方案是越来越多，绝不限于上面的，不过有

一点需提醒，如果想支持比较多的用户，需要发挥的好才行。 其他一些具体的技术细节，等以后有时间了补上。