一步一步开始做。

附录：

一套开源协议：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来划分）到这个用户所在的归属位置寄存器，并从该寄存器取得用户信息，然后保存在与这个服务器相关联的拜访位置寄存器中。

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

大概的流程：
1、用户登录，登录及会话服务器验证登录并生成会话，同时分配聊天服务器给窗户端，同时更新好友列表与状态相关信息，和客户端相关信息。
2、客户端拿到会话令牌和分配得到的聊天服务器的信息，连接聊天服务器，聊天服务器到会话服务器进行验证，验证通过后与客户端建立会话，开始聊天。
3、如果对聊天消息不做检查的话，直接走P2P的流程进行聊天，当然如果需要对聊天消息做处理的话就需要走消息中转服务器，如果同服务器的不需要走，不同服务器的走中转服务器进行中转。
4、对于离线消息直接存储到内存队列或者文本DB中，不同服务器间走中转服务器进行中转。
5、对聊天服务器做分配，做负载均衡时需要考虑结点的添加与删除相关发布式实现的常见问题。

个人觉得如果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 架构的考虑，是整体性的考虑，关键问题是你想支持多大的用户并发，多大的用户存储空间，想给用户提供什么样的服务。
是什么规模的集群，楼主可以先考虑一下。
因为大规模和小规模差别太大了。