openfire中的集群技术及其原理

对即时聊天了解的可能会听说过openfire，openfire是基于JAVA语言的开源项目，主要是利用XMPP协议进行通信，今天主要探讨下其集群技术。

openfire采用了一个半开源的集群项目Hazelcast，像Mysql一样，有个功能不完全的开源版，而其功能完全的商业版则是要收费的。

通过对Hazelcast的使用和源码解读，我总结出了一些关于集群方面的个人思考。对于集群中各结点间无关联的可能只要通过增加机器就可以了，

但是对于即时通讯来说却不行，因为要共享用户的Session，所以就会有集群的数据共享问题，如何处理才能让其可以最大规模的拓展成为我们

重要难题，而今天的Hazelcast只是解决中小规模（官方说最大数百台）集群的一种技术方案，对于大规模的集群就重新选择了。

目前集群的网络架构设计可以分为中心管理型和对等型，所谓的中心管理型就是有负责管理集群中各结点的，比如Zookepper就可以充当这个角色，

而中心结点则不负责处理任何业务，只做管理元数据，使用过MongoDB的人应该能想到起的config进程其实也是这个角色，而所谓的对等型的网络，

其实里面也有个充当中心管理角色的结点，只不过它还要处理业务逻辑。Hazelcast就是一个看似对等的一个部署方案，它的中心角色对使用的程序

员来说是透明的，接下来我先说下它集群的创建过程，通过我画的这个流程图应该能理解一些。

也就是说它内部有个选举算法来决定哪个结点作为管理结点，在Hazelcast里又叫oldest结点，oldest结点负责接收加入请求并处理联合（Join）。

下图是我画的一个帮助理解集群联合过程的草图：

集群创建完后会有一人容器存放所有的集群结点信息，主要包括是否是本地local，地址address(IP，Port)，UUID唯一编号等等。

说到这里我要说个插曲，对于这个存放集群结点信息的容器，使用了可重入锁技术（ReentrantLock   try前lock，finally里unlock）。

当然，除了用于管理集群中的结点的容器外，Hazelcast还提供了几个集群的数据共享容器，像Queue和Map，那可能会有人问这

些容器里的数据是怎么存的呢？是每个结点都放所有的，还是每个结点都只存各自的数据呢？如果每个结点都存放所有的数据，那

么当集群中结点数量越来越多后，各结点数据的同步还能很好进行么？而且冗余数据也会非常多。如果每台只存放各自的，如果这台

机器宕机了，共享的数据怎么办呢？带着这些疑问我接着看Hazelcast的源码，发现原来它是第三种相法，就是先把所有数据汇总，

由它来决定哪个结点存放哪些数据，一般每份数据会有两个备份，存放在不同的三台机器里，而每个结点会有一个Nearcache，充当

本地缓存。这个对使用它的程序员来说也是透明的，这样问题就集中在当结点变多时如何同步这些数据上了，其实这也是Hazelcast和

其他一些集群技术的难题，既要实时又要性能，这个难题大家可以一起思考，期待能有更多更好的大规模集群技术出现。

另外Hazelcast还有个监控集群的后台，原理也很简单，感兴趣的用一用就明的了，不过它是商业版里的部分，要想用的也很简单，反编译

它的class文，里面有个生成licence的类，它没有联网校验功能，只要licence就可以了，不过还是要尊重版权的。