消息处理
之前有说过,openfire的消息处理策略本人并不是很喜欢。先看下openfire上脱机消息策略。
个人认为消息关于会话的消息,用户的存储量应该无限大。服务器不应该被消息吃撑了。所谓聊天通讯,这一关很重要。
Openfire的消息是什么流程呢。
1、当用户登陆连接的时候。握手、认证、绑定资源、获取花名册、获取离线消息。
2、服务端会查找关系型数据库。经本人测试离线消息在数据库表中达到100万条以上的时候,查询速度非常慢,甚至会导致openfire奔溃。
.....
那么openfire在消息这块会有哪些不足之处呢。本人认为有一下几点:
1)用户登陆的时候需要验证用户的可效性。又一次需要查询数据库,而本人认为这一步没
必要。可以删掉
2)用户每次登陆都需要重新获取自己的好友花名册。这样导致数据访问次数过多,服务端
push消息的量也增多。导致登陆流程很慢
3)用户发送的消息,没有回执。就是说A发送消息给B。而B又一致不回复。所以对于客
户端A来讲压根不知道消息是否发送成。然而S(服务端)接收到A的消息转发给B的时
候,B也不做回执。所以S也不知道消息到底是否成功到达。
4)用户的离线消息表访问峰值时,系统可能会奔溃。
针对上面的问题,下面一一做解答。
用户校验
问题1:比较简单。在DefaultLockOutProvider中有一个getDisabledStatus方法。该方法判断用户的可效行。禁用这个方法则可。
源码如下:
用户数据同步
问题2:将用户花名册、group、MUC等相关信息预知Redis中。设置用户的数据版本标志。用户每次登陆后只需要跟服务端记录的用户版本进行匹配。版本一致的时候则不需要每次都要重新同步了。本人针对用户聊天室重新做了XMPP的拓展。
A.用户发送请求获取自己所拥有的房间:
B.服务端返回消息:
C.用户获取房间内成员:
D.服务端返回消息
下面代码主要描述服务端对用户聊天室请求的处理
这里回答了提出来的2点问题。第3、4个问下会在下面章节中回答