linux下IM server搭建

一步一步开始作。

附录：

一套开源协议：http://www.igniterealtime.org/index.jsp

Proso：http://prosody.im/

那谁网友的笔记http://www.cppblog.com/converse/archive/2009/01/13/71902.html

网友的一些观点：

msn是用几个不一样的服务器分别运行的不一样的服务。好比最前端专门作单点登陆。一台作用户列表的管理。再一台专门负责通讯。相似如此。
还有是服务器群集的技术，我也不是很了解。高手补充下。

定时发送其实很简单，将待发送数据排程便可。好比，用户但愿“一个月后”发送该消息，那么就将该消息和“请求时间+一个月”的时间存放入数据库。——这是进入队列过程。

出队过程就是，将消息按发送时间前后排序，将全部“时间到”的消息发送出去，并根据“最近一条消息时间”安排下次发送便可。

具体架构偶也不是很清晰，不过建议使用RPC中间件。Ice有个Strome就是用于 发布/订阅 模型的，一我的订阅的就是“与他有关”的全部消息，而每一个用户能够“发布”消息到好友 或者 聊天室(群)里面，这样就完成了一个基础的IM架构了。分布式的话，设计服务器间同步的接口，而后将用户像撒豆子同样交给各个服务器(经过HASH算法和登入服务器接口)，每一个用户的消息一定是须要交给一个或多个其它用户的，那么消息就有了“目的地”，根据“豆子们”所在的服务器做为“跳跃门”将消息丢过去，该服务器再根据客户状态要么暂存要么交给客户就行了。

难点有下面两点：

1.用户上下线消息的处理。
  不一样的用户分布式策略决定了用户上下线消息的处理。

2.DB的分布式策略
  在同时在线 10万用户的系统里面单数据库显然没法知足需求，
  分布式的数据库策略或者大量的memory cache是个解决方案。

我之前作过一段时间电信，我以为IM和移动的原理差很少，能够考虑用移动网的架构。

关于DB分布，能够考虑引入两个概念，一个叫归属位置寄存器，另一个叫拜访位置寄存器。

归属位置寄存器存放用户的原始资料信息，包括用户名和密码。当一个用户在某个服务器上登录时，服务器根据特定的规则定位（好比依据ID来划分）到这个用户所在的归属位置寄存器，并从该寄存器取得用户信息，而后保存在与这个服务器相关联的拜访位置寄存器中。

我以为应当包含如下几部分:
一、好友列表、状态维护服务器，用记好友列表的读取以及状态更新等，这一块的实现应当比较复杂，发布式实现也较为麻烦。
二、登陆及会话分发服务器，用于用户登陆系统，会话实现以及分配聊天服务器。
三、聊天服务器，用户与该服务器直接链接进行，包括离线消息队列等都存储在该机器上。
四、聊天消息中转服务器，对于不一样的聊天服务器间消息的分发，牵涉到好友分组。

大概的流程：
一、用户登陆，登陆及会话服务器验证登陆并生成会话，同时分配聊天服务器给窗户端，同时更新好友列表与状态相关信息，和客户端相关信息。
二、客户端拿到会话令牌和分配获得的聊天服务器的信息，链接聊天服务器，聊天服务器到会话服务器进行验证，验证经过后与客户端创建会话，开始聊天。
三、若是对聊天消息不作检查的话，直接走P2P的流程进行聊天，固然若是须要对聊天消息作处理的话就须要走消息中转服务器，若是同服务器的不须要走，不一样服务器的走中转服务器进行中转。
四、对于离线消息直接存储到内存队列或者文本DB中，不一样服务器间走中转服务器进行中转。
五、对聊天服务器作分配，作负载均衡时须要考虑结点的添加与删除相关发布式实现的常见问题。

我的以为若是P2P应用得好和好友列表及状态维护上也实现得好，那么IM的架构应当是比较不错了的。

以上纯属我的猜测。你们继续！

好友状态能够用简单的Ping Pong机制来肯定，另外，我有想将服务器的所谓“中转网络”扩大到客户端的作法。这样，消息中转不必定须要走服务器，直接与客户端链接也能够。涉及到一个不复杂的节点算法流程，与KAD相似。

我以为不必定像移动网那么复杂，也不必定彻底照搬。 
粗略划分了一下： 
对于HLR（归属寄存器），保存账号的基本信息；基本上是静态数据，也应该包括用户 
最后一次登录时的服务器等少许的动态信息。 
对于VLR（拜访寄存器），能够用来保存离线消息这类的既时信息（其它用户给当前 
（不在线）用户发的消息）

呃……对了……有大量的基于Jabber的开源服务器能够参考。那些服务器大部分都实现了服务器间通讯，以及消息缓存等机制。

若是要现成的，
也许能够看看 ejabberd - Distributed, fault-tolerant Jabber/XMPP server
written in Erlang
http://www.process-one.net/en/projects/ejabberd/

ICE提供的功能也足够实现分布式IM了

im 最大的难点，就是一个定位 和查找的问题。

而最致命的问题，是不少账户可能不用
归属位置寄存器存放用户的原始资料信息，包括用户名和密码。

这种作法可能会有很是大的浪费。 可是设计合理仍是能够用的。

定位和查找，偶们常用的树形结构就颇有用。好比你打长途电话，若是跨市，就要拨打区号，若是跨国，就要拨打国际长途号码同样——用这种结构，咱们用一个目录，就能装下地球上全部人了。什么？你不在里面？抱歉，还米开通火星长途，请等待添加火星服务器……(后面只是玩笑~)

对于游戏im来讲还要考虑一帐户多脚色多点同登问题。最好是两层登陆

IM 架构的考虑，是总体性的考虑，关键问题是你想支持多大的用户并发，多大的用户存储空间，想给用户提供什么样的服务。
是什么规模的集群，楼主能够先考虑一下。
由于大规模和小规模差异太大了。