Openfire 是一个XMPP协议的IM Server。
Openfire使用mysql配合它不知所谓几乎无效的的Cache机制就注定无法支撑高并发，
所以第一步，将数据库切换为比较强一点的MongoDB。
但是MongoDB也是有问题的，在高并发时才会发现，MongoDB的锁表十分严重，
经过调查发现，MongoDB也比较坑爹，他是使用“全局锁”的，也就是说，你更新A表的时候，会锁住B表，数据更新后解锁。
所以作为实时查询数据库即使是使用MongoDB的master/slave模式依然不能胜任。
增加解决方案，缓存层，使用redis作为MongoDB的数据缓存，在访问时数据时，首先进入Cache层访问redis，如果没有，再去访问MongoDB，然后再回头填充Redis。
OK，数据源解决了，接下来确认需要在什么地方切入。
1，首先是将用户信息数据切换到MongoDB中。并停止Openfire自己的Roster服务，在管理控制台设置 xmpp.client.roster.active = false
2，AuthProvider，这里是登陆模块，可以继承接口重写一个属于自己的Provider。
重写authenticate方法，将登陆验证请求交给cache层。
3，离线信息的存储在之后也会成为负担，那么继承OfflineMessageStore类，重写属于自己的离线信息策略，将离线信息保存到Redis中。
4，重写状态更新的广播：PresenceUpdateHandler中的broadcastUpdate方法。
好了，这时候Openfire已经被修改的面目全非，但是效率已经不可同日而语了。
这时候还有一个问题，就是Openfire没有消息保障机制，也就是说，网络不稳定的时候，客户端异常断线，信息就会发送到空气中，
需要再发送信息的时候实现“握手机制”来保障信息的可靠性。不细说了，自己百度。
这时候Openfire的在线用户可以飚到6W无压力，但是死活上不去了，又被限制了。
在error.log中会发现类似 “open files too larger” 一类的错误，这些是linux系统参数：最大文件打开数。
在linux下执行ulimit -a就能观察最大的文件打开数，执行ulimit -n 350000设置为35万，然后kill掉openfire退出控制台，重新连接控制台使其生效，重新启动Openfire。
好吧，这时候用户量可以飙6W以上了。
XMPP服务器的测试工具，比较简单的可以使用tsung来实现，简单的配置，模拟成千上万的用户登陆，并且可以模拟HTTP等其他请求。
接下来就是单台服务器容量的问题了，我们服务器是Dell R710， 64G内存 16核CPU，15000转硬盘。
服务器在这种架构下在线用户数据在29W左右，几乎已经是单台Openfire封顶了。
开始考虑集群，不过Openfire的几种集群都测试过，效果不理想，有一个神马war包的插件，弄上去时好时坏，放弃。
还有一个oracle的集群插件，不过在高压下多台Openfire直接脱离集群，自己玩自己的了。。。日。
如果到了十万二十万左右的在线用户级别，就放弃掉Openfire，可以尝试使用tigase试试，或者和我们一样，自己写通讯服务器。