新年开贴，对于IM在网络设计上的一些讨论。
自己对IM一直很感兴趣，但是工作上一直没有机会能够有个项目的机会。

最近一直在搜索相关的资料，wireshark抓包分析了目前公司的一个即时通讯（big ant，公司封了QQ，对这个也研究了一番）,网易POPO以及最近的QQ。 也对XMPP SIP的协议再详细的阅读和思考了一番。自己也有了一些想法，希望有兴趣的朋友积极参与交流。

观点1：使用现有开源项目可以有一时之快，但是当产品精细化或者深度挖掘时是否会有瓶颈？

网上开源的项目很多，仿佛也很诱人，但是在一些关键的难点上依旧存在问题，如果想加入自己的修改，就需要对开源项目深入了解，这样的投入可能会深不可测，会在后期形成一个很大的瓶颈。我也在关注杭州一些做即时通讯的公司招聘，往往需要了解开源项目，以及XMPP，大致清楚是选择了网上开源的项目基础上做开发。个人感觉是，杭州做即时通讯的小公司不少，但是做的突出，能做大企业项目的很少，或许是遇到了我前面讲的瓶颈。

观点2：使用短连接！
在我之前设计IM的网络模块时，首先考虑长连接，之前提到的big ant也是采用这样的方式，通过长连接加心跳包来维持每一个客户端的在线状况，但是这样会出现一个性能问题，对大量连接数管理很容易遇到瓶颈！big ant同事说，在大客户时也是遇到了这样的性能瓶颈。而QQ用自己的OICQ协议或者是网易POPO使用XMPP，基于HTTP或者HTTPS方式，采用短连接的方式，就可以大大的省去大量用户维持心跳的开销，而且HTTP也更加容易做分布式的部署。

观点3：大量用户的IM通讯背后是否依赖较高的数据库？
如果了解XMPP通讯的协议，应该知道，不同用户登陆的很有可能是不同服务器。比如A,B用户分别登陆S1，S2，那A向B发送的数据流过程，就是A-->S1-->S2--B.
S1-->S2的过程时就会进行数据库的查询，用户量大，对于数据库的操作要求就比较高。


仅仅是个人的一些观点，资深在这方便工作的朋友希望给予些经验分享，莫见笑。


[解决办法]
沙发 我也喜欢这个玩儿
[解决办法]
我最近也在研究这个 也设计了一个架构 等有时间发上了和大家讨论一下
[解决办法]
观点1：使用现有开源项目可以有一时之快，但是当产品精细化或者深度挖掘时是否会有瓶颈？
如果开源的都学不好，那自己做会是怎么情况？
观点2：使用短连接！
我记得我用QQ电脑管家查看过QQ的连接，好像是长链接，不知道有没有记错....
观点3：大量用户的IM通讯背后是否依赖较高的数据库？
数据库是必须的，大量用户采用分布式是常规手段！好像QQ也在用MYSQL.....
[解决办法]
短连接的话，容易出现多终端登录的情况啊
[解决办法]
通讯编程
[解决办法]

[解决办法]
这个还要考虑什么服务器集群，容错什么的，当一台服务器当掉以后，然后转移到其它服务器上，让用户感觉无影响
[解决办法]
东西一做大，什么问题都来了啊。。。
[解决办法]
1:肯定有瓶颈，否则大家都基于一套开源就好了，为什么要搞那么多
2:短连接就不要想了，根本不现实，但是呢一些应用可以采用，比如查找用户，获取一个人具体用户资料等
3:分布式数据库很常用了，技术也很成熟
[解决办法]
不熟此类，听听高见，学习学习。
[解决办法]
如果我来做，肯定还是要用数据库存东西的

数据库可以按全国区域划多几个 用户按特定规则分到不同数据库
[解决办法]
网上开源的项目很多，仿佛也很诱人，但是在一些关键的难点上依旧存在问题，如果想加入自己的修改，就需要对开源项目深入了解，这样的投入可能会深不可测，会在后期形成一个很大的瓶颈。我也在关注杭州一些做即时通讯的公司招聘，往往需要了解开源项目，以及XMPP，大致清楚是选择了网上开源的项目基础上做开发。个人感觉是，杭州做即时通讯的小公司不少，但是做的突出，能做大企业项目的很少，或许是遇到了我前面讲的瓶颈。

[解决办法]
网上开源的项目很多，仿佛也很诱人，但是在一些关键的难点上依旧存在问题，如果想加入自己的修改，就需要对开源项目深入了解，这样的投入可能会深不可测，会在后期形成一个很大的瓶颈。我也在关注杭州一些做即时通讯的公司招聘，往往需要了解开源项目，以及XMPP，大致清楚是选择了网上开源的项目基础上做开发。个人感觉是，杭州做即时通讯的小公司不少，但是做的突出，能做大企业项目的很少，或许是遇到了我前面讲的瓶颈。

[解决办法]

数据库可以按全国区域划多几个 用户按特定规则分到不同数据库
[解决办法]
俺不懂这个，持续关注该贴
[解决办法]

[解决办法]
1、除了少数几家有实力的公司，能够完全自己设计达到开源项目水平的几乎没有吧，既然水平不够为啥不参照开源的来做。
2、长连接对断线检测比较麻烦，针对IM应用，相比短链接并不一定能节约多少资源，那还不如Client周期性的和Server建立短链接，一次性交换需要接收和发送的数据。最早的QQ用的是UDP协议，后来因为防火墙的问题才转移到基于TCP的HTTP协议。不使用长连接的另一个重要原因在于，这不利于动态均衡负载的实现。
3、这个是最麻烦的一点，和整个服务器集群的部署结构是相辅相成的，涉及到各服务器角色分配、数据流向问题，消息转发可能根本就没用到数据库。

我猜想可以这样的，唯一的1台请求负载控制服务器负责将Client的连接请求重定向到N台前端服务器中，其中1台前端服务器接受连接请求、接收待发送消息、通过对应的缓存服务器中获取发给此Client的消息、发送待接收消息、关闭连接。前端服务器周期性的将接收到的消息打包传输给后台服务器，后台服务器根据内存数据库中的好友信息过滤非法消息、展开群消息到每个成员，然后周期性的将待发送消息打包推送给N个缓存服务器。

这样的话，就把SSL、解析、组包、连接处理、收发包的重任分散到了M台前端服务器，把实时消息查询的任务也分散到了N台缓存服务器，1台缓存服务器固定为M/N台前端服务器服务，而无法进行任务分解的后台服务器只进行批量数据的简单处理。从数据流上看，前端服务器到后台服务器、后台服务器到缓存服务器都是单向的，可以使用专用链路避免这两个主干数据流发生网络资源冲突。