集群的使用范围

　　集群是中间件厂商经常热捧的一个概念，说只有采取集群策略你的应用系统的性能才能提高。不明就里的用户在付出了数倍的价钱去购买集群设备和软件以后，却往往得不到所应该得到的效果。Apusic作为一家负责任的公司，应当向大家来澄清所谓的“集群悖论”。所谓集群，只有在细粒度计算中其效果才会明显，也就是将计算过程以一定的并行算法进行细分，将计算分布到多个处理机运行，最后再将计算结果合并。有一个很有名计划叫做SETI@home，是一项利用全球联网的闲置计算机共同搜索地外文明的科学实验计划，只需要下载一个小程序就可以对从射点望远镜得到数据进行分析。这就是一个典型的细粒度计算，所有的参与计划的计算机并行地计算浩如烟海的庞大数据库中的一小段数据，再将计算的结果汇总，从而发现可能的智能信号。而反过来我们看到在J2EE应用中大多数计算都是粗粒度的，再加上事务处理需要在分布式计算中进行协调，更降低了集群的整体处理能力。因此集群并不是解决性能问题的最佳途径，在单机低并发的情况下如果你认为性能不理想，那么请不要指望集群能给你带来性能的提升，相反你会发现性能反而还会有所下降。

　　那么，集群仅是厂商宣传的噱头吗？在以下两种情况下集群是有用的：1. 高并发超负荷运行的主机，例如google这样的网站，它的访问量是相当大的，因此google会采取集群策略来分散客户的请求，以提高整体响应能力。我们接触的很多J2EE应用负荷量都不大，其实每秒访问量在500以下的应用都没有必要采取集群策略。2. 失效转移，其实我认为这才是集群真正有用的地方，使用一台低成本计算设备作为主设备的备份，在主设备发生故障时及时接替，以保证7x24小时不间断服务。综上所述，在准备采用集群之前，一定要仔细分析具体的应用环境，以避免不必要的浪费。作为一种选择，Apusic同样实现了集群技术，但我们并没有沿用大多数应用服务器厂商所采取的内存复制技术（in-memory replication），我们知道在集群中需要在各结点之间同步一些状态信息，如果采用内存复制技术，将耗费大量的网络带宽，对性能也有很大影响。这是因为每当一个结点的状态发生变化时，都需要通过多播等方式向其他结点传递状态信息，随着集群内部结点的增多，内存复制将会非常频繁，从而造成广播风暴，严重阻塞带宽。Apusic所采取的技术是客户端缓存，即直接将状态信息保存在客户端，当服务器失效时将状态转移到可用服务器。