系统通知、 聊天服务的实现

用户信息用user1@ip1, user2@ip2表示。   后面的消息存储db是公共的。

1）用户登录时主动拉取信息， server将该用户的离线信息发给用户

2）同server中， 不同用户传递消息时， server将收到的其他用户发来的消息直接存储并发给该目标用户、无需判断发送是否成功。 不成功则表示用户连接异常了， 下次再连上时，目标用户能主动拉取到。【保证了任何情况下不会丢掉消息】

3）user1通过server1转发给server2的user2时，server1收到时即存储， 然后server1转发给server2； 如果转发成功，则由server2执行步骤2负责最终的投递；server2投递成功，user2就能看到最新；否则user2离线、下次再登陆依然能看到。【也保证了任何情况下不会丢掉消息】

这种要求server之间能全互通、且全互连接了。 不支持server之间的多次relay、不支持第三方server。

可能问题：

1） 写可能成为瓶颈。在db前端加cache、数据慢慢由cache写到db中； 查询时合并db结果和cache结果。

2）群聊、群通知（几十、几百的规模）。server逐个给群中每个人发、或者发给其他server转发。【信息的存储是以群为单位】

3）全服系统通知（几万、几十万规模、或者腾讯几亿规模？ 几亿也是分解到了一个服务器能支撑的量， 约几w或者几千！！）：可以短时间内全部逐个发、或者分时发减慢影响。 全服系统通知可以使用内存存放，整个就没多少数据。避免后端db的查询。【信息的存储以全服为单位、独此一份】

4）有时序问题？ server2收到消息msg1，查询知user2未上线，准备写db/cache； 写之前user2上线了并主动获取离线消息、但得到的是不包含msg1的离线消息。 msg1在这次登陆中被漏掉了。？  server先写cache/db， 再判断是否用户在线而发送；这样OK。

5）有可能有多次relay的需求？   或者relay之后的server也有存储的需求？  cache只是减少写压力； 读依赖于mysql本身的缓存机制。

每个模块负责自己的事情、把自己的事情做好， 能够向外承诺模块自己的责任； 模块也能信任其他模块声称的职能。

模块间的功能和职责划分明确， 否则模块之间互相不能信任，考虑的东西太多太复杂， 无法达成简洁、清晰的设计。

略 仿xmpp

http://wiki.jabbercn.org/Jabberd2:%E5%AE%89%E8%A3%85%E5%92%8C%E7%AE%A1%E7%90%86%E6%8C%87%E5%8D%97

https://github.com/jabberd2/jabberd2

http://zh.wikipedia.org/wiki/XMPP%E5%8D%94%E8%AD%B0%E4%BC%BA%E6%9C%8D%E5%99%A8%E8%BB%9F%E9%AB%94%E5%88%97%E8%A1%A8