BlogJava-海水正蓝-随笔分类-Web 服务器

【转】WEB 集群与负载均衡(一)基本概念

小胡子 — Thu, 21 Feb 2013 01:24:00 GMT

Web集群是由多个同时运行同一个web应用的服务器组成，在外界看来就像一个服务器一样，这多台服务器共同来为客户提供更高性能的服务。集群更标准的定义是：一组相互独立的服务器在网络中表现为单一的系统，并以单一系统的模式加以管理，此单一系统为客户工作站提供高可靠性的服务。
    而负载均衡的任务就是负责多个服务器之间（集群内）实现合理的任务分配，使这些服务器（集群）不会出现因某一台超负荷、而其他的服务器却没有充分发挥处理能力的情况。负载均衡有两个方面的含义：首先，把大量的并发访问或数据流量分担到多台节点上分别处理，减少用户等待响应的时间；其次，单个高负载的运算分担到多台节点上做并行处理，每个节点设备处理结束后，将结果汇总，再返回给用户，使得信息系统处理能力可以得到大幅度提高
    因此可以看出，集群和负载均衡有本质上的不同，它们是解决两方面问题的不同方案，不要混淆。

    集群技术可以分为三大类：
    1、高性能性集群(HPC Cluster)
    2、高可用性集群(HA Cluster)
    3、高可扩展性集群

一、高性能性集群(HPC Cluster)
     指以提高科学计算能力为目标的集群技术。该集群技术主要用于科学计算，这里不打算介绍，如果感兴趣可以参考相关的资料。
二、高可用性集群(HA Cluster)
     指为了使群集的整体服务尽可能可用，减少服务宕机时间为目的的集群技术。如果高可用性集群中的某节点发生了故障，那么这段时间内将由其他节点代替它的工作。当然对于其他节点来讲，负载相应的就增加了。
    为了提高整个系统的可用性，除了提高计算机各个部件的可靠性以外，一般情况下都会采用该集群的方案。
    对于该集群方案，一般会有两种工作方式：
     ①主-主(Active-Active)工作方式
       这是最常用的集群模型，它提供了高可用性，并且在只有一个节点时也能提供可以接受的性能，该模型允许最大程度的利用硬件资源。每个节点都通过网络对客户机提供资源，每个节点的容量被定义好，使得性能达到最优，并且每个节点都可以在故障转移时临时接管另一个节点的工作。所有的服务在故障转移后仍保持可用，但是性能通常都会下降。

这是目前运用最为广泛的双节点双应用的Active/Active模式。

支撑用户业务的应用程序在正常状态下分别在两台节点上运行，各自有自己的资源，比如IP地址、磁盘阵列上的卷或者文件系统。当某一方的系统或者资源出现故障时，就会将应用和相关资源切换到对方的节点上。

这种模式的最大优点是不会有服务器的“闲置”，两台服务器在正常情况下都在工作。但如果有故障发生导致切换，应用将放在同一台服务器上运行，由于服务器的处理能力有可能不能同时满足数据库和应用程序的峰值要求，这将会出现处理能力不够的情况，降低业务响应水平。

     ②主-从(Active-Standby)工作方式
      为了提供最大的可用性，以及对性能最小的影响，主-从工作方式需要一个在正常工作时处于备用状态的节点，主节点处理客户机的请求，而备用节点处于空闲状态，当主节点出现故障时，备用节点会接管主节点的工作，继续为客户机提供服务，并且不会有任何性能上影响。

两节点的Active/Standby模式是HA中最简单的一种，两台服务器通过双心跳线路组成一个集群。应用Application联合各个可选的系统组件如：外置共享的磁盘阵列、文件系统和浮动IP地址等组成业务运行环境。

PCL为此环境提供了完全冗余的服务器配置。这种模式的优缺点：

缺点：Node2在Node1正常工作时是处于“闲置”状态，造成服务器资源的浪费。
优点：当Node1发生故障时，Node2能完全接管应用，并且能保证应用运行时的对处理能力要求。

三、高可扩展性集群
这里指带有负载均衡策略（算法）的服务器群集技术。带负载均衡集群为企业需求提供了更实用的方案，它使负载可以在计算机集群中尽可能平均地分摊处理。而需要均衡的可能是应用程序处理负载或是网络流量负载。该方案非常适合于运行同一组应用程序的节点。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也是如此。通常，单个节点对于太大的网络流量无法迅速处理，这就需要将流量发送给在其它节点。还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。
负载均衡集群在多节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障。

前面已经说过负载均衡的作用是在多个节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡可以采用软件和硬件来实现。一般的框架结构可以参考下图。


后台的多个Web节点上面有相同的Web应用，用户的访问请求首先进入负载均衡分配节点(可能是软件或者硬件)，由它根据负载均衡策略（算法）合理地分配给某个Web应用节点。每个Web节点相同的内容做起来不难，所以选择负载均衡策略（算法）是个关键问题。下面会专门介绍均衡算法。

web 负载均衡的作用就是把请求均匀的分配给各个节点，它是一种动态均衡，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把请求理分配出去。对于不同的应用环境（如电子商务网站，它的计算负荷大；再如网络数据库应用，读写频繁，服务器的存储子系统系统面临很大压力；再如视频服务应用，数据传输量大，网络接口负担重压。），使用的均衡策略 (算法)是不同的。所以均衡策略（算法）也就有了多种多样的形式，广义上的负载均衡既可以设置专门的网关、负载均衡器，也可以通过一些专用软件与协议来实现。在OSI七层协议模型中的第二（数据链路层）、第三（网络层）、第四（传输层）、第七层（应用层）都有相应的负载均衡策略（算法），在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径；在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点；而传输层和应用层的交换（Switch），本身便是一种基于访问流量的控制方式，能够实现负载均衡。
   目前，基于负载均衡的算法主要有三种：轮循（Round-Robin）、最小连接数（Least Connections First），和快速响应优先（Faster Response Precedence）。
①轮循算法，就是将来自网络的请求依次分配给集群中的节点进行处理。
②最小连接数算法，就是为集群中的每台服务器设置一个记数器，记录每个服务器当前的连接数，负载均衡系统总是选择当前连接数最少的服务器分配任务。这要比"轮循算法"好很多，因为在有些场合中，简单的轮循不能判断哪个节点的负载更低，也许新的工作又被分配给了一个已经很忙的服务器了。
③快速响应优先算法，是根据群集中的节点的状态（CPU、内存等主要处理部分）来分配任务。这一点很难做到，事实上到目前为止，采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说，只能在TCP/IP协议方面做工作，几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。

上面是负载均衡常用的算法，基于以上负载均衡算法的使用方式上，又分为如下几种：

1、DNS轮询
   最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。

　　 DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。当使用DNS负载均衡的时候，必须尽量保证不同的客户计算机能均匀获得不同的地址。由于DNS数据具备刷新时间标志，一旦超过这个时间限制，其他DNS服务器就需要和这个服务器交互，以重新获得地址数据，就有可能获得不同IP地址。因此为了使地址能随机分配，就应使刷新时间尽量短，不同地方的DNS服务器能更新对应的地址，达到随机获得地址，然而将过期时间设置得过短，将使DNS流量大增，而造成额外的网络问题。DNS负载均衡的另一个问题是，一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（刷新时间）才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器
2、反向代理服务器
    使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。

　　这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部服务器，而这种代理方式是代理多个客户访问内部服务器，因此也被称为反向代理模式。虽然实现这个任务并不算是特别复杂，然而由于要求特别高的效率，实现起来并不简单。

　　使用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能。然而它本身也存在一些问题，首先就是必须为每一种服务都专门开发一个反向代理服务器，这就不是一个轻松的任务。

　　代理服务器本身虽然可以达到很高效率，但是针对每一次代理，代理服务器就必须维护两个连接，一个对外的连接，一个对内的连接，因此对于特别高的连接请求，代理服务器的负载也就非常之大。反向代理方式下能应用优化的负载均衡策略，每次访问最空闲的内部服务器来提供服务。但是随着并发连接数量的增加，代理服务器本身的负载也变得非常大，最后反向代理服务器本身会成为服务的瓶颈。

3、地址转换网关
    支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。很多硬件厂商将这种技术集成在他们的交换机中，作为他们第四层交换的一种功能来实现，一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载。由于地址转换相对来讲比较接近网络的低层，因此就有可能将它集成在硬件设备中，通常这样的硬件设备是局域网交换机。

原文出自：

http://blog.csdn.net/lovingprince/article/details/3290871

小胡子 2013-02-21 09:24 发表评论

【转】tomcat中class和jar的加载顺序

小胡子 — Thu, 22 Nov 2012 04:03:00 GMT

当我们启动一个tomcat的服务的时候，jar包和claess文件是是以怎么样的顺序被加载进来的？

加载顺序：

1. $java_home/lib 目录下的java核心api

2. $java_home/lib/ext 目录下的java扩展jar包

3. java -classpath/-Djava.class.path所指的目录下的类与jar包

4. $CATALINA_HOME/common目录下按照文件夹的顺序从上往下依次加载

5. $CATALINA_HOME/server目录下按照文件夹的顺序从上往下依次加载

6. $CATALINA_BASE/shared目录下按照文件夹的顺序从上往下依次加载

7. 我们的项目路径/WEB-INF/classes下的class文件

8. 我们的项目路径/WEB-INF/lib下的jar文件

在同一个文件夹下，jar包是按顺序从上到下依次加载

由ClassLoader的双亲委托模式加载机制我们可以知道，假设两个包名和类名完全相同的class文件不再同一个jar包，如果一个class文件已经被加载java虚拟机里了，那么后面的相同的class文件就不会被加载了。

原文：

http://xiaomogui.iteye.com/blog/847686

小胡子 2012-11-22 12:03 发表评论

Websphere 反应很慢

小胡子 — Mon, 20 Aug 2012 06:16:00 GMT

Java代码

在项目中经常遇见这样的问题：修改应用的配置文件web.xml后，无论重启应用还是重启WebSphere服务器，都不能重新加载web.xml，导致修改的内容无效。
这个问题困扰了我好久，即使删除了${was安装目录}\IBM\WebSphere\AppServer\profiles\AppSrv01\下的 temp和wstemp两个缓存文件夹下的临时文件，重启后还是无效。几经折腾，后来终于找到了问题所在——还是由于was的缓存机制导致的。
找到${was安装目录}\AppServer\profiles\AppSrv01\config\cells\xxxNode01Cell \applications\${应用名}.ear\deployments\目录下，有一个与应用相同名称的缓存文件夹，删除或修改该文件夹的 web.xml，重启was即可。

Java代码

在websphere中修改了jsp后，有时会出现修改的jsp没有起作用，特别是改变了某jsp的样式后，在页面中没看到效果，这主要就是由于websphere中缓存的缘故，这就要清除WebSphere中jsp缓存，如我的应用部署的目录为：
E:\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\nbxzfwNode01Cell\项目名_war.ear\项目名.war
在这个目录下更新了某个jsp页面，后在浏览器里面查看的时候，发现页面没有改变。基于此，我查看了一下目录，存放应用临时文件的地方：
E:\IBM\WebSphere\AppServer\profiles\AppSrv01\temp\nbxzfwNode01\server1\项目名_war\项目名.war
在这目录下，可以看到有很多class文件，都是jsp编译过来的，对应我们应用目录下的jsp文件，于是找到对应jsp的class文件删除，再到浏览器中查看，发现已经改变了。。
还有一种办法，就是把这个jsp从项目中删除或重命名，再到浏览器里面查看那个页面，这时可能会报错，之后，再把对应的jsp添加上或名字改过来，再次到浏览器里面查看应用的时候，就发现这jsp的更新效果出来了，呵呵…

Java代码

前两天去客户那里给系统做升级，同时协助解决几个使用中的问题。到了现场第一件事情是把以前的应用导出做备份，结果居然遇到返回null。查看日志发现系统报告空间不足，以前遇到这个问题是因为WAS出现oom(Out of Memory）之后，会生成javacore和dump文件供分析内存，这两个文件通常都比较大，30多M。如果多次出现oom，生成的文件就会占用大量空间。难道最近经常内存溢出？我心抽搐。
　　快马赶到Profile目录，没有发现导出文件，询问客户也没有出现系统宕机的情况，大石落地。仔细查看之后发现profile下的wstemp目录体积巨大，接近1.7G。这是个临时目录，每当管理员通过console登录之后，wstemp会生成一个新文件夹，保存管理员的所有操作记录，在管理员登出之后会删除该目录。但是wstemp下一堆的临时文件夹都没有被删掉，看来是was 5的bug又遗留到was 6了，真是搞不明白，was的这一堆补丁怎么都没解决掉这么明显的一个问题。N多RMB的was啊，越来越觉得还不如免费的jboss。
　　回公司之后查看了自己的was版本，wstemp目录2.4G，不过分区够大才没出问题。直接删之了事

转：

http://dsr-22.iteye.com/blog/1258831

小胡子 2012-08-20 14:16 发表评论

不设置环境变量，Tomcat 设置JDK地址

小胡子 — Tue, 31 Jul 2012 02:49:00 GMT

修改

apache-tomcat-6.0.33\bin\catalina.bat 文件

@echo off
if "%OS% " == "Windows_NT " setlocal
rem ---------------------------------------------------------------------------
rem Start script for the CATALINA Server
rem
rem $Id: startup.bat,v 1.4 2002/08/04 18:19:43 patrickl Exp $
rem ---------------------------------------------------------------------------
set JAVA_HOME=c:\jdk
set CATALINA_HOME=c:\apache-tomcat-6.0.33

rem Guess CATALINA_HOME if not defined
if not "%CATALINA_HOME% " == " " goto gotHome

JAVA_HOME=c:\jdk
set CATALINA_HOME=c:\apache-tomcat-6.0.33 中
c:\jdk 是你jdk工具包的目录，

c:\apache-tomcat-6.0.33 是tomcat 安装目录

小胡子 2012-07-31 10:49 发表评论