openfire im xmpp

一、 类加载器 　　　要深入理解openfire插件机制的内部原理，必须要深入了解一下java的类加载器。类加载器作用是加载 Java 类到 Java 虚拟机中。 　　　加载过程如下：Java 源程序编译后转换成 Java 字节码（.class），类加载器负责读取 字节码，并转换成java.lang.Class类的一个实例。 　　　 系统提供的类加载器有： 　　　　１、引导类加载器（bootstrap class loader） 　　　　　　jvm内置的加载器，是用C++实现的。 　　　　　　引导类加载器的加载路径，由系统属性sun.boot.class.path来指定，它的默认值指向jre的classes目录，及lib目录下rt.jar等几个jar文件。 　　　　　　可通过-Dsun.boot.class.path来手工指定，也可通过-Xbootclasspath等属性来指定。 　　　　２、扩展类加载器（extensions class loader） 　　　　　　类加载路径由java.ext.dirs来确定，java.ext.dirs属性值指向一个或多个目录，默认jre/lib/ext，加载 Java 的扩展库$java_home/jre/ext/*.jar。 　　　　３、应用类加载器（application class loader） 　　　主要负责加载java

Openfire 是一个XMPP协议的IM Server。 基于MINA的java nio服务器。 一般就是使用mysql来作为数据库，保存配置配置信息、离线信息、用户数据。 官网的数据是支持5000人同时在线，使用connectionManager可以实现支持3.3万人在线。 这数据一点都不漂亮，只能作为一个类似腾讯通的局域网聊天工具使用。 首先说点题外话，我测试用connectionManager。 这是一个openfire提供的连接管理器，作用其实是数据整流。 源码里是通过阻塞式多线程将信息通过特定端口与openfire提交数据。 测试之后的结果，这玩意严重影响效率，放弃，我们的目标不只是3.3万人。 Openfire使用mysql配合它不知所谓几乎无效的的Cache机制就注定无法支撑高并发， 所以第一步，将数据库切换为比较强一点的MongoDB。 但是MongoDB也是有问题的，在高并发时才会发现，MongoDB的锁表十分严重， 经过调查发现，MongoDB也比较坑爹，他是使用“全局锁”的，也就是说，你更新A表的时候，会锁住B表，数据更新后解锁。 所以作为实时查询数据库即使是使用MongoDB的master/slave模式依然不能胜任。 增加解决方案，缓存层，使用redis作为MongoDB的数据缓存，在访问时数据时，首先进入Cache层访问redis，如果没有