Java集群转发

  JAVA集群：一组相互独立、通过高速网络互联的计算机，他们组成了一个组，并以单一系统模式加以管理。

基本术语：

1.伸缩性

在一些大型的系统中，预测用户量和行为是非常困难的。伸缩性是指系统适应不断增长的用户量的能力，去适应一个增长的过程。提高这种并发会话能力最直接的方法就是提高cpu、内存、磁盘等。集群是解决这个问题的另外一种方法，它允许一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务。

2.高可用性

单一服务器解决方案不是一个健全的方式，因为如果出现了问题，可能会引起服务器挂掉或者死机等故障，在许多系统（类似银行、账单处理等）出现类似问题会造成很大影响。它们需要这样一些服务在任务时间都可以访问并在可预期的合理时间周期内进行响应。集群方案通过在集群中增加冗余的服务器，使得在其中一台服务器失效后仍能提供服务。

3.负载均衡

负载均衡是集群的一项关键技术，通过把请求分发给不同的服务器，从而获得高可用性和较好的性能。一个负载均衡器可以是一个servlet或Plug-Ins，到昂贵的内置SSL加速器的硬件。除此之外，负载均衡器还需执行一些其他的重要任务，比如“会话胶粘“让一个用户会话始终存在一个服务器上，”健康检查“用于防止将请求发送到已经失效的服务器上。有些负载均衡器也会参与我们下面将会谈到的”失效转移“过程。

4.容错

高可用性意味着对数据的正确性要求不那么高。在J2EE集群中，当一个服务器实例失效后，服务仍然是有效的，这是因为请求被冗余的服务器处理。但是当一个请求在一个正在失效的服务器中处理时，可能得到不正确的结果。不管有多少个错误，容错的服务器应当能确保有严格的正确行为。

5.失效转移

失效转移是集群中获取容错能力的另外一种关键技术，当一个节点失效后，通过选择集群中的另一个节点，处理将会继续而不会终止。转移到另一个节点可以被显示的编码，或者通过底层平台自动地透明的路由到另外一个服务器。

6.等幂方法

等幂方法是指这样一些方法：重复用相同的参数调用都能得到相同的结果。这些方法不会影响系统状态，可以重复调用而不用担心改变系统。

-----------------------J2EE集群-------------------------

J2EE集群技术包括：负载均衡、失效转移

负载均衡意味着有许多客户端向目标对象同时发送请求，而负载均衡器则是在调用者和被调用者之间，分发请求到冗余的对象中。（伸缩性、高可用性就是这样得到的）。如图：

失效转移 与负载均衡不同，有时客户端会连续发请求到目标对象，如果请求中间目标对象失效了，失效转移系统将检测到这次失败，并将请求重定向到另一个可以用的对象中，通过这种方式获得容错能力。

----------------------------- J2EE里面什么对象可以集群呢？在代码中哪里会发生负载均衡/失效转移?

实际上，不是所有的对象都可以集群，

并且负载均衡和失效转移不是在任何地方都能发生。

在J2EE平台上，分布式技术包括：JSP（Servlet）、JDBC、EJB、JNDI、JMS、WEB Service等。

负载均衡和失效转移就发生在这些分布式方法被调用时。（

可以在浏览器和WEB服务器之间实现负载均衡和失效转移的功能）

---------------------------------------------------Web层集群实现-------------------------------------------------------------------

Web层集群是J2EE集群的重要且基本的功能。

Web集群技术包括Web负载均衡和HTTP Session失效转移。

1.Web负载均衡：基本上都是在浏览器和Web服务器之间插入一个负载均衡器。

其中负载均衡器可以是一台硬件，如F5负载均衡器，

或仅仅是另一台有负载均衡Plug-Ins的Web服务器，

一个简单的带ipchains的linux box可以很好的实现负载均衡。

负载均衡器具有的特性：

-------------------------------------实现负载均衡算法：

当客户请求时，负载均衡需要决定将如何分发到后台服务器。

流行的算法是Round-Robin、Random和Weight Based。

负载均衡器尽力使每台服务器实例都获得相同的负载，不过上述算法仅仅是依据发送到服务器的请求个数去判断的。

一些精密的负载均衡器实现了特殊的算法，它会在分发请求之前去检测服务器的工作负载然后去执行操作。

-------------------------------------健康检测:

当一台服务器失效了，负载均衡器应当检测出来失效并不在将请求分发给这台服务器。

同样也要检测服务器是否恢复正常，并恢复分发请求。

-------------------------------------会话胶粘：

几乎所有的Web应用程序都会有会话状态，可能是简单的用户信息存储，

或者包含购物车信息等，因为HTTP本身是无状态的，

会话状态应当存储在服务器的某个地方并与你当前浏览会话相关联，

这样当你下次请求相同的Web程序的页面时就会很容易的重新获取。

当负载均衡时，最佳的选择就是将特定的浏览器会话分发到上次相同的服务器实例中，

否则应用程序可能不能正常工作。

因为会话状态存储在特定的Web服务器的内存中，“会话胶粘”对于负载均衡很重要。

但是，如果其中某台服务器因为某种原因失效了，那么这台服务器的会话状态将会丢失。

负载均衡器应当检测到这个失效并不在将请求分发给它，

但这些请求的会话状态都因为存放在失效的服务器中而丢失了所有的信息，

这样将会导致请求的错误。于是会话的失效转移产生了。

2.Http Session失效转移

几乎所有的J2EE都在它们的集群产品中实现了Http Session失效转移，

用来保障当某台服务器失效后会话状态不丢失，使得客户端请求能正常处理。

流程： 当浏览器访问有状态的Web应用程序，

这个应用程序可能在内存创建了会话对象用于保存信息以供后面请求使用，

同时，发给浏览器一个唯一的Http SesisonID用于标识这个会话对象，

浏览器把这个ID存放到COOKIE里面，再次请求同一个Web程序的时候就会带上这个id发送给服务器。

为了支持会话转移，Web服务器将在一定的时候把会话对象备份到其他地方以防止服务器失效之后会话信息丢失。

当负载均衡器检测到这个服务器失效之后，将后续的请求发送给装有同样应用程序的服务器中，

由于会话对象备份到了其他地方，所以这个服务器实例可以恢复会话正确的处理请求。如图：

Http Session失效转移将带来以下问题：

1.全局Http Session ID

在会话失效转移的实现过程中，要求不同的JVM不能产生相同的两个HTTPSESSION ID ，

这是因为当失效转移发生时，一个JVM的会话将要备份并恢复到另外一个中，这样，

必须建立全局HTTP Session ID产生机制。

2.如何备份会话状态

3.备份的频率和粒度（影响性能）

------------------------------------如何备份会话状态--------------------

1.数据库备份方式

2.内存复制方式-----通过Socket通信，把会话状态备份到备份服务器中。

备份后，所有会话数据都已经保存到了备份服务器的内存中，

所以不需要恢复备份那阶段，可以直接处理请求。

3.Tomcat方式，多服务器复制--------当一个服务器实例发生改变后，

将备份到所有的服务器上。当一台服务器失效后，负载均衡器可以选择任何一个服务器实例。

但是这种方式大大的降低了性能。

性能因素：一台WEB服务器可能运行着多个web应用，

他们中每个应用都可能被大量并发用户访问，并且都会铲平会话。然后所有会话都会备份，

这样性能就会是会话失效的重要因素了。

备份时机：

1.按WEB请求------请求结束后，发生响应之前备份数据。

这样保证备份的数据是最新的。

2.按固定时间间隔------------按一定得时间间隔去备份数据，

可能备份的数据不是最新的。但是性能会得到提高。

备份粒度：

1.整个会话---------每次都将保存整个会话信息。

2.修改过的会话----------当会话修改后，则备份整个会话。性能会好些。

3.修改过的属性----------仅仅保存被修改过的会话属性而不是整个会话。

总结：

集群与独立环境不同，J2EE供应商采用不同的方法来实现集群。

如果你的项目为做到高伸缩性而使用集群，你应该在你的项目开始的时候就做准备。

选择符合你的需求的正确的J2EE产品。选择正确的第三方软件和框架并确保它们能支持集群。

最后设计正确的架构使得能从集群中受益而不是受害。