Weblogic中的load banlance问题[Java编程]

在一个复杂的企业利用环境中,常常一个application server无法承当全部的服务恳求,所以很多企业都为此架起了多个服务器实例.这些服务器实例结合在一同,可以组织成一个健旺的企业运行环境,它易于扩大、支持load banlance, 支持fail over, 可以做到backend server的failure关于客户是透明的.这样的一个企业环境就是我们常说的Cluster.Weblogic Cluster供应了多种load banlance的大概, 比方web application恳求处理,可以通过proxy来实现(e.g. apache, HttpClusterServlet, IIS), 差别的J2EE Component在Weblogic有差别的load banlance实现．下面我们来一一看看,

1: Http恳求通过proxy实现的load banlance

当客户端通过proxy拜候Cluster中的业务页面时,proxy通过自身的算法(round-robin)来实现load banlance．当然这些恳求要求是从差别的客户端(大概不带session的同一客户端的恳求)发动的．关于同一客户端,假如页面中利用了 session, 那么Weblogic 通过session粘连来实现同一客户端的恳求会被dispatch到primary server上．假如primary server无法供应服务,那么恳求会被dispatch到其他server上.session粘连可以通过以下几种方法实现:

1.1:browser支持cookie的话,weblogic会把jsession id写入到cookie中,下次恳求提交的时刻jseeion id会被提交到proxy端,proxy通过jseeion id 来决意恳求的dispatch.

1.2:browser不支持cookie,server端在处理返回页面时,调用response.encodeURL()来将session id附在url上.

1.3:post-data方法,直接将session作为数据,post到proxy端.

我们来看看weblogic供应的HttpClusterServlet是若何实现load banlance的,

public　synchronized　Server　next()　{
　　　　　　 if　(list.size()　==　0)　return　null;
　　　　　　 if　(index　==　-1)　index　=　(int)(java.lang.Math.random()　*　list.size());
　　　　　　 else　index　=　++index　%　list.size();
　　　　　　 Object[]　servers　=　list.values().toArray();
　　　　　　 return　(Server)　servers[index];
}

HttpClusterServlet保护一个managed servlet list,每当一个恳求被dispatch到某个managed server后,server list的index加1,这样在下次dispatch恳求的时刻,恳求将会被dispatch到server list中的其他server上去.逻辑很简单,但基本也实现了load banlance功效.

2:InitialContext的load banlance

我们知道,每次我们需求获得jdbc connection, jms connection,ejb stub这类RMI Object的时刻,我们都要初始化一个上下文,问题是我们初始化上下文的时刻,衔接的毕竟是哪个managed server?

初始化上下文的时刻,我们需求供应一个provider url, 以下:

PROVIDER_URL = "t3://localhost:7011";

这种写法很简单,直接衔接7001对应的server, 但假如写法以下呢?

CLUSTER_PROVIDER_URL="t3://localhost:7011,localhost:7021";

这时刻,load banlance就又来了.10个客户端(weblogic server大概thin client)new 10个InitialContext的话,这10个客户端将55辨别衔接到后端的两台server上去.实际上客户端在new InitialContext的时刻,weblogic会成立一个T3衔接到对应的managed server上(RJVMConnection),注意这个RJVMConnection是个长衔接,在同一个JVM中,连向同一managed server的衔接只有一个.即假如一个客户端,持续new 10个 InitialContext, 这10个Context实际上是同一对象,weblogic server这时根本不会和后端的server通讯,因为对象已经在client JVM中有了.

new InitialContext的load banlance算法基本和proxy的算法一样,都是保护一个server list, 通过index递增的办法实现.差别的是:在衔接某个managed server的connection碰到peer gone的时刻, proxy可以recover server list, 而jndi context的load banlance算法例不能.也就是说假如后端有三个managed server, server1, server2相继呈现弊端的话,全部客户端的context将城市衔接到server3, 即便server1, server2可以恢复过来,后续恳求也不会衔接到他们,除非server3后来呈现问题.

值得一提的是:context全部的相关操作时server affinity的,而非load banlance.比方:2个客户端辨别new了个context, 辨别衔接到server1和server2上,衔接到server1的context,做了10次lookup,那么这10次操作,都在server1上完成,不会在server2上作任何操作.所以说jndi级别的load banlance不是绝对均衡的.

　　以上是“Weblogic中的load banlance问题[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：