OpenFire源码学习之二十三：关于消息的优化处理

消息处理

之前有说过，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方法。该方法判断用户的可效行。禁用这个方法则可。

源码如下：

    public LockOutFlag getDisabledStatus(String username) {
        if (username == null) {
            throw new UnsupportedOperationException("Null username not allowed!");