号码携带集中管理系统的高可用技术应用

，负载均衡器也能够检测到，并且开始向它转发请求。

（4）会话粘滞

所有的Web应用都会有一些会话状态，比如号码携带系统中某个流程是否结束的信息，某条请求消息是否接收到对应的ACK信息或者响应信息等。因为HTTP协议本身是无状态的，所以会话状态就需要记录在某个地方，并且和客户端关联，以便于下次请求的时候能够很方便地取出来。当进行负载均衡的时候，对于某一个确定的会话来说，把请求转发到上一次它所请求到的服务器实例是一个很好的选择，否则的话，可能会导致应用不能正常工作。

因为一般来说会话状态是存储在某个Web服务器实例的内存中的，所以对于负载均衡器来说，“会话粘滞”的特征非常重要。但是，如果某个Web服务器由于某种原因失败，那么在这个服务器上的会话状态就会全部丢失。负载均衡器能够检测到这个错误并且不再把请求转发到这个服务器，但是由于会话状态的丢失，可能会引发其他错误。因此，负载均衡器必须还要有另一个重要功能“会话失败转移”。

（5）会话失败转移

会话失败转移的实现机制是在某个Web服务器在收到某个客户端请求后，将会话对象备份到某个地方，以保证服务器失败的时候会话状态不会丢失。

如何备份会话数据也有不同的方案，比较主流的方案包括数据库方案和内存复制方案。

数据库方案就是在合适的时间让Web服务器将会话数据存储到数据库中。当失败转移发生时，另外可用的Web服务器实例接替失败的服务器，从数据库中将会话状态恢复加载进来。数据库方案的优点是：

●易于实现。将请求处理和会话备份分离开来使得集群更健壮、更易于管理。

●即使整个集群都失败了，会话数据仍然可以保存下来，可以在系统重启时继续使用。

数据库事务的缺点是比较消耗资源，当会话中的数据量较大时就会受到性能的限制。

内存复制方案是在备用服务器的内存中保存会话信息，而不是在数据库中进行持久化。和数据库方案相比，这种方案的性能较高，在原始服务器和备份服务器之间直接进行网络通讯的消耗很小，这种方案节省了会话数据“恢复”的阶段，因为会话信息已经在备份服务器的内存中了。

3.4 应用服务器基于J2EE的方案

介绍应用服务器的集群方案之前，有必要介绍一下J2EE，因为J2EE已经是一个分布式企业级应用开发与部署的事实标准，应用服务器的集群方案实际上是基于J2EE的某些标准实现的。

在J2EE中，业务逻辑被封装成可复用的组件，组件在分布式服务器的组件容器中运行，容器间通过相关的协议进行通讯，实现组件间的相互调用。所以，我们看到的网络上客户端或者Web服务器和应用服务器之间的通信过程，在J2EE实现上是组件之间的调用或者是组建对容器服务的调用。这种调用在J2EE的规范中分为两个阶段，一是对JNDI服务器访问，获得要调用的EJB组件的代理（EJB Stub），二是对EJB组件的调用。

对JNDI访问的集群方案分为共享全局JNDI树方案，独立的JNDI方案和具有高可用性的中央集中JNDI方案，每种方案都可以实现JNDI服务提供的高可用性。

而在对EJB组件的调用阶段，客户端实际上只能调用一个叫做“Stub”的本地对象，这个本地的“Stub”和远程的EJB有相同的接口，起到代理的作用。Stub知道如何通过RMI/IIOP协议在网络上找到真正的对象。对于在调用EJB Stub过程中的集群方案，主要有以下3种方式：

●Smart Stub：在Stub代码中加入特殊的行为，但是这些代码对于客户端而言又是透明的（客户端程序对这些代码一无所知），这些代码包含了一个可访问的目标服务器的列表，也能够检测到目标服务器的失败，同时还包含了很复杂的负载均衡和失败转移的逻辑来分发请求。

●IIOP运行库：负载均衡和失败转移的逻辑集成在IIOP运行库中，这样就使得Stub很小并且不掺杂其他代码。

●LSD（LocatiON Service Daemon）：LSD的作用是EJB客户端的代理，在这种方案中，EJB客户端通过查找JNDI获取一个Stub，这个Stub中包含的路由信息指向LSD，而不是指向真正的拥有这个EJB的应用服务器。所以，LSD收到客户端的请求之后，根据其负载均衡和失败转移的逻辑将请求分发到不同的应用服务器实例。

3.5 数据库服务器方案

对于数据库服务器的集群方案，一般的方法有两种：一种是基于操作系统提供的集群软件，比如各种HA软件等；另一种是数据库软件本身提供的集群软件。

3.5.1 HA软件

HA软件的工作过程大致如下：

（1）在一个HA网络环境中，将网络分成TCP/IP网络和非TCP/IP网络。TCP/IP网络即应用客户端和服务器之间互相通*问的公共网，非TCP/IP网络是HA软件的