java集群技术面试的一些知识准备

转载自：http://www.jfox.info/java-ji-qun-ji-shu-mian-shi-de-yi-xie-zhi-shi-zhun-bei

java集群技术面试的一些知识准备

一个集群系统是一群松散结合的服务器组，形成一个虚拟的服务器，为客户端用户提供统一的服务。对于这个客户端来说，通常在访问集群系统时不会意识到它的服务是由具体的哪一台服务器提供。

集群的目的，是为实现负载均衡（Load Balancing）、容错（Fault Tolerance）和灾难恢复（Failover）。以达到系统可用性（High Availability）和可伸缩性（Scalability）的要求。

集群系统一般应具高可用性、可伸缩性、负载均衡、故障恢复和可维护性等特殊性能。

越来越多的关键任务和大型应用正运行在J2EE平台上，象银行之类的应用要求很高的可用性(HA)，大型系统比如大型网站则要求更好的伸缩性。

容错(fault tolerance)

高可用环境下的数据不见得肯定是正确的数据。在Java EE集群中，当一个服务器实例宕机(以后统称“失败”)后，服务通过集群中别的服务器依然可用。但是在失败的那台服务器中正在处理的请求也许就不能获取正 确的数据了。所以，容错技术可始终保证在特定的错误环境下也能执行正确的行为。

失败转移(Failover)

失败转移是集群当中的另一项实现容错的重要技术。失败转移通过在集群中选择另一节点，将能延续失败节点上的服务。失败转移可通过代码指定或者自动通过底层平台的通信链路进行自动切换。

幂等方法(Idempotent methods)

幂 等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例 如，“getUsername()”函数就是一个幂等函数，“deleteFile()”函数就不是。“幂等”是HTTP Session和EJB失败转移中的一个重要概念。

集群层次说明

1、Web级集群，是J2EE集群中最重要和基础的功能。web层集群技术包括：Web负载均衡和HTTPSession失效转移。

web负载均衡，基本的是在浏览器和web服务器之间放置负载均衡器。

2、应用级集群，是ejb集群，EJB是J2EE应用平台的核心，EJB是用于开发和部署具多层结构的、分布式的、面向对象的Java应用系统跨平台的构件体系结构。主要是业务应用，部署在EJB容器上。

3、数据库级集群，比如在oracle数据库设置多个数据库实例，全部映射到数据库。

可扩展性(scalability)

在一些大规模的系统中，不太好预估确切的在线用户数和他们的行为。可扩展性即指系统能够支撑用户数量激增的情况。立马能想到的提高可扩展性(在线并发会话)的办法是在服务器上增加资源(内存、CPU……)。集群技术是解决这个问题的另一途径。集群支持一组服务器从逻辑上作为单独的服务器运行，但共同分担系统负载。

高可用性(high availability)

采用单一服务器解决方案(增加内存、CPU等)来解决可扩展性的问题并非完美，因为系统失败集中于一点(单一服务器)上。任务关键型的应用(银行的或者是计费系统)不能容忍哪怕只有一分钟的宕机。所以需要这些服务在任何时刻都必须可以访问。集群技术是达到这类高可用要求的解决方案，它通过在集群中提供附加的服务器来保证一旦其中的某个服务器宕机时服务的延续性。

负载均衡(load balance)

负载均衡是集群技术中重要的一部分。通过将请求分发到不同的服务器，它提供了可同时获得高可用性和更高性能的服务的方法。简单的负载均衡器可以是一个Servlet或一些插件，复杂的负载均衡器可能是高级的嵌入了SSL加速器的硬件设备。

除了分发请求之外，负载均衡器还负责执行一些重要的任务：

1、 “会话持久”用来确保用户会话生命周期在一台服务器上的完整性。

2、 “心跳”来检查失败的服务器。

3、 在某些情况下，负载均衡器需要参与“失败转移”的过程，下文中会提及。

Web层集群实现

Web层的集群技术是Java EE集群技术中最基础且最重要的部分。Web集群技术包括：Web负载均衡与HTTPSession失败转移。

Web负载均衡

Java EE的供应商通过多种方式实现Web负载均衡。总的来说，负载均衡器在浏览器和Web服务器之间进行监听，如下图：

诸如F5负载均衡器这样的硬件产品可以担当这个工作，也有可能是一个有负载均衡插件的另一个Web服务器。无论使用什么技术，负载均衡器通常具有以下特点：

实现了负载均衡的算法

当客户端请求到来时，负载均衡器决定将此请求分发到后端的哪台服务器实例上。经常使用的算法包括轮询、随机和基于权重的算法。负载均衡器试图均衡每个服务器实例上的工作负载，但上述算法都不可能真正实现理想的均衡，因为他们仅仅考虑到了分发到特定服务器实例的请求数量。使用复杂算法的负载均衡器通过特殊算法在分发请求之前将探测每台服务器的工作负载。

心跳线检查

当某个服务器实例失败时，负载均衡器需要检测到该失败并取消分发到该实例的请求。负载均衡器也需要监控失败的服务器何时重新开始服务，并开始对其分发请求。

会话持久

几乎所有的Web应用都使用会话状态来记录诸如登录、购物车等信息。因为HTTP协议本身是无状态的，会话状态需要保存起来并与浏览器会话关联。在负载均衡的状态下，最佳选择是将请求分发到与该浏览器会话的上次请求同一的服务器实例上。否则，可能会导致应用工作不正确。

因为会话状态是在Web服务器实例的内存空间中存储的，所以“会话持久”就相当重要了。但当一个服务器实例失败后，所有该实例中的会话信息就会丢失。所以，我们即需要会话的失败转移。

HTTPSession失败转移

主流的Java EE供应商都实现了HTTPSession失败转移。当浏览器在访问有状态的Web应用时，在该服务器的内存中会创建会话对象。与此同时将能唯一确定会话对象的HTTPSession ID发送至浏览器。浏览器将该ID作为cookie存储，并在下次请求该Web应用时将此cookie发送至Web服务器。

为了支持会话失败转移，Web服务器中的会话对象将被备份下来，以备服务器失败时防止会话信息丢失。负载均衡器将检测到实例的失败，并将后续请求分发到其他服务器实例上。由于会话对象已经被备份下来了，处理请求的新服务器实例就能恢复该会话的信息，继续正确处理会话。

要实现上述功能，需要引入以下内容：

全局HTTPSession ID

上面已经讲过，HTTPSession ID用来标识特定服务器实例中的内存会话对象。在Java EE中，HTTPSession ID根据JVM实例来产生。每个JVM实例能驻留多个Web应用，每个应用能为不同的用户保存HTTPSession。HTTPSession ID是在当前JVM实例中访问相关会话对象的关键。在会话失败转移的实现中，不同的JVM实例不能生成相同的HTTPSession ID。如若不然，在失败转移发生时，就不知道哪个对象是应该恢复的对象。所以，需要引入全局HTTPSession ID机制。

备份会话状态的机制

后续的描述中会有这方面的内容。将来我还着手写一片比较各主流服务器中会话备份机制的具体实现的文章。

备份频率和粒度

HTTPSession状态的备份会造成额外开销，比如CPU时间周期、网络带宽和磁盘或数据库I/O。备份操作的频率和粒度的选择都可能影响集群的性能。

数据库持久化办法

一些的Java EE集群产品都支持使用JDBC通过关系型数据库备份会话状态。让服务器实例序列化会话内容并在适当的时候将他们保存在数据库中。当失败转移发生时，另一可用的服务器实例接管失败的服务器实例，并从数据库中恢复所有的会话状态。对象的序列化是其中的一个关键点，这样内存中的会话数据就可以得到持久化并可进行移植。

通常，执行数据库的事务会造成一些额外的开销，所以本方法的主要缺陷在于当并发数据量较大时可能无法提供需要的可扩展性。大部分采用数据库会话持久化方法的应用服务器供应商都建议尽量减少HTTPSession存储的对象，但这又可能影响到web应用的架构和设计，尤其是在需要使用HTTPSession存储用户数据的时候。

采用数据库持久化方法的优点在于：

易于实现。

由于数据库对集群中的所有节点都共享，所以，可以实现对会话数据的失败转移。

即使在集群的所有节点都瘫痪的情况下，会话数据依然能够得到保留。

内存复制办法

Tomcat、JBoss、WebLogic、Websphere之流的Java EE服务器都提供了另一种实现：内存复制。

在上图中描述了使用内存复制技术来实现会话状态备份的场景。本方法的性能很好。之余数据库持久化技术，在原服务器和一台或多台备份服务器之间进行直接内存复制对网络通信的影响很小。但是，不同厂商的服务器对内存复制技术的应用方式不同(在下面有具体描述)，有的厂商采用的技术就不再需要“恢复”的过程了，即会话数据备份时已驻留在备份服务器的内存中，当备份服务器接管时，所有的数据已经存在。