构建可扩展的Java EE应用（二） - 编程入门网

Figure 5: collocated structure

结果表明collocated式的部署方式比分布式的方式更具备可扩展性。假设你应 用中的一个方法调用了一堆的EJB，如果每个EJB的调用都需要load balance，那 么有可能会因为需要分散到不同的服务器上进行调用导致你的应用崩溃，这样的 结果就是，你可能做了很多次无谓的跨服务器的调用。来看更糟糕的情况，如果 你的方法是需要事务的，那么这个事务就必须跨越多个服务器，而这对于性能是 会产生很大的损害的。

构建可扩展的Java EE应用（二）(3)

共享资源和服务

对于用于支撑并发请求的Java EE集群系统而言，其扩展后的性能取决于对于 那些不支持线性扩展的共享资源的操作。数据库服务器、JNDI树、LDAP服务器以 及外部的文件系统都有可能被集群中的节点共享。

尽管Java EE规范中并不推荐，但为了实现各种目标，通常都会采用外部的I/O 操作。例如，在我们实验室测试的应用中有用文件系统来保存用户上传的文件的 应用，或动态的创建xml配置文件的应用。在集群内，应用服务器节点必须想办法 来复制这些文件到其他的节点，但这样做是不利于扩展的。随着越来越多节点的 加入，节点间的文件复制会占用所有的网络带宽和消耗大量的CPU资源。在集群中 要达到这样的目标，可以采用数据库来替代外部文件，或采用SAN作为文件的集中 存储，另外一个可选的方案是采用高效的分布式文件系统，例如Hadoop DFS (http://wiki.apache.org/hadoop/)。

在集群环境中共享服务很常见，这些服务不会部署到集群的每个节点，而是部 署在专门的服务器节点上，例如分布式的日志服务或时间服务。分布式锁管理器 (DLM)来管理集群中的应用对这些共享服务的同步访问，即使在网络延时和系统处 理失败的情况下，锁管理器也必须正常操作。举例来说，在我们的实验室中测试 的一个ERP系统就碰到了这样的问题，他们写了自己的DLM系统，最终发现当集群 中持有锁的节点失败时，他们的lock system将会永远的持有锁。

分布式缓存

我所碰到过的几乎所有的Java EE项目都采用了对象缓存来提升性能，同样所 有流行的应用服务器也都提供了不同级别的缓存来加速应用。但有些缓存是为单 一运行的环境而设计的，并且只能在单JVM实例中正常的运行。由于有些对象的创 建需要耗费大量的资源，我们需要缓存，因此我们维护对象池来缓存对象的实例 。如果获取维护缓存较之创建对象而言更划算，那么我们就提升了系统的性能。 在集群环境中，每个jvm实例维护着自己的缓存，为了保持集群中所有服务器状态 的一致，这些缓存对象需要进行同步。有些时候这样的同步机制有可能会比不采 用缓存的性能还差，对于整个集群的扩展能力而言，一个可扩展的分布式缓存系 统是非常重要的。

如今很多分布式缓存相关的开源java产品已经非常流行，在我们实验室中有如 下的一些测试：

1个基于JBoss Cache的项目的测试；

3个基于Terracotta的项目的测试；

9个基于memcached的项目的测试；

测试结果表明Terracotta可以很好的扩展到10个节点，并且在不超过5个节点 时拥有很高的性能，但memcached则在超过20个服务器节点时会扩展的非常好。

Memcached

Memcached是一个高性能的分布式对象缓存系统，经常被用于降低数据库load ，同时提升动态web应用的速度。Memcached的奇妙之处在于它的两阶段hash的方 法，它通过一个巨大的hash表来查找key = value对，给它一个key，就可以set或 get数据了。当进行一次memcached查询时，首先客户端将会根据整个服务器的列 表来对key进行 hash，在找到一台服务器后，客户端就发送请求，服务器端在接 收到请求后通过对key再做一次内部的hash，从而查找到实际的数据项。当处理巨 大的系统时，最大

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!