集群技术学习总结

集群技术

集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可


靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。
集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管


理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性


。
中文名 集群技术 
外文名 cluster 
操    作 计算机、电脑 
性    质 服务器
目录
1 目的
2 分类
3 系统结构
4 调度方法
5 区别
6 发展趋势
目的
1 提高性能
一些计算密集型应用，如：天气预报、核试验模拟等，需要计算机要有很强的运算处理能力，现有的技


术，即使普通的大型机器计算也很难胜任。这时，一般都使用计算机集群技术，集中几十台甚至上百台


计算机的运算能力来满足要求。提高处理性能一直是集群技术研究的一个重要目标之一。
2 降低成本
通常一套较好的集群配置，其软硬件开销要超过100000美元。但与价值上百万美元的专用超级计算机相


比已属相当便宜。在达到同样性能的条件下，采用计算机集群比采用同等运算能力的大型计算机具有更


高的性价比。
3 提高可扩展性
用户若想扩展系统能力，不得不购买更高性能的服务器，才能获得额外所需的CPU 和存储器。如果采用


集群技术，则只需要将新的服务器加入集群中即可，对于客户来看，服务无论从连续性还是性能上都几


乎没有变化，好像系统在不知不觉中完成了升级。
4 增强可靠性
集群技术使系统在故障发生时仍可以继续工作，将系统停运时间减到最小。集群系统在提高系统的可靠


性的同时，也大大减小了故障损失。
分类
1 科学集群
科学集群是并行计算的基础。通常，科学集群涉及为集群开发的并行应用程序，以解决复杂的科学问题


。科学集群对外就好像一个超级计算机，这种超级计算机内部由十至上万个独立处理器组成，并且在公


共消息传递层上进行通信以运行并行应用程序。
2 负载均衡集群
负载均衡集群为企业需求提供了更实用的系统。负载均衡集群使负载可以在计算机集群中尽可能平均地


分摊处理。负载通常包括应用程序处理负载和网络流量负载。这样的系统非常适合向使用同一组应用程


序的大量用户提供服务。每个节点都可以承担一定的处理负载，并且可以实现处理负载在节点之间的动


态分配，以实现负载均衡。对于网络流量负载,当网络服务程序接受了高入网流量，以致无法迅速处理，


这时，网络流量就会发送给在其它节点上运行的网络服务程序。同时，还可以根据每个节点上不同的可


用资源或网络的特殊环境来进行优化。与科学计算集群一样，负载均衡集群也在多节点之间分发计算处


理负载。它们之间的最大区别在于缺少跨节点运行的单并行程序。大多数情况下，负载均衡集群中的每


个节点都是运行单独软件的独立系统。
但是，不管是在节点之间进行直接通信，还是通过中央负载均衡服务器来控制每个节点的负载,在节点之


间都有一种公共关系。通常，使用特定的算法来分发该负载。
3 高可用性集群
当集群中的一个系统发生故障时，集群软件迅速做出反应，将该系统的任务分配到集群中其它正在工作


的系统上执行。考虑到计算机硬件和软件的易错性，高可用性集群的主要目的是为了使集群的整体服务


尽可能可用。如果高可用性集群中的主节点发生了故障，那么这段时间内将由次节点代替它。次节点通


常是主节点的镜像。当它代替主节点时，它可以完全接管其身份，因此使系统环境对于用户是一致的。
高可用性集群使服务器系统的运行速度和响应速度尽可能快。它们经常利用在多台机器上运行的冗余节


点和服务，用来相互跟踪。如果某个节点失败，它的替补者将在几秒钟或更短时间内接管它的职责。因


此，对于用户而言,集群永远不会停机。
在实际的使用中，集群的这三种类型相互交融，如高可用性集群也可以在其节点之间均衡用户负载。同


样，也可以从要编写应用程序的集群中找到一个并行集群，它可以在节点之间执行负载均衡。从这个意


义上讲，这种集群类别的划分是一个相对的概念，不是绝对的。
系统结构
根据典型的集群体系结构，集群中涉及到的关键技术可以归属于四个层次：
（1）网络层：网络互联结构、通信协议、信号技术等。
（2）节点机及操作系统层高性能客户机、分层或基于微内核的操作系统等。
（3）集群系统管理层：资源管理、资源调度、负载平衡、并行IPO、安全等。
（4）应用层：并行程序开发环境、串行应用、并行应用等。
集群技术是以上四个层次的有机结合，所有的相关技术虽然解决的问题不同，但都有其不可或缺的重要


性。
集群系统管理层是集群系统所特有的功能与技术的体现。在未来按需（On Demand）计算的时代，每个集
群都应成为业务网格中的一个节点，所以自治性（自我保护、自我配置、自我优化、自我治疗）也将成
为集群的一个重要特征。自治性的实现，各种应用的开发与运行，大部分直接依赖于集群的系统管理层

。此外，系统管理层的完善程度，决定着集群系统的易用性、稳定性、可扩展性等诸多关键参数。正是

集群管理系统将多台机器组织起来，使之可以被称为“集群”。
调度方法
1 进程迁移
进程迁移就是将一个进程从当前位置移动到指定的处理器上。它的基本思想是在进程执行过程中移动它


，使得它在另一个计算机上继续存取它的所有资源并继续运行，而且不必知道运行进程或任何与其它相


互作用的进程的知识就可以启动进程迁移操作，这意味着迁移是透明的。进程迁移是支持负载平衡和高


容错性的一种非常有效的手段。对一系列的负载平衡策略的研究表明：进程迁移是实现负载平衡的基础


，进程迁移在很多方面具有适用性。
（1）动态负载平衡。将进程迁移到负载轻或空闲的节点上，充分利用可用资源，通过减少节点间负载的


差异来全面提高性能。
（2）容错性和高可用性。某节点出现故障时，通过将进程迁移到其它节点继续恢复运行，这将极大的提


高系统的可靠性和可用性。在某些关键性应用中，这一点尤为重要。
（3）并行文件IO。将进程迁移到文件服务器上进行IO，而不是通过传统的从文件服务器通过网络将数据


传输给进程。对于那些需向文件服务器请求大量数据的进程，则将有效地减少通讯量，极大地提高效率


。
（4）充分利用特殊资源。进程可以通过迁移来利用某节点上独特的硬件或软件能力。
（5）内存导引机制。当一个节点耗尽它的主存时，内存导引机制将允许进程迁移到其它拥有空闲内存的


节点，而不是让该节点频繁地进行分页或和外存进行交换。这种方式适合于负载较为均衡，但内存使用


存在差异或内存物理配置存在差异的系统。
2 进程迁移的实现角度
进程迁移的实现复杂性及对OS 的依赖性阻碍了进程迁移的广泛使用，尤其是对透明的进程迁移的实现。


根据应用的级别,进程迁移可以作为OS 的一部分、用户空间、系统环境的一部分或者成为应用程序的一


部分。
（1）用户级迁移：用户级实现较为简单，软件开发和维护也较为容易，因此，现有的很多系统都是采用


用户级实现，如Condor和Utopia。但由于在用户级无法获得Kernel的所有状态，因此，对于某类进程，


无法进行迁移。另外，由于Kernel空间和User空间之间存在着壁垒，打破这个边界获得Kernel提供的服


务需要巨大的开销。因此，用户级实现的效率远远低于内核级实现。
（2）应用级迁移：应用级迁移的实现较为简单，可移植性好，但是需要了解应用程序语义并可能需对应


用程序进行修改或重新编译，透明性较差，这方面的系统有Freedman、Skordos等。
（3）内核级迁移：基于内核的实现可以充分利用OS提供的功能，全面的获取进程和OS状态，因此实现效


率较高，能够为用户提供很好的透明性。但是由于需要对OS进行修改，实现较为复杂。这方面的典型系


统有MOSIX和Sprite系统。
进程迁移的主要工作就在于提取进程状态，然后在目的节点根据进程状态再生该进程。在现实中，一个


进程拥有很多状态，并且随着操作系统的演化，进程状态也越来越多样。一般来说，一个进程的状态可


以分为以下几类：①进程执行状态。表示当前运行进程的处理器状态，和机器高度相关。包括内核在上


下文切换时保存和恢复的信息，如通用和浮点寄存器值、栈指针、条件码等。②进程控制。操作系统系


统用来控制进程的所有信，一般包括进程优先级、进程标识，父进程标识等。一旦系统编排了进程控制


信息，进程迁移系统必须冻结该进程的运行。③进程Memory状态和进程地址空间。包括进程的所有虚存


信息，进程数据和进程的堆栈信息等，是进程状态的最主要的一部分。④进程的消息状态。包括进程缓


冲的消息和连接（Link）的控制信息。进程迁移中通讯连接的保持以及迁移后连接的恢复是进程迁移中


一项较有挑战意义的问题。⑤文件状态。进程的文件状态包括文件描述符和文件缓冲符。保持文件的


Cache一致性和进程间文件同步访问也是进程迁移机制需要着重考虑的。
区别
模拟集群与数字集群不同的地方，说简单点就是：模拟集群在单信道比数字对讲机用户容量要小，语音


没有数字对讲机清楚，只能实现简单的数据功能。
数字集群分TDMA和FDMA两种，TDMA是提供给专业用户使用的，是时分的制式。FDMA是提供给民用的，是


频分的制式。
FDMA和模拟对讲机相比，除了可以把信道间隔做得更窄（模拟的是25KHz，数字的是12.5KHz两时隙或


6.25KHz四时隙），单信道用户量更大外，对用户来说并没有太大的更新体验。
TDMA制式的对讲机和模拟对讲机相比，除了单信道用户容量更大外，还可以现实同频中转。模拟系统中


，要实现中转，必须要有收、发频率一对。而在TDMA时分数字系统中，可利用数字技术，通过时隙的转


换来实现中转。例如：当中转台收到A时隙的数据时，同时转发出去的数据就是在B时隙上实现的。
现在在中国还没有自己的数字对讲机标准。现在MOTOROLA的数字对讲机是TDMA制式的，ICOM和建伍的数


字对讲机是FDMA制式的。
发展趋势
虽然集群系统的构建目前可以说是模块化的，从硬件角度来看可以分为节点机系统、通讯系统、存储系


统等，软件角度则主要有操作系统、集群操作系统（COS）、并行环境、编译环境和用户应用软件等，目


前高性能计算机的通讯、存储等硬件系统是伴随摩尔定律快速发展的，跟踪、测试、比较最新硬件设备


构成的高性能计算机的可能方案也成了高性能计算机厂商的重要科研活动，而所有这些关键部件研发、


系统方案科研以及厂商的自主部件研发的高度概括就是“整合计算”。整合硬件计算资源的同时，伴随


着整合软件资源，其中集群操作系统COS是软件系统中连接节点机操作系统和用户并行应用的重要“黏合


剂”，也是高性能计算机厂商的技术杀手锏。
高性能集群系统目前在国内的应用领域主要集中在气象云图分析和石油勘探的领域。这样的应用对于高


性能集群系统来说进入门槛比较低，所以目前这些领域都采用了国内厂商构建的集群系统。虽然对比要


处理大量并发的小问题的用于商业计算的高可用性集群来说，高性能集群实现起来要简单一些。但实际


上，高性能集群的构建中仍有许多技术上的难点，尤其是高性能集群系统往往是针对一个很独特的科学


计算的应用，而对这种应用的实现用高性能集群系统来计算，就必须要先建立数学模型，而这样的建模


过程需要大量的对于这种应用模式的理解。总结起来，可管理性、集群的监控、并行程序的实现、并行


化的效率以及网络实现是构建高性能集群的几个难点。这其中，并行化程序的实现就是指特定应用领域


的特定应用程序在集群系统上的实现。虽然有诸多的技术实现上的难点，但集群系统本身的优势仍然给


了厂商们克服难点、攻克高性能集群的力量。首先撇开一些具体的优势不说，从互联网中心服务器的变


化来看，可以清晰地观察到集群结构是中心服务器的发展趋势。20世纪90年代以前，中心服务器一般都


用大型机（Mainframe），大型机上可以完成一切的应用和服务，用户从终端通过网络完成应用。这种应


用模式带来许多的好处：应用集中、比较好部署、系统监控、管理方便等。但大型机的缺点也是非常明


显的，主要是设备昂贵，很难实现高可用解决方案；非高可用系统在出现故障时，全部应用都受到影响


；操作系统、设备和部件比较专用，用户本身维护困难；可扩展性不强等。这些缺点中的任何一个都是


用户难以接受的。随着PC及其操作系统的普及和Intel CPU的性能和稳定性的不断提高，人们逐渐用PC服


务器构成的分布式系统（Distributed System）去代替大型机。分布式系统解决了大型机上面提到的多


个缺点,却丢弃了大型机应用的优点，服务器多且杂，不好监控、管理，不好部署。因此综合大型机和分


布式系统优势的服务器必将成为趋势，集群系统就是这样应运而生的服务器。
========

分布式与集群的区别是什么

集群是个物理形态，分布式是个工作方式。


只要是一堆机器，就可以叫集群，他们是不是一起协作着干活，这个谁也不知道；一个程序或系统，只


要运行在不同的机器上，就可以叫分布式，嗯，C/S架构也可以叫分布式。


集群一般是物理集中、统一管理的，而分布式系统则不强调这一点。


所以，集群可能运行着一个或多个分布式系统，也可能根本没有运行分布式系统；分布式系统可能运行


在一个集群上，也可能运行在不属于一个集群的多台（2台也算多台）机器上。


分布式是相对中心化而来，强调的是任务在多个物理隔离的节点上进行。中心化带来的主要问题是可靠


性，若中心节点宕机则整个系统不可用，分布式除了解决部分中心化问题，也倾向于分散负载，但分布


式会带来很多的其他问题，最主要的就是一致性。
集群就是逻辑上处理同一任务的机器集合，可以属于同一机房，也可分属不同的机房。分布式这个概念


可以运行在某个集群里面，某个集群也可作为分布式概念的一个节点。
一句话，就是：“分头做事”与“一堆人”的区别


1：分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起，实现同一业


务。


分布式中的每一个节点，都可以做集群。 而集群并不一定就是分布式的。


举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完


成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成


。


而分布式，从窄意上理解，也跟集群差不多， 但是它的组织比较松散，不像集群，有一个组织性，一台


服务器垮了，其它的服务器可以顶上来。


分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。


2：简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的


任务数来提升效率。


例如：


如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行该任务需10小时


。


采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，


执行完这个任务只需一个小时。(这种工作模式的一个典型代表就是Hadoop的Map/Reduce分布式计算模型


）


而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达


，10个服务器将同时工作，1小时后，10个任务同时完成，这样，整身来看，还是1小时内完成一个任务


！


分布式：一个业务分拆多个子业务，部署在不同的服务器上
集群：同一个业务，部署在多个服务器上


我个人理解：集群强调的是任务的同一性，分布式强调的是差异性。例如同样是负责文件传输的服务器


，对终端用户而言它只知道文件传到服务器上了，不在乎后台是几台服务器，分布在那些机房。对于后


台管理人员而言，同样是文件上传我可以在上海放置服务器处理上海地区的请求，北京放置服务器处理


北京的请求，最终实现全部地区用户可上传文件的任务，所以从这个角度来看是分布式的。另一方面，


上海的服务器可能有多台，同时处理上海来的请求，只是前端做了负载均衡，其内部运行逻辑什么的完


全是另外一台的clone,有一台挂掉了对整体业务无影响，所以从这个角度看是集群。如果北京的服务器


全挂了，那么北京的用户就没得玩了，从分布式的角度看对此是无能为力的，如果在此情况下我将北京


的请求转到上海，实现城市间的集群概念，那么就可handle 这个问题了。不过目前好像集群的概念用的


比较范了，你对用户说他的文件上传到了服务器集群也是ok的，至于内部是怎么个架构怎么个分布都无


所谓了。


按照我的理解，集群是解决高可用的，而分布式是解决高性能、高并发的


Distributed是针对用户/终端来讲的，把Job送到地理上分散的sever(i.e. 网格类)上协同作业，然后合


并计算结果。
Cluster是把很多的server捆绑串并，以infiniband实现高速内部互联网络，组成HPC. 从而支持多用户


的并行计算。


普通的软件是运行在一台物理机器上的，比如一个app或一个操作系统（如linux）；
而分布式系统则是这样一种软件系统：它运行在网络上，网络对于分布式系统就如同单台计算机对于普


通软件。
集群则是一组物理计算机的组合，组合起来的目标得看具体场合，比如有的是为了提高可用性，有的是


为了提高性能，有的是为了应对高并发。集群内的计算机之间使用什么方式进行协作，得看它们用的是


什么软件系统：既可能是分布式的系统也可能是普通的软件系统。


集群一般被分为三种类型，高可用集群如RHCS、LifeKeeper等，负载均衡集群如LVS等、高性能运算集群


;分布式应该是高性能运算集群范畴内。


在这里我也发表一下自己的一些拙见，看到大家这么多的回复，我思考，加入一个企业用一套体量很大


的系统，需要高效率处理任务的目标时，我觉得采用分布式+集群的模式 是不是应该是最佳的。也就是


说，先用分布式把这套系统进行负载均衡，即把各个功能模块进行拆分（也就是分布式概念），然后在


拆分的基础上增加集群。
========

服务器集群

服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。


集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使


得任何一个机器坏了整个系统还是能正常运行。
中文名 服务器集群 
外文名 Server cluster 
特    点 很高的计算速度 
学    科 计算机学
目录
1 服务器集群简介
2 创建群集
3 形成群集
4 集群服务的状态
5 优势
6 缺点
7 加入群集
▪ 寻找
▪ 条件
▪ 过程
▪ 验证
8 脱离群集
9 方法
10 集群的特点
11 集群技术的分类
服务器集群简介
一旦在服务器上安装并运行了集群服务，该服务器即可加入群集。集群化操作可以减少单点故障数量，


并且实现了群集化资源的高可用性。下述各节简要介绍了群集创建和集群操作中的节点行为。[1] 
注意：有关安装群集服务器的信息，请参阅 Windows server 2003产品家族的帮助和部署指南。
关于Windows Server 2003的企业版和Datacenter版都可以支持最大达8个节点的集群配置;其典型的特征


是可为数据库、消息系统、文件与打印服务这些关键业务应用，提供高可用性和可扩展性，在集群中的


多个服务器(节点)保持不间断的联系。即是说如果在集群中的某一节点因出错或维护不可用时，另一节


点会立刻提供服务，以实现容错。正在访问服务的用户可以继续访问，而不会察觉到服务已经由另一台


服务器(节点)提供。[2] 
创建群集
在服务器群集产品中含有用来在服务器上安装群集软件和创建新群集的群集安装实用工具。创建新群集


时，首先在选择作为群集的第一个成员的计算机上运行该实用工具。第一步是确定群集名称并创建群集


数据库和初始的群集成员列表来定义新群集。 Windows server 2003 群集新增了一个群集管理设置向导


以及使用 cluster.exe命令行界面创建（ 包括从远程创建 ）群集的功能。
创建群集的第二步是，添加可供所有群集成员使用的共用数据存储设备。这样，创建的新群集将带有一


个节点、自己的本地数据存储设备以及群集共用资源 —— 通常是磁盘或数据存储和连接介质资源。
创建群集的最后一步是，在另外将要成为群集成员的每一台计算机上运行安装实用工具。每当将新节点


添加到群集中时，新节点都会自动从群集的原始成员获得现有群集数据库的副本。当节点加入或形成群


集时，群集服务会更新该节点私有的配置数据库副本。
形成群集
如果服务器运行了群集服务并且无法找到群集中的其它节点，它自己可以形成一个群集。要形成群集，


节点必须能够获得对仲裁资源的独占权。
当最初形成群集时，群集中的第一个节点将包括群集配置数据库。每当有新节点加入群集时，新节点都


会在本地获得并保持群集配置数据库的副本。仲裁资源用恢复日志（其中含有同节点无关的群集配置和


状态数据）的形式存储配置数据库的最新版本。
在群集运行中，群集服务使用仲裁恢复日志执行以下操作 ：
保证只有一组活动、可相互通讯的节点才能形成群集
仅当某个节点可以获得对仲裁资源的控制权时 ， 才允许它形成群集
仅当某个节点可以同控制仲裁资源的节点通讯时 ， 才允许它加入或留在现有群集中
集群服务的状态
从群集中的其它节点和群集服务管理接口的角度看，当形成群集时，群集中的每个节点可能处于三种不


同状态中的一种。事件处理器会记录这些状态，而事件日志管理器会将这些状态复制到群集的其它节点


。群集服务状态包括：
脱机。此时的节点不是完全有效的群集成员。该节点及其群集服务器可能在运行，也可能未运行。
联机。此时的节点是完全有效的群集成员。它遵从群集数据库的更新、对仲裁算法施加自己的影响、维


护心跳通讯，并可以拥有和运行资源组。
暂停。它只能支持它当前已拥有的那些资源组。之所以提供暂停状态，是为了允许执行某些维护。大多


数服务器群集组件会将联机和暂停视为等价的状态。
优势
一、集群系统可解决所有的服务器硬件故障，当某一台服务器出现任何故障，如：硬盘、内存、CPU、主


板、I/O板以及电源故障，运行在这台服务器上的应用就会切换到其它的服务器上。
二、集群系统可解决软件系统问题，我们知道，在计算机系统中，用户所使用的是应用程序和数据，而


应用系统运行在操作系统之上，操作系统又运行在服务器上。这样，只要应用系统、操作系统、服务器


三者中的任何一个出现故障，系统实际上就停止了向客户端提供服务，比如我们常见的软件死机，就是


这种情况之一，尽管服务器硬件完好，但服务器仍旧不能向客户端提供服务。而集群的最大优势在于对


故障服务器的监控是基于应用的，也就是说，只要服务器的应用停止运行，其它的相关服务器就会接管


这个应用，而不必理会应用停止运行的原因是什么。
三、集群系统可以解决人为失误造成的应用系统停止工作的情况，例如，当管理员对某台服务器操作不


当导致该服务器停机，因此运行在这台服务器上的应用系统也就停止了运行。由于集群是对应用进行监


控，因此其它的相关服务器就会接管这个应用。
缺点
我们知道集群中的应用只在一台服务器上运行，如果这个应用出现故障，其它的某台服务器会重新启动


这个应用，接管位于共享磁盘柜上的数据区，进而使应用重新正常运转。我们知道整个应用的接管过程


大体需要三个步骤：侦测并确认故障、后备服务器重新启动该应用、接管共享的数据区。因此在切换的


过程中需要花费一定的时间，原则上根据应用的大小不同切换的时间也会不同，越大的应用切换的时间


越长。
加入群集
寻找
如果一个服务器要加入现有群集 ， 则它必须运行群集服务并且必须成功找到群集中的其它节点。在找


到其它节点后，加入的服务器必须接受群集成员资格验证，并获得群集配置数据库的副本。
条件
加入现有群集的过程开始于 Windows Server 2003 或 Windows 2000 Service Control Manager 在节点


上启动群集服务之时。在启动过程中，群集服务会配置并装入该节点的本地数据设备。它并不会试图将


共用的群集数据设备作为节点联机，因为现有群集可能正在使用这些设备。
过程
为了查找其它节点 ， 会启动一个发现过程。当节点发现任何群集成员时，它将执行身份验证序列。第


一个群集成员会对新加入者进行身份验证，并且在新服务器得到成功验证后返回成功状态。如果验证不


成功（未能识别待加入节点的群集成员身份，或者它使用了无效的帐户密码），则加入群集的请求会被


拒绝。
验证
进行成功验证后，首先联机的群集节点会检查加入节点上的配置数据库副本。如果该副本已过时，对加


入服务器进行验证的群集节点会为加入的服务器发送该数据库的更新副本。刚加入群集的节点在收到复


制的数据库后，可以用它查找共享资源并根据需要将它们联机。
脱离群集
当节点关闭或群集服务被停止时，节点可能脱离群集。但当节点不执行群集操作（比如不向群集配置数


据库提交更新）时，节点也可能被迫脱离（被逐出）群集。
如果节点根据预先的计划脱离群集，它会向其它所有节点成员发送 ClusterExit 消息，通知它们它将脱


离群集。该节点不等待任何响应就会立即进行关闭资源和所有群集连接的操作。由于其余节点收到了退


出消息，因此它们不会执行在节点意外失效或网络通讯停止时发生的重新分组过程以重新确立群集成员


身份。
方法
有两种常用的服务器集群方法，一种是将备份服务器连接在主服务器上,当主服务器发生故障时,备份服


务器才投入运行,把主服务器上所有任务接管过来。另一种方法是将多台服务器连接,这些服务器一起分


担同样的应用和数据库计算任务,改善关键大型应用的响应时间。同时,每台服务器还承担一些容错任务,


一旦某台服务器出现故障时,系统可以在系统软件的支持下,将这台服务器与系统隔离,并通过各服务器的


负载转嫁机制完成新的负载分配。PC服务器中较为常见的是两台服务器的集群,UNIX系统可支持8台服务


器的集群系统,康柏的专用系统OpenVMS可支持多达96台服务器的集群系统。
集群的特点
在集群系统中，所有的计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户


所使用。集群必须可以协调管理各分离组件的错误和失败，并可透明的向集群中加入组件。用户的公共


数据被放置到了共享的磁盘柜中，应用程序被安装到了所有的服务器上，也就是说，在集群上运行的应


用需要在所有的服务器上安装一遍。当集群系统在正常运转时，应用只在一台服务器上运行，并且只有


这台服务器才能操纵该应用在共享磁盘柜上的数据区，其它的服务器监控这台服务器，只要这台服务器


上的应用停止运行（无论是硬件损坏、操作系统死机、应用软件故障，还是人为误操作造成的应用停止


运行），其它的服务器就会接管这台服务器所运行的应用，并将共享磁盘柜上的相应数据区接管过来。


其接管过程如下图所示（以应用A为例）：
1.应用A正常工作时；
2.应用A停止工作后，其它的备用服务器将该应用接管过来。 具体接管过程分三部执行： a.系统接管 


b.加载应用 c.客户端连接
集群技术的分类
高可用集群
高可用集群的英文全称是High Availability，简称HA cluster。高可用的含义是最大限度地可以使用。


从集群的名字上可以看出，此类集群实现的功能是保障用户的应用程序持久、不间断地提供服务。
负载均衡集群
负载均衡集群也是由两台或者两台以上的服务器组成。分为前端负载调度和后端服务两个部分。负载调


度部分负责把客户端的请求按照不同的策略分配给后端服务节点，而后端节点是真正提供应用程序服务


的部分。与HA Cluster不同的是，负载均衡集群中，所有的后端节点都处于活动动态，它们都对外提供


服务，分摊系统的工作负载。
科学计算集群
高性能计算集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大计算能力，包括数值


计算和数据处理，并且倾向于追求综合性能。HPC与超级计算类似，但是又有不同，计算速度是超级计算


追求的第一目标。最快的速度、最大的存储、最庞大的体积、最昂贵的价格代表了超级计算的特点。随


着人们对计算速度需求的提高，超级计算也应用到各个领域，对超级计算追求单一计算速度指标转变为


追求高性能的综合指标，即高性能计算。[3] 
参考资料
========

java集群技术

越来越多的关键应用运行在J2EE（Java 2, Enterprise Edition）中，这些诸如银行系统和账单处理系


统需要高的可用性（High Availability, HA），同时像Google和Yahoo这种大系统需要大的伸缩性。高


可用性和伸缩性在今天高速增长的互连接的世界的重要性已经证实了。eBay于 1999年6月停机22小时的


事故，中断了约230万的拍卖，使eBay的股票下降了9.2个百分点。
J2EE集群是用来提供高可用性和伸缩性服务，同时支持容错处理的一种流行的技术。但是，由于J2EE规


范缺乏对集群的支持，J2EE供应商实现集群的方法也各异。这给J2EE架构师和开发人员带来了很多困难


。以下是几个常见的问题：
为什么带集群功能的商业J2EE服务器产品如此昂贵？（10倍于不带集群功能的产品）
为什么基于单服务器环境构建的应用不能在集群中运行？
为什么应用在集群环境中运行得很慢，但在非集群环境中却快得多？
为什么集群的应用移植到其他服务器中失败？
理解这些限制和要素的最佳方法是学习他们的实现方式。
基本术语
在我们讨论不同的集群实现之前，先谈谈几个概念。这有助于理解不同的J2EE集群产品不同的设计结果


和概念：
伸缩性（Scalability）：
在一些大的系统中，预测最终用户的数量和行为是非常困难的，伸缩性是指系统适应不断增长的用户数


的能力。提高这种并发会话能力的一种最直观的方式就增加资源（CPU，内存，硬盘等），集群是解决这


个问题的另一种方式，它允许一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务。
高可用性（High availability）：
单一服务器的解决方案并不是一个健壮方式，因为容易出现单点失效。像银行、账单处理这样一些关键


的应用程序是不能容忍哪怕是几分钟的死机。它们需要这样一些服务在任何时间都可以访问并在可预期


的合理的时间周期内有响应。集群方案通过在集群中增加的冗余的服务器，使得在其中一台服务器失效


后仍能提供服务，从而获得高的可用性。
负载均衡（Load balancing）：
负载均衡是集群的一项关键技术，通过把请求分发给不同的服务器，从而获得高可用性和较好的性能。


一个负载均衡器可以是从一个简单的Servlet或 Plug-Ins（例如一个Linux box利用ipchains来实现），


到昂贵的内置SSL加速器的硬件。除此之外，负载均衡器还需执行一些其他的重要任务，如“会话胶粘”


让一个用户会话始终存在一个服务器上，“健康检查”用于防止将请求分发到已失效的服务器上。有些


负载均衡器也会参与我们下面将要谈到“失效转移”过程。
容错（Fault tolerance）：
高可用性意味着对数据正确性的要求不那么高。在J2EE集群中，当一个服务器实例失效后，服务仍然是


有效的，这是因为新的请求将被冗余服务器处理。但是，当一个请求在一个正在失效的服务器中处理时


，可能得到不正确的结果。不管有多少个错误，容错的服务应当能确保有严格的正确的行为。
失效转移（Failover）：
失效转移是集群中用来获取容错能力的另一项关键的技术。当一个结点失效后，通过选择集群中的另一


个结点，处理将会继续而不会终止。转移到另一个结点可以被显式的编码，或是通过底层平台自动地透


明地路由到另一个服务器。
等幂方法（Idempotent methods）：
等幂方法是指这样一些方法：重复用相同的参数调用都能得到相同的结果。这些方法不会影响系统状态


，可以重复调用而不用担心改变系统。例如：getUsername()就是等幂的，而deleteFile就不是。当我们


讨论HTTP Session失效转移和EJB失效转移时，它是一个重要的概念。
什么是J2EE集群
一个天真的问题，不是吗？但我仍要用几句话和图来回答它。通常，J2EE集群技术包括"负载均衡"和"失


效转移"。
 
图 1  负载均衡
如图1所示，负载均衡意味着有许多客户端向目标对象同时发出请求。负载均衡器在调用者和被调用者之


间，分发请求到与原始对象相同的冗余对象中。伸缩性和高可用性就是这样得到的。
 
图 2  失效转移
如图2所示，失效转移与负载均衡不同。有时客户端会连续发请求到目标对象，如果请求中间目标对象失


效了，失效转移系统将检测到这次失败，并将请求重定向到另一个可用的对象。通过这种方式可以获得


容错能力。
如果你想知道更多的有关J2EE集群的知识，你就会问到一个基本的问题，“什么对象可以集群？”和“


在我的J2EE代码中哪里会发生负载均衡和失效转移呢？”。这些都是用来理解J2EE集群的非常好的问题


。实际上，并不是所有的对象都能被集群的，并且负载均衡和失效转移并不是在J2EE代码所有地方都能


发生。看看下面的例子代码：
 
图 3  例子代码
在Class A的bussiness()方法中，instance1可以负载均衡吗？或是当其失效，可以失效转移到其他B的


实例上吗？我想是不行的！对负载均衡和失效转移来说，必须要有个拦截器在调用者和被调用者之间分


发或重定向请求到不同的对象上。Class A和Class B的实例是运行在一个JVM中紧密耦合的，在方法调用


间加入分发逻辑非常困难。
什么类型对象可以被集群？——只有那些可以被部署到分布式拓朴结构中的组件。
在我的J2EE代码中，什么地方会有负载均衡和失效转移？——只在你调用分布式组件的方法时。
 
图 4  分布式对象
在如图4所示的分布式环境中，调用者和被调用者被分离在有明显边界的不同的运行容器中，这个边界可


以是JVM，进程和机器。
当目标对象被客户端调用时，目标对象的功能是在容器中运行的（这就是为什么我们说它是分布式的原


因）。客户端和目标对象通过标准的网络协议通信。这些特性就为一些机制提供了机会可以介入到方法


调用之间实现负载均衡和失效转移。
如图4，浏览器通过HTTP协议调用JSP对象，JSP运行在WEB服务器中，浏览器只需要返回结果而不关心它


是怎么运行的。在上述场景中，一些东西就可以在浏览器与WEB服务器之间实现负载均衡和失效转移的功


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


衡和失效转移就发生在这些分布式方法被调用时。在后续部分我们将详细讨论这些技术。
 
4 WEB层集群实现
WEB层集群是J2EE集群的重要且基本的功能。WEB集群技术包括WEB负载均衡和HTTP Session失效转移。
4.1 WEB负载均衡 
J2EE提供商实现WEB负载均衡有许多方式。基本上，都一个负载均衡器被插入到浏览器和WEB服务器之间


，如下图所示。
 
图 5  WEB负载均衡
负载均衡器可以是一台硬件，如F5负载均衡器，或仅仅是另一台有负载均衡Plug-Ins的WEB服务器，一个


简单的带ipchains的Linux box可以很好的实现负载均衡。不管采用哪种技术，负载均衡器都有以下特性


：
4.1.1 实现负载均衡算法
当客户请求到来时，负载均衡器需要决定将如何分发到后台服务器。流行的算法是Round-Robin、Random


和Weight Based。负载均衡器尽力使每台服务器实例都获得相同的负载，但是上述算法没有一个可以获


得理想的负载相同，因为它们仅仅是依据发送到特定服务器的请求的个数。一些精密的负载均衡器实现


了特殊的算法。它在分发请求之前将检测服务器的工作负载。
健康检测
当一台服务器失效了，负载均衡器应当检测出失效并不再将请求分发到这台服务器上。同样，它也要检


测服务器是否恢复正常，并恢复分发请求。
会话胶粘
几乎所有的WEB应用程序都有一些会话状态，可能是简单的记住用户是否登陆，或是包含你的购物车信息


。因为HTTP本身是无状态的，会话状态应当存在服务器的某个地方并与你当前浏览会话相关联，这样当


你下次再请求相同WEB应用程序的页面时可以很容易的重新获取。当负载均衡时，最佳的选择就是将特定


的浏览器会话分发到上次相同的服务器实例中，否则，应用程序可能不能正确工作。
因为会话状态存储在特定WEB服务器的内存中，“会话胶粘”对于负荷均衡非常重要。但是，如果其中某


台服务器实例因为某种原因失效了（比如关机），那么这台服务器的会话状态将要丢失。负载均衡器应


当检测到这个失效并不再将请求分发给它，但这些请求的会话状态都因为存放在失效的服务器中而丢失


了所有信息，这就将导致错误。会话的失效转移因此而生。
4.2 HTTP Session失效转移 
几乎所有流行的J2EE供应商都在他们的集群产品中实现了Http Session失效转移，用来保障当某台服务


器失效后会话状态不会丢失，使客户端请求能被正确处理。如图6所示，当浏览器访问有状态的WEB应用


程序（第 1 ,2步），这个应用程序可能在内存创建了会话对象用于保存信息以供后面的请求使用，同时


，发送给浏览器一个唯一的HTTP Session ID用于标识这个会话对象（第3步），浏览器将这个ID保存


Cookie中，并当它下次再请求同一WEB应用程序的页面时，会将Cookie发还给服务器。为了支持会话失效


转移，WEB服务器将在一定的时候把会话对象备份到其他地方以防止服务器失效后丢失会话信息（第4步


）。负载均衡器检测到这个失败（第5，6步），并将后续的请求分发到装有相同应用程序的服务器实例


中（第7步），由于会话对象已经备份到其他地方了，这个新的服务器实例可以恢复会话（第8步）正确


地处理请求。
 
图 6  HTTP Session失效转移
为了实现上述功能，HTTP Session失效转移将带来以下问题：
全局HTTP Session ID
如上所述，HTTP Session ID用于在特定的服务器实例中标识唯一的内存会话对象，在J2EE平台，HTTP 


Session ID依赖于JVM实例，每个JVM实例拥有几个应用程序，每个应用程序都为不同的用户管着许多会


话，HTTP Session ID是在当前JVM实例用于访问相关会话的关键。在会话失效转移的实现中，要求不同


的JVM实例不能产生两个相同的HTTP Session ID，这是因为当失效转移发生时，一个JVM的会话将要备份


并恢复到另一个中，这样，必须建立全局HTTP Session ID产生机制。
 如何备份会话状态
如何备份会话状态是区别J2EE服务器好坏的关键因素。不同的供应商有不同的实现，在后续部分我再详


细解释。
备份的频率和粒度
会话的备份是消耗性能的，包括CPU，内存，网络带宽和写入磁盘和数据库的I/O，备份的频率和备份对


象的粒度将严重影响性能。
4.2.1 数据库备份方式
几乎所有的J2EE集群产品都允许选择将你的会话对象通过JDBC备份到关系数据库中。如图7所示，这种方


式可以让服务器实例非常简单的在正确的时间序列化会话内容并写到数据库中。当发生会话转移时，另


一台可用的服务器接过已失效的服务器工作，从数据库中恢复所有的会话状态。序列化对象是关键点，


它使得内存会话数据可以持久化和传输。要了解更多有关Java对象序列化知识，请参考


http://java.sun.com/j2se/1.5.0/docs/guide/serialization/index.html 。
 
图 7  备份会话数据到数据库
由于数据库交易是非常昂贵的，这种方法主要缺点是当在会话中保存大量的或大的对象时限制了伸缩性


，大多数使用数据库会话持久化的服务器产品都提倡尽量减少用HTTP会话存储对象，但这限制了你的应


用程序的架构和设计，特别是你要使用HTTP会话缓存用户数据时。
数据库的方式也有一些优点：
简单，容易实现。分离的请求处理和会话备份处理使集群更好管理和健壮。
会话可以失效转移到任何一台服务器，因为数据库是共享的。
当整个集群失效时，会话数据依旧幸免。
4.2.2 内存复制方式 
因为性能的原因，一些J2EE服务器（Tomcat，Jboss，WebLogic，WebSphere）提供了另一种实现：内存


复制
 
图 8  对会话状态进行内存复制
基于内存的会话持久化将会话信息保存在一台或是多台备份服务器中，而不是保存数据库中（如图8）。


这种方式因为性能高而非常流行。同数据库方式相比，直接在原服务器和备份服务器之间网络通信是非


常轻量的。同时注意在使用方式中，数据库方式中的“恢复”阶段是不需要的，因为在备份后，所有会


话数据都已经存在备份服务器的内存中了，已经可以处理请求。
“Java Groups”是当前Tomcat和Jboss集群所使用的通信层。Java Groups是用于实现可靠组通信和管理


的工具包。它提供了诸如“组成员协议”和“消息广播”等核心特性，这些都对集群的工作非常有用。


有关Java Groups的信息，请参考：http://www.jgroups.org/javagroupsnew/docs/index.html 。
4.2.3 Tomcat方式：多服务器复制
内存复制也存在许多不同的方式，第一种方法就是将会话数据复制到集群中的所有结点，Tomcat5采用的


就是这种方式。
 
图9  多服务器复制
如图9所示，当一个服务器实例的会话改变后，将备份到其他所有的服务器上。当一台服务器失效后，负


载均衡器可以选择其他任何一台可用的服务器实例。但这种方式限制了伸缩性，如果集群中有很多的服


务器实例，那么网络通信的代价就不能被忽略，这将严重降低性能，并且网络也将成为系统的瓶颈。
4.2.4 WebLogic，Jboss和Websphere的方式：对等服务器复制
由于性能和伸缩性的原因，WebLogic，Jboss和Webshpere采用了其他方式实现内存复制。每台服务器任


意选择一台服务器备份其内存中的会话信息。如图10所示。
在这种方式中，每台服务器都有一台自己的对等服务器，而不是其他所有的服务器，这种方式消除在集


群中加入过多服务器实例的话影响伸缩性的问题。
 
图 10  对等服务器复制
尽管这种方式实现失效转移有很高的性能和伸缩性，但它仍有一些限制：
它给负载均衡器带来了更多的复杂性。当一台服务失效后，负载均衡器必须知道那台服务是这台己失效


服务器的对等备份服务器。这将缩小了负载均衡器的选择范围，同时有些硬件也不能满足这种要求。
 除了处理正常的请求外，服务器还将负责复制的任务。由于备份会话数据的任务也需要占用CPU的周期


，所以每台服务器的请求处理能力也降低了。
在没有发生失效转移的时候，备份服务器上大量用于备份的内存是个浪费。同时这也将增加了JVM GC的


负担。
集群中的服务器实例构成了复制对。这样，当会话所在主服务器失效后，负载均衡器将会话转移到备份


服务器，使备份服务器处理两倍的请求，这将造成备份服务器的性能问题。
为了克服上面的4点问题，不同的软件供应商采用了不同的方法，WebLogic采用的复制对不是对每台服务


器，而是对每个会话。当一台服务器实例失效后，会话数据己经分散备份到多个备份服务器上，使失效


的负载均匀地分布。
4.2.5 IBM的方式：中央状态服务器
Websphere采用不同的方式实现内存复制：备份会话信息到中央的状态服务器，如图11所示：
 
图 11  中央状态服务器复制
这与数据库的解决方案非常类似，不同之处在于专用的“会话备份服务器”代替了数据库服务器，这种


方式结合了数据库和内存复制两种方式的优点。
将请求处理和会话备份处理分开使用集群更加健壮。
 所有的会话数据都备份到专用的服务器上，无需服务器浪费内存用于备份其他服务器的会话。
因为会话备份服务器是在服务器之间共享的，所有失效后可以转移到任何一台服务器上，这样大多数据


软硬件负载均衡器都可以使用，更重要的是当一台服务器失效后，负载将均匀的分布到所有实例上。
与重量级的数据库连接相比，应用服务器与备份服务器之间Socket通信是轻量的。这样就比数据库的解


决方案有更好的性能和更好的伸缩性。
然而，由于有恢复失效服务器会话数据的这么一个阶段，因此其性能肯定不如两台服务器直接复制解决


方案，另外，多出来一台备份服务器也增加了管理的复杂性。也可能由于单台备份服务器造成性能瓶颈


。
4.2.6 Sun的方式：特殊数据库
 
图 12  特殊数据库复制
Sun JES应用服务器采用了别的方式实现会话失效转移，如图12所示，它看上去很像数据库的方式，因为


它采用关系数据库存储会话并通过JDBC访问所有会话数据。但是JES内部所使用的关系数据库称为HADB，


已经为访问会话做了特别优化，并且将几乎所有的会话数据存在内存中。这样，你可以说它更像中央状


态服务器的方式。
4.2.7 性能因素
考虑如下问题：一台WEB服务器中可能运行着许多WEB应用，它们中每一个都可能被成百的并发用户访问


，而每个用户都会产生浏览器会话用于访问特定的应用。所有会话信息都将备份以便服务器失效后能转


移到其他服务器实例中。更糟的是，会话会由于一次次的发生以下情况而变化，包括创建、失效、增加


属性、删除属性、修改属性值。甚至是什么都没变，但由于有新的访问而使最后访问时间变了（由此判


断什么时候失效会话）。因此，性能在会话失效转移的解决方案中是个很大的因素。供应商通常会提供


一些可调的参数改变服务器行为，使之适应性能需求。
4.2.7.1 备份时机
当客户端的请求被处理后，会话随时改变。由于性能因素，实时备份会话是不明智的。选择备份频率需


要平衡。如果备份动作发生得太频繁，性能将急剧下降。如果两次备份的间隔太长，那么在这间隔之间


服务器失效后，很多会话信息将会丢失。不管所有的方式，包括数据库和内存复制，下面是决定备份频


率的常用的选项。
 按WEB请求
在WEB请求处理结束后，发生响应之前保存数据。这种方式能够保证在失效后备份的会话数据是最新的。
按固定的时间间隔
会话在后台按固定的时间间隔保存。这种方式不能保证备份的会话数据是最新的。但由于不需在每次请


求之后备份数据，因而有更好的性能。
4.2.7.2 备份粒度
当备份会话的时候，你还需要决定多少会话状态需要保存。以下是不同产品所有采用的常用的策略。
整个会话
每次都将保存所有会话。这种方式为正确保存分布式WEB应用的会话提供了最好保证。这种方式简单，内


存复制和数据库存储方式都默认采用这种方式。
修改过的会话
当会话被修改过后，则备份整个会话。当“session.setAttribute()”或 “session.removeAttribute


()”被调用后，则认为会话被修改过。必须保证这些方法调用才修改会话属性，这并不是J2EE规范后要


求的。但却是正确实现这种方法所需要的。备份修改过的会话减少了会话存储的数量，那些仅仅是读取


会话属性的请求将不会触发会话备份的动作。这将带来比备份整个会话更好的性能。
修改过的属性
仅仅是保存被修改过的会话属性而不是整个会话。这将最小化备份的会话数据。这种方式带来最好的性


能及最小的网络通信。为了保证这种方式工作的正确性，必须依据以下的要点。首先，只能通过调


用“setAttribute()”方法修改会话状态，并且会话数据要被序列化和备份。其次，确保属性之间没有


交叉引用。每个唯一的属性键值下的对象图应当被独立地序列化和保存。如果两个独立的键值下的对象


存在交叉引用，它们将不能够正确的序列化和反序列化。例如图13所示，在一个内存复制的集群中，会


话中存有“student”和“school”对象，同时“school”对象含有到“student”对象的引用，某一个


时候“school”被修改后备份到备份服务器中。在序列化和反序列化之后，在备份服务器的被还原


的“school”对象的版本将包含整个对象图，包括其引用的“student”对象。但是“student”对象可


以被独立的修改，当它被修改后，仅仅只有它自己被备份。在序列化和反序列化之后，在备份服务器中


还原“student”对象，但在此时，它将丢失与“school”对象的连接。尽管这种方式有最好的性能，但


上述限制将影响WEB应用程序的架构和设计。特别是需要用会话保存缓存的复杂的用户数据。
 
图 13  会话复制中的交叉引用
4.2.8 其他失效转移的实现
如前面章节所提到的，当会话备份时粒度对于性能非常重要。然而，当前的一些实现，不管是数据库存


储还是内存复制，都将使用Java对象序列化技术来传输Java对象。这就打了个大印子，影响系统的性能


，并给WEB应用程序的架构和设计带来很多的限制。一些J2EE供应商便寻找一些特别的手段来更为轻量地


，小印子地实现WEB集群，提供细粒度的分布式对象共享机制用于提高集群的性能。
4.2.8.1 Jrun的Jini技术
Jrun4将它的集群解决方案构在Jini技术之上。Jini为分布式计算而生，它允许在一个单一的分布式计算


空间内创建“联合”的设备或组件。 Jini提供查找，注册，租用等分布式系统服务，这对集群环境非常


有用。另一种称为JavaSpace的技术构建于Jini之上，它提供了一些用于实现集群非常有价值的特性，如


对象处理，共享，迁移等。要了解有关Jini和JavaSpace更多的信息，请参考


http://java.sun.com/products/jini/2_0index.html
4.2.8.2 Tangosol的分布式缓存
Tangosol Coherence提供了一个分布式数据管理平台，它可以嵌入到大多数流行的J2EE服务器中用于实


现集群环境。Tangosol Coherence同时也是提供了分布式缓存系统用于在不同的JVM之间有效地共享Java


对象。要了解有关Tangosol更多的信息，请参考http://www.tangosol.com
 
5 JNDI集群实现
J2EE规范要求所有的J2EE容器必须提供JNDI规范的实现。JNDI在J2EE应用程序中的主要角色是用来提供


一个间接层，这样资源可以很容易被找到，而不用关心细节。这使得J2EE组件更加可复用。
拥用全特性的集群的JNDI对于J2EE集群是非常重要的。所有的EJB调用都开始于在JNDI树上查找它的Home


接口，J2EE供应商根据他们的集群结构采用不同的方式实现JNDI集群。
5.1 共享全局JNDI树 
WebLogic和Jboss都有一个全局的，共享的，集群范围的JNDI Context供客户端查找和绑定对象，绑定的


全局JNDI Context中对象将通过IP广播的方式在集群中复制，这样当一台服务器实例停机后，被绑定的


对象仍然可供查找。
 
图 14  共享的全局JNDI
如图14所示，共享的全局JNDI树实际包括了所有本地JNDI结点上绑定的对象。集群上每个结点都拥有自


己的名称服务器，它们与集群中其他服务器相互复制所有的东西。这样每个名称服务器上都拥有其他名


称服务器对象树的拷贝。这种冗余结构使得全局JNDI树高可用。
实际上，集群的JNDI树可以被用做两个目的。可以被管理员用来部署对象和服务。在一台服务中部署完


EJB模块或JDBC&JMS服务后，JNDI树上的所有对象都将复制到其他服务器实例中。在运行期，程序可以


JNDI API访问JNDI树存储或者获取对象，这些对象也将被全局复制。
5.2 独立JNDI
Jboss和WebLogic都采用了共享全局JNDI树的方式，Sun JES和IBM WebSphere等采用了每个服务器都拥有


独立的JNDI树的方式。在使用独立JNDI树的集群中，成员服务器不必知道或关心集群中其他服务器。这


是否意味着不想把JNDI集群呢？所有EJB访问都开始于在JNDI树上查找它们的Home接口，如果没有可集群


的JNDI树，集群就根本无用。
实际上，如果J2EE应用程序是相似的，独立的JNDI树仍然可以获得高可用性。当集群中所有实例都有相


同的设置以及都部署相同的应用程序集，我们说集群是“相似的”，这种情况下，一种被称为代理的特


殊管理工具可以帮助我们获取高可用性，如图15所示：
 
图 15  独立JNDI
不管是Sun JES还是WebSphere都在集群的实例上安装了结点代理，当部署EJB模块或绑定其他JNDI服务，


管理控制员可以向所有的代理发出命令，以此实现与共享全局JNDI相同的效果。
但是独立JNDI的方案不能支持复制在运行期绑定或获取的对象。有以下几个原因：JNDI在J2EE应用程序


中的主要角色是用来提供管理外部资源的间接层，并不是用来做数据存储。如果有这样的需求，可以采


用具有HA（高可用性）特性的独立的LDAP服务器或数据库。Sun和IBM自己都有这样拥有集群特性的独立


的LDAP服务器产品。
5.3 中心JNDI
少数J2EE产品使用了中心JNDI方案，这种方案中名称服务器驻留在单一服务器中，所有的服务器实例都


注册它们相同的EJB组件和管理对象到单一的服务器中。
名称服务器实现了高可用性，这对客户端是透明的。所有的客户端都在这台服务器中查找EJB组件，但是


这种结构意味着复杂的安装和管理，慢慢被多数供应商抛弃。
5.4 初始化访问JNDI服务器 
当然客户端要访问JNDI服务器的时候，它们需要知道远程JNDI服务器的主机名/IP地址和端口，在全局或


是独立JNDI树的方案中，有多个JNDI服务器。客户端第一次访问时应该连接哪个呢？如何获得负载均衡


和失效转移呢？
从技术上说，一个软件或硬件负载均衡器可以设在远程客户端和所有的JNDI服务器之间执行负载均和失


效转移。但是，很少有供应商实现这种方式，这里有些简单的方案：
Sun JES和Jboss 实现JNDI集群是在“java.naming.provider.url”属性中设置一列用逗号分隔的URL，


如 java.naming.provider.url=server1:1100,server2:1100:server3.1100:server4.1100 客户端将挨


个联系列表中的服务器，一旦其中一个响应了便中止。
Jboss同时也实现了自动发现的特性，当设置属性串“java.naming.provider.url”为空时，客户端将试


图通过网络广播来发现在一个JNDI服务器。
6 EJB集群实现
EJB是J2EE技术中重要的部分，并且EJB集群是实现J2EE集群最大的挑战。
EJB技术是为分布式计算而生。它们可以在独立的服务器中运行。Web服务器组件或富客户端可以从其他


的机器通过标准协议（RMI/IIOP）来访问EJB。你可以象调用你本地Java对象的方法一样调用远程EJB的


方法。实际上，RMI/IIOP完全掩盖了你正在调用的对象是本地的还是远程的，这被称作本地/远程透明性


。
 
图 16  EJB调用机制
上图显示了远程EJB的调用机制。当客户端想使用EJB，它不能直接调用，相反，客户端只能调用一个被


称为“stub”的本地对象，它扮演了到远程对象代理的角色，并且有远程对象相同的接口。这个对象负


责接受本地方法调用，并且这些调用通过网络代理到远程EJB。这些对象在客户JVM中运行，并且知道如


何通过RMI/IIOP跨过网络查找真正的对象。要了解有关EJB更多的信息，请参考


http://java.sun.com/products/ejb/
为解释EJB集群的实现，我们先看看在J2EE代码中如何使用EJB的。为了调用EJB，我们需要
在JNDI服务器中查找EJBHome stub
使用EJBHome stub查找或创建EJB对象，这样获得一个EJBObject stub
在EJBObject stub上调用方法
负载均衡和失效转移可以在JNDI查找时发生，这我们已在上面阐述了。在EJB stub（包括EJBHome和


EJBObject）的方法调用时，供应商采用以下三种方式实现EJB负载均衡和失效转移。
6.1 智能存根（Smart stub）
正如我们所知，客户端可以通过存根对象（stub）来访门远程的EJB，这个对象可以通过JNDI树获取，甚


至客户端可能透明地从WEB服务器上下载存根类文件。
这样存根就可以在运行期动态地用程序生成，而其类文件也不必在客户端环境的classpath或库中。（因


为它是可以被下载的）
 
图 17  智能存根
如图17所示，BEA WebLogic和Jboss通过在存根代码中组合几种行为来实现EJB集群，而这些都是在客户


端透明运行的（客户端不需要了解这些代码）。这种技术叫做智能存根。
智能存根确实很聪明，它包含一组它可以访问的目标实例，可以检测这些实例的任何失效，它也包含了


复杂的负载均衡和失效转移的逻辑，用来分发请求到目标实例。而且，如果集群拓朴改变了的话（比如


新增或删除了服务器实例），存根可以更新它的目标实例清单来反映新的拓朴，而不需要手工重新配置


。
使用智能存根实现集群有以下优点：
因为EJB存根运行在客户端，所以它可以节省许多服务器资源。
负载均衡是在客户端代码中，并且与客户端的生命周期相关。这样就消除了负载均衡器的单点失效。如


果负载均衡器失效了，就意味着客户端也失效了，这种情况是能接受的。
存根可动态的自动下载更新，这意味着零维护。
6.2 IIOP运行期库 
Sun JES Application Server使用了另一种方法实现EJB集群。负载均衡和失效转移逻辑是在IIOP运行库


中实现的。比如，JES修改了“ORBSocketFactory”的实现，使它能支持集群。如图18所示。
 
图 18  IIOP运行期
“ORBSocketFactory”的修改版有实现负载均衡和失效转移的所有逻辑和算法，这样就保持了存根干净


和小。因为是在运行库中实现的，这样就比存根的方式更容易获得系统资源。但这种方式需要在客户端


运行一个特殊的运行库，这样就给与其他J2EE产品进行互操作时带来了麻烦。
6.3 拦截器代理
IBM Webshpere采用了定位服务精灵（Location Service Daemon-LSD）,它对EJB客户端扮演了拦截器代


理的角色，如图19所示。
 
图 19  拦截器代理
在这种方式中，客户端通过JNDI查找获取存根，这个存根将信息路由到LSD，而不是运行了EJB的应用程


序服务器。这样LSD接收到所有进来的请求，根据负载均衡和失效转移的策略来判断应该将它发送到哪个


服务器实例。这种方式增加的安装和维护集群的额外的管理工作。
6.4 EJB的集群支持 
要调用EJB的方法，要涉及到两种存根对象，一是EJBHome接口，另一个是EJBObject接口。这意味着EJB


潜在的需要在两层上实现在负载均衡和失效转移。
当客户端使用EJBHome存根创建或查找EJB对象时
 当客户端调用EJB对象上的方法时。
6.4.1 EJBHome存根支持集群
EJBHome接口用于在EJB容器中创建和查找EJB实例，而EJBHome存根是EJBHome接口的客户端代理。


EJBHome接口不需维持任何客户端的状态信息。这样，来自不同EJB容器中的相同EJBHome接口对于客户端


来说是一致的。当客户端执行create()或find()调用的时候，home存根根据负载均衡和失效转移算法从


多个相同的服务器实例中选择一个，并将调用发送到该服务器的home接口上。
6.4.2 EJBObject存根支持集群
当EJBHome接口创建一个EJB实例，它将返回EJBObject的存根给客户端，并让用户调用EJB的业务方法。


集群中已有一组可用的服务器实例，并在上面的部署了bean，但是不能将EJBObject存根对象向


EJBObject接口发出调用转发到任意一个服务器实例上，这取决于EJB的类型。
无状态会话Bean是最简单的情况，因为不涉及到状态，所有的实例都可以认为是一样的，这样对


EJBObject的方法调用可负载均衡和失效转移到任意一个服务器实例上。
集群的有状态会话Bean与无状态会话Bean有一点不同，正如我们所知，有状态会话Bean对于客户端连续


的请求会持有状态信息。从技术上来说，集群有状态会话Bean与集群HTTP Session是一样的。在常规时


间，EJBObject存根将不会把请求负载均衡到不同的服务器实例。相反，它将胶粘到最初创建的服务器实


例上，我们称这个实例为“主实例”。在执行过程中，会话状态会从主实例备份到其他服务上去。如果


主实例失效了，备份服务器将接管它。
实体Bean本质上是无状态的，尽管它可以处理有状态的请求。所有的信息都将通过实体Bean本身的机制


备份到数据库中。这样看起来实体Bean可以象无状态会话Bean一样很容易获取负载均衡和失效转移。但


实际，实体Bean多数情况下是不负载均衡和失效转移的。根据设计模式的建议，实体Bean 被会话外观包


装。这样，多数对实体Bean的访问都是进程内会话Bean通过本地接口完成的，而不是远程客户端。这使


得负载均衡和失效转移没有意义。
 
JMS和数据库连接的集群支持
除JSP，Servlet，JNDI和EJB之外，在J2EE中还有其他的分布式对象。这些对象在集群的实现中可能支持


，可能不支持。
当前，一些数据库产品，如Oracle RAC，支持集群环境并可以部署到多复制，同步的数据库实例中。然


而，JDBC是一个高度状态化的协议并且它的事务状态直接与客户端和服务器的 Socket连接绑定，所以很


难获取集群能力。如果一个JDBC连接失效了，与该失效连接相关的所有JDBC对象也就失效了。客户端代


码需要进行重连的动作。BEA WebLogic使用JDBC多池（multipool）技术来简化这种重连过程。
JMS被多数J2EE服务器所支持，但支持得并不完全，负载均衡和失效转移仅仅被JMS代理所实现，很少有


产品在JMS Destination中的消息有失效转移的功能。
 
8 J2EE集群的神话
8.1 失效转移可以完全避免错误——否定
在Jboss的文档中，整个章节都在警告你“你真的需要HTTP会话的复制吗？”。是的，有时没有失效转移


的高可用性的解决方案也是可接受并且是廉价的。失效转移并不是你想象的那么强壮。
那么失效转移到底给你带来了什么？你可能想失效转移可以避免错误。你看，没有会话的失效转移，当


一个服务器实例失效后，会话数据将丢失而导致错误。通过失效转移，会话可以从备份中恢复，而请求


可以被其他服务器实例所处理，用户根本意识不到失效。这是事实，但这是有条件的！
回想一样我们定义的“失效转移”，我们定义了一个条件是失效转移是在“两个方法调用之间”发生的


。这是说如果你有两个连续的对远程对象的方法调用，失效转移只会在第一调用成功后并且第二调用的


请求发出前才能发生。
这样，当远程服务器在处理请求的过程中失效了会发生什么呢？答案是：多数情况处理将会停止而客户


端将会看到错误信息。除非这个方法是等幂的（Idempotent），只有这个方法是等幂的，一些负载均衡


器更智能，它会重试这些方法并将它失效转移到其他实例上。
为什么“等幂”重要呢，因为客户端不知道当失效发生的时候请求被执行到什么地方。是才刚刚初始化


还是差不多就要完成了？客户端没法判断！如果方法不是等幂的，在相同方法上的两次调用可能会两次


修改系统的状态，而使得系统出现不一致的情形。
你可能想所有在事务中的方法都是等幂的，毕竟，如果错误发生，事务将被回滚，事务状态的改变都将


被复位。但事实上事务的边界可能不包括所有的远程方法调用过程。如果事务已经在服务器上提交了而


返回给客户端时网络崩溃怎么办呢？客户端不知道服务器的事务是否是成功了。
在一些应用程序中，将所有的方法都做成等幂的是不可能的。这样，你只能通过失效转移减少错误，而


不是避免它们。拿在线商店为例，假设每台服务器可以同时处理100个在线用户的请求，当一台服务器失


效了，没有失效转移的解决方案将丢失100个用户的会话数据并激怒这些用户。而有失效转移的解决方案


中，当失效发生的时候有20个用户正在处理请求，这样20个用户将被失效激怒。而其他80个用户正处于


思考时间或在两个方法调用之间，这些用户可以透明地获得失效转移。这样，你就需做以下的考虑：
激怒20个用户和激怒100个用户造成影响的区别。
采用失效转移和不采用失效转移产品成本的区别
8.2 独立应用可以透明的迁移到集群结构中——否定
尽管一些供应商宣称他们的J2EE产品有这样的灵活性。不要相信他们！事实你要在开始系统设计时就要


准备集群，而这将影响开发和测试的所有阶段。
8.2.1 Http Session
在集群环境中，如我前面提到的，使用HTTP Session有很多限制，这取决于你的应用程序服务器采用了


那种会话失效转移的机制。第一个重要的限制就是所有保存的HTTP Session中的对象必须是可序列化的


，这将限制设计和应用程序结构。一些设计模式和MVC框架会用HTTP Session保存一些不序列化的对象（


如ServletContext，EJB本地接口和WEB服务引用），这样的设计不能在集群中工作。第二，对象的序列


的反序列化对性能的影响很大，特别是数据库保存的方式。在这样的环境中，应该避免在会话中保存大


的或是众多的对象。如果你采用了内存复制的方式，如前所述你必须小心在会话中属性的交叉引用。其


他在集群环境中的主要区别是在会话不管任何属性修改，你必须调用“setAttribute()”方法。这个方


法调用在独立的系统中是可选的。这个方法的目的是区别已修改的属性和那些没用到属性，这样系统可


以只为失效转移备份必要的数据，从而提高性能。
8.2.2 缓存
我经历过的大多数J2EE项目都用了缓存来提高性能，同时流行的应用程序服务器也都提供了不同程度的


缓存用来加快应用程序的速度。但这些缓存都是为那些典型的独立环境设计的，只能在单JVM实例中工作


。我们需要缓存是因为一些对象很“重”，创建它需花费大量的时间和资源。因此我们维护了对象池用


于重用这些对象，而不需要在后面创建。我们只有当维护缓存比创建对象更廉价时才能获得性能的提高


。在集群环境，每个JVM实例都要维护一份缓存的拷贝，这些拷贝必须同步以维持所有服务器实例状态的


一致性。有时这种类型的同步会比没有缓存带来更糟的性能。
8.2.3 Static变量
当我们设计J2EE应用程序时，在架构上经常会使用一些设计模式。这些如“Singleton”的设计模式会用


到静态变量来在多对象之间共享状态。这种方式在单服务中工作得很好，但在集群环境将失效。集群中


的每个实例都会在它的JVM实例中维护一份静态变量的拷贝，这样就破坏了模式的机制。一个使用静态变


量的例子就是用它来保持在线用户数。用静态变量来保存在线用户数是一个很简单的办法，当用户进入


或离开时就增加和减少它。这种方式在单服务器中绝对是好的，但在集群环境将失效。在集群中更好的


方式是将所有状态保存到数据库。
8.2.4 外部资源
尽管J2EE规范不支持，但为各种目的仍然会用外部I/O的操作。例如，一些应用会使用文件系统来保存用


户上传的文件，或是创建一个动态配置的 XML文件。在集群环境是没有办法来在其他实例之间来复制这


些文件的。为了在集群中工作，办法是用数据库作为外部文件的存放点，另外也可以使用SAN（存储区域


网，Storage Area Network）作为存放点。
8.2.5 特殊服务
一些特殊的服务只在独立的环境中才有意义，定时服务就一个很好例子，这种服务可以在一个固定的间


隔时间有规律的触发。定时服务常用于执行一些自动化管理任务。如日志文件滚动，系统数据备份，数


据库一致性检查和冗余数据清理等。一些基于事件的服务也很难被迁移到集群环境中。初始化服务就是


个好例子，它只在整个系统启动时才发生。邮件通知服务也一样，它在一些警告条件下触发。
这些服务是被事件而不是被请求触发的，而且只被执行一次。这些服务使得负载均衡和失效转移在集群


中没多少意义。
一些产品准备了这些服务，如Jboss使用了“集群单例设施”来协调所有实例，保证执行这些服务一次且


仅有一次。基于你所选择的平台，一些特殊的服务可能会是把你的应用迁移到集群结构中的障碍。
8.3 分布式结构比并置结构更灵活——不一定
J2EE技术，尤其是EJB，天生就是用来做分布式计算。解耦业务功能，重用远程组件，这些使得多层应用


非常流行。但是我们不能将所有的东西都分布。一些J2EE架构师认为Web层与EJB层并置得越近越好。这


些计论后面会继续。先让我解释一下。
 
图 20  分布式结构
如图20所示，这是一个分布式结构。当请求来了，负载均衡器将请求分发到不同服务器中的不同WEB容器


，如果请求包含了EJB调用，WEB容器将重发EJB调用到不同的EJB容器。这样，请求将被负载均衡和失效


转移两次。
一些人看分布式结构，他们会指出：
第二次负载均衡没有必要，因为它不会使任务分配更平坦。每个服务器实例都有它们自己的WEB容器和


EJB容器。把EJB容器用来处理来自其他实例WEB容器的请求比只在服务器内部调用并没有什么优势。
第二次失效转移没有必要，因为它不能是高可用性。多数供应商实现J2EE服务器都会在同一服务器中运


行的WEB容器和EJB容器放在一个JVM实例中。如果EJB容器失效了，多数情况下在同一个JVM中的WEB容器


也将同时失效。
性能将下降。想像一下对你的应用的一次调用包含一组对EJB的调用，如果你负载均衡了这些EJB，这将


跨越每个服务器实例，导致许多不必要的服务器到服务器的交互。还有，如果这个方法在事务范围内，


那么事务边界将包含许多服务器实例，这将严重影响性能。
实际上在运行期，多数的供应商（包括Sun JES，WebLogic和Jboss）都会优化EJB调用机制，使请求首先


选择同一个服务器中的EJB容器。这样，如图21所示，我们只在第一层（WEB层）做负载均衡，然后调用


相同服务器上的服务。这种结构我们称之为并置结构。技术上说，并置结构是分布式结构的一种特例。
 
图 21  并置结构
一个有趣的问题是，既然多数的部署在运行期都演进成了并置结构，为什么不用本地接口代替远程接口


，这将大提高性能。你当然可以，但是记住，当你使用本地接口后，WEB组件和EJB耦合得很紧，而方法


调用也是直接的而不通过RMI/IIOP。负载均衡和失效转移分发器没有机会介入本地接口调用。 “WEB


+EJB”整体处理负载均衡和失效转移。
但不幸的是，在集群中使用本地接口在多数J2EE服务器中有局限性。使用本地接口的EJB是本地对象，是


不可序列化的，这一个限制就使本地引用不能保存在HTTP Session中。一些产品，如Sun JES，会将本地


接口区别看待，使它们可以序列化。这样就可以用在HTTP Session中。
另一个有趣的问题是，既然并置结构这么流行并且有好的性能，为什么还要分布式结构呢？这在多数情


况下是有道理的，但有时分布式结构是不可替代的。
EJB不仅被WEB容器使用，富客户端也会使用它。
EJB组件和WEB组件需在不同的安全级别上，并需要物理分离。这样防火墙将被设置用于保护运行EJB的重


要机器。
WEB层和EJB层极端不对称使得分布式结构是更好的选择。比如，一些EJB组件非常复杂并且很消耗资源，


它们只能运行在昂贵的大型服务器上，另一方面，WEB组件（HTML，JSP和Servlet）简单得只需廉价的PC


服务器就能满足要求。在这种情况下，专门的WEB服务器可以用来接受客户端连接请求，很快处理静态数


据（HTML和图像）和简单的WEB组件（JSP和Servlet）。大型服务器只被用来做复杂计算。这将更好的利


用投资。
9 结论 
集群与独立环境不同，J2EE供应商采用不同的方法来实现集群。如果你的项目为做到高伸缩性而使用集


群，你应该在你的项目开始的时候就做准备。选择符合你的需求的正确的J2EE产品。选择正确的第三方


软件和框架并确保它们能支持集群。最后设计正确的架构使得能从集群中受益而不是受害。
========

数据库集群技术漫谈

简介
    当今世界是一个信息化的世界，我们的生活中无论是生活、工作、学习都离不开信息系统的支撑。


而信息系统的背后用于保存和处理最终结果的地方就是数据库。因此数据库系统就变得尤为重要，这意


味着如果数据库如果面临问题，则意味着整个应用系统也会面临挑战，从而带来严重的损失和后果。


    如今“大数据”这个词已经变得非常流行，虽然这个概念如何落地不得而知。但可以确定的是，随


着物联网、移动应用的兴起，数据量相比过去会有几何级的提升，因此数据库所需要解决的问题不再仅


仅是记录程序正确的处理结果，还需要解决如下挑战：


当数据库性能遇到问题时，是否能够横向扩展，通过添加服务器的方式达到更高的吞吐量，从而充分利


用现有的硬件实现更好的投资回报率。
是否拥有实时同步的副本，当数据库面临灾难时，可以短时间内通过故障转移的方式保证数据库的可用


性。此外，当数据丢失或损坏时，能否通过所谓的实时副本（热备）实现数据的零损失。
数据库的横向扩展是否对应用程序透明，如果数据库的横向扩展需要应用程序端进行大量修改，则所带


来的后果不仅仅是高昂的开发成本，同时也会带来很多潜在和非潜在的风险。
    面对上述挑战一个显而易见的办法是将多个服务器组成一组集群，这样一来就可以充分利用每一台


服务器的资源并将客户端负载分发到不同服务器上，随着应用程序负载的增加，只需要将新的服务器添


加到集群即可。


    本篇文章将对集群的概念、形式以及目前主流的数据库集群技术进行探讨。


数据库集群的形式
    数据库的集群和扩展不像应用程序扩展那样容易，因为从数据库端来说，一旦涉及到了集群，往往


会涉及到数据库层面的同步，因此从是否存在数据冗余这个角度来讲，我们可以从大面上把数据库集群


分为以下两种形式：


Share-Disk架构


    Share-Disk架构是通过多个服务器节点共享一个存储来实现数据库集群，两台机器最简单的Share-


Disk架构如图1所示。
1
    图1.简单的Share-Disk架构
    在此基础之上，Share-Disk架构又分为单活和双活，双活即为集群中的每一个节点都可以同时对外


提供服务，而单活为集群中只有一个节点可对外提供服务，集群中的其他服务器作为冗余在“活”的节


点出现故障时接替该服务器成为对外提供服务的节点。该类架构最典型的产品就是SQL Server Failover 


Cluster(SQL Server故障转移集群)、NEC的EXPRESSCLUSTER、ROSE的ROSE HA。这种方式的弊端也是显而


易见的，如下：


硬件资源的严重浪费，同一时间集群中只有一台服务器活着，其他服务器只能作为冗余服务器。
集群无法提升性能，因为只有一台服务器可用
存储方面存在单点故障，除非在存储层级保证高可用，通常需要昂贵的SAN存储。
    因此该类方案仅仅可以做到服务器层面的高可用，无法带来性能的提升，也无法解决存储单点故障


的问题。因此如果不搭配其他高可用或负载均衡的技术，存在的意义并不是很大。


    另一类技术是Share-Disk中的双活的技术，与单活技术不同的是，双活的技术虽然也是共享磁盘，


但集群中的所有节点都可以对外提供服务，典型的产品就是Oracle的RAC。RAC的技术性非常的高，因此


需要水平比较高的人来运维系统。RAC设计的初衷并不是为了性能，而是为了高可用和可扩展性，如果应


用程序不是针对RAC架构设计和开发的，则将应用程序迁移到RAC上由于block contention (block busy 


waits)可能会导致性能的急剧下降，并且节点越多性能下降越明显。


Share-Nothing架构


    Share-Nothing架构又分为两种，首先是分布式架构。将数据库中的数据按照某一标准分布到多台机


器中，查询或插入时按照条件查询或插入对应的分区。


    另一种是每一个节点完全独立，节点之间通过网络连接，通常是通过光钎等专用网络。如图2所示。
2


图2.Share-Nothing冗余架构


    在Share-Nothing架构中，每一个节点都拥有自己的内存和存储，都保留数据的完整副本。通常来说


，又可以分为两种，可以负载均衡和不可以负载均衡。


    首先谈谈不可负载均衡的集群，在不可负载均衡的技术中，集群中的节点会被分为主节点和辅助节


点，主节点向外提供服务，辅助节点作为热备（二阶段事务提交）或暖备（不需要保证事务同步），同


时有可能使得辅助节点提供只读的服务。使用这个架构的技术包括：SQL Server AlwaysOn，SQL Server 


Mirror，Oracle Data Guard这种架构带来的好处包括：


辅助节点数据和主节点保持同步或准同步，当搭配第三方仲裁后，可以实现自动的故障转移，从而实现


了高可用
辅助节点由于和主节点完全独立且数据同步或准同步，因此主节点出现数据损坏后，可以从辅助节点恢


复数据（自动或手动）
由于Share-Nothing架构使用了本地存储（或SAN），相较于Share-Disk架构在慢速网络时有非常大的性


能优势
 
     当然，弊端也显而易见，因为辅助节点无法对外提供服务或只能提供只读服务，因此该类集群的弊


端包括：


扩展能力非常有限
对性能没有提升，因为涉及到各节点的数据同步，甚至带来性能的下降
辅助节点如果可读，虽然提升性能，但需要修改前端应用程序，对应用程序不透明


     另一类Share-Nothing架构中，是允许负载均衡的。所谓负载均衡就是就是将对数据库的负载分布


到集群中的多个节点上，在集群中的每一个节点都可以对外提供服务，从而达到更高的吞吐量，更好的


资源利用率和更低的响应时间。前端通过代理进行调度。使用该类架构的技术包括：MySQL上的Amoeba(


架构如图3，摘自MySQL大师陈畅亮的博客：


http://www.cnblogs.com/gaizai/archive/2012/06/12/2546755.html)，MySQL上的HA Proxy（如图4所


示），格瑞趋势(www.grqsh.com)在SQL Server上的Moebius集群(如图5所示)。


3


图3.Amoeba


5


图4.HA Proxy
4


图5.Moebius集群


    可负载均衡的Share-Nothing架构的好处是每台服务器都能提供服务，能充分利用现有资源，达到更


高的吞吐量。其中Amoeba中可能会涉及到数据分片，数据分片的好处是对于海量数据的处理更加高效，


但同时也引入了其他问题，比如说需要应用程序端对应数据分片进行调整、跨分片节点查询的处理问题


、每一个数据分片节点是否能够承受各自业务负载的高峰问题等。该类架构需要实施的人员水平比较高


，且需要应用层面做调整，因此更适合于互联网企业。


    另一类不涉及到数据分片的架构，比如一类可以使用组合方案，比如说Oracle RAC+F5。另一类是使


用单个厂商提供的方案，比如说SQL Server上的Moebius。这类方案集群中的每个节点都会对外提供服务


，因此有如下好处：


由于每一个节点都可以对外提供服务，因此可以提升性能
扩展性得到提升，可以通过向集群添加节点直接进行Scale-Out扩充
由于前端应用通过代理连接到集群，而集群中的每一个节点都保持完整的数据集，因此不存在分片不到


位反而造成性能下降的问题，因此对应用程序端完全透明
 


    但相比较于MySQL的数据分片，该类方案的弊端也显而易见，因为每一个节点都需要完整的数据集，


因此需要占用更多的存储空间。


小结
    本文从一个比较高的层面谈到了数据库集群技术。从数据库应用层面的Share-Disk集群直到集群的


最高形式-能够提供负载均衡的集群，并列举了一些主流的商用产品。集群的存在意义是为了保证高可用


、数据安全、扩展性以及负载均衡。如果现在的集群产品不能包含这几个特性，而业务场景也需要，也


可以将和一些现有的技术结合来实现，但毕竟不是每一个人都是数据库专家，即使给你一堆工具和材料


你也做不出来iPhone，因此在系统设计之初就对数据库方面的方案有所考虑会免去很多麻烦。
========