Java EE集群技术初探——第八部分(关于Java EE集群的误区)

 

关于 Java EE 集群的误区

 

失败转移能完全避免错误。 —— 否

在 JBoss 的文档中，我看见一段警告： “ 真的需要 HTTPSession 复制么？ ” 当然，有的时候不带失败转移的高可用解决方案是可接受，而且也很划算。而且，失败转移的功能并不像想象中的那样强大。

 

那到底失败转移能带来些什么呢？有的人认为失败转移能避免错误。事实上，如果没有失败转移，当服务器失败时会因会话数据的丢失产生错误；如果有会话失败转移的话，会话数据能被恢复到另外一台服务器实例中，客户端可能都没有察觉失败。这是真的，但绝对是有条件的！

 

回忆一下对 “ 失败转移 ” 的定义。失败转移的时机是 “ 介于方法调用之间的 ” 。这就意味着连续两次调用远程对象的方法，只有当第一个方法调用完毕且第二个调用请求还未送出时才可能发生失败转移。

 

所以，当正在进行方法调用的时候失败了怎么办呢？答案是：处理过程中止，客户端看见错误消息提示 ( 除非方法是幂等方法 ) 。只有方法是幂等方法的情况，一些负载均衡器才能试图失败转移这些方法到别的实例。

 

幂等为何如此重要？因为客户端并不知道服务器何时失败的 ( 在方法刚开始调用或者快要调用完成的时候 ) 。如果是非幂等方法，则两次调用就会两次改变系统状态，系统就会处于不一致的状态。

 

在复杂应用中，不太可能把所有的方法都变成幂等方法。所以，只能通过失败转移减少错误，而不可能从根本上避免错误。

 

 

未采用集群技术的应用能顺利地透明迁移至集群环境中。 —— 否

虽然一些厂商宣称其 Java EE 产品的灵活性，但是我奉劝大家不要相信他们。实际上，需要从一开始的设计阶段就考虑到集群的因素，并在开发和测试阶段去进行验证。

 

HTTPSession

在集群环境下，根据会话失败转移使用的机制，对 HTTPSession 有很多限制。首先就是限制在 HTTPSession 中存储的对象必须是可序列化的。有些 MVC 的框架使用 HTTPSession 存储一些非序列化对象 ( 如 Servlet 上下文、 Local EJB 接口和 web 服务的引用等等 ) ，那么这些框架就不能在集群环境下使用。其次，对象序列化和反序列化的过程对性能的开销很大，尤其是采用数据库持久化方法的时候。在这种情况下，应该避免存储大对象和存储的对象个数较多。如果使用的是内存复制的办法，那么必须注意 HTTPSession 中不能存在交叉引用的属性。还有就是必须使用 setAttribute() 方法对 HTTPSession 中的属性进行修改。

 

缓存 (Cache)

几乎所有的 Java EE 项目都使用缓存来改善性能，但这些缓存都是针对非集群环境设计的，只能在一个 JVM 实例上工作。需要缓存的原因是有的对象频繁创建，有的对象在创建时需要消耗大量资源，所以我们需要在缓存池中保存这些对象避免后续创建。使用缓存的根本原因是维护管理缓存的开销比创建新的对象划算。在集群环境下，每个 JVM 实例需要维护自己的缓存，还需要维护从别的服务器上同步过来的缓存，以便保证所有服务器实例的状态一致。有时，这种同步机制会带来更低的性能。

 

静态变量

一些设计模式，比如单实例模式将使用静态变量来共享多个对象的状态。在集群环境下，每个服务器实例需要保存自己的静态变量，这就打破了该模式的机制。比如用静态变量对在线用户数进行统计的情况。在集群环境下，这种用法将失败，在集群环境下，最好的办法是将数据存入数据库。

 

外部资源

很多系统都使用了外部 I/O 操作，比如上传或动态创建 XML 配置文件。在集群应用服务器中，没有办法跨服务器进行文件复制，所以只能通过数据库或外部文件的方法来解决。

 

特殊服务

比如计时器 ( 固定时间间隔触发任务 ) 之类的特殊服务很难在集群环境下运行。之类的例子还有邮件通知服务、在整个系统启动时的初始化服务等。

 

这些服务都是由时间触发的，而不是由请求触发的，而且只能执行一次。对他们进行负载均衡和失败转移意义不大。

 

有一些产品在这方面也做了一些工作，例如 JBoss 的 “ 集群下单模式工具 (clustered singleton facility)” 。

 

总结

集群与普通的环境不同， Java EE 的厂商实施集群的方法也不同。必须要认真考虑是否需要采用集群环境，并且认真选择相应的产品来支持集群环境的正常工作。