第⼀章集群的概念和发展1集群的概念1.1集群相关术语定义1.1.1服务硬件
服务硬件是指提供计算服务的硬件，⽐如PC机、PC服务器。1.1.2服务实体
服务实体通常指服务软体和服务硬体。1.1.3节点（node）
运⾏Heartbeat进程的⼀个独⽴主机称为节点，节点是HA的核⼼组成部分，每个节点上运⾏着操作系统和Heartbeat软件服务。在Heartbeat集群中，节点有主次之分，分别称为主节点和备⽤/备份节点，每个节点拥有⼀个唯⼀的主机名，并且拥有属于⾃⼰的⼀组资源，例如磁盘、⽂件系统、⽹络地址和应⽤服务等。主节点上⼀般运⾏着⼀个或者多个应⽤服务，⽽备⽤节点⼀般处于监控状态。1.1.4资源（resource）
资源是⼀个节点可以控制的实体，当节点发⽣故障时，这些资源能够被其他节点接管。在Heartbeat中，可以当做资源的实体如下：
(⼀)磁盘分区、⽂件系统(⼆)IP地址(三)应⽤程序服务(四)共享存储1.1.5事件（event）
事件也就是集群中可能发⽣的事情，例如节点系统故障、⽹络连通故障、⽹卡故障和应⽤程序故障等。这些事件都会导致节点的资源发⽣转移，HA的测试也是基于这些事件进⾏的。1.2什么是集群
简单的说，集群（cluster）就是⼀组计算机，它们作为⼀个整体向⽤户提供⼀组⽹络资源，这些单个的计算机系统就是集群的节点（node）。⼀个理想的集群是，⽤户从来不会意识到集群系统底层的节点，在他们看来，集群是⼀个系统，⽽⾮多个计算机系统；并且集群系统的管理员可以随意的增加和删改集群系统的节点。与单⼀服务实体相⽐较，集群提供了以下两个关键的特性。
(⼀)可扩展性。集群的性能不限于单⼀的服务实体，新的服务实体可以动态的加⼊到集群，从⽽增强集群的性能。
(⼆)⾼可⽤性。集群通过服务实体冗余使客户端免于轻易遭遇到“out of service”警告。当⼀台节点服务器发⽣故障的时候，这台服务器上所运⾏的应⽤程序将在另⼀节点服务器上被⾃动接管。消除单点故障对于增强数据可⽤性、可达性和可靠性是⾮常重要的。
为了具有可扩展性和⾼可⽤性的特点，集群必须具备以下两⼤能⼒。
(⼀)负载均衡。负载均衡能把任务⽐较均匀的分布到集群环境下的计算和⽹络资源，以便提⾼数据吞吐量。
(⼆)错误恢复。如果集群中的某⼀台服务器由于故障或者维护需要⽽⽆法使⽤，资源和应⽤程序将转移到可⽤的集群节点上。这种由于某个节点中的资源不能⼯作，另⼀个可⽤节点中的资源能够透明的接管并继续完成任务的过程叫做错误恢复。负载均衡和错误恢复都要求各服务实体中有执⾏同⼀任务的资源存在，⽽且对于同⼀任务的各个资源来说，执⾏任务所需的信息视图（信息上下⽂）必须是相同的。分布式与集群的联系与区别如下：
(⼀)分布式是指将不同的业务分布在不同的地⽅。
(⼆)⽽集群指的是将⼏台服务器集中在⼀起，实现同⼀业务。
(三)分布式的每⼀个节点，都可以做集群，⽽集群并不⼀定就是分布式的。
⽐如互联⽹上访问的⼈多了，就可以做⼀个集群，前⾯放⼀个响应服务器，后⾯⼏台服务器完成同⼀业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将任务交给哪台去完成。
⽽分布式，从狭义上理解，也与集群差不多，但是它的组织⽐较松散，不像集群，有⼀定组织性，⼀台服务器宕了，其他的服务器可以顶上来。分布式的每⼀个节点，都完成不同的业务，⼀个节点宕了，这个业务就不可访问了。1.3集群技术
实现集群⽆必要有以下两⼤技术：●集群地址
集群由多个服务实体组成，集群客户端通过访问集群的集群地址获取集群内部各服务实体的功能。具有单⼀集群地址（也叫单⼀影像）是集群的⼀个基本特征。维护集群地址的设置称为负载均衡器。负载均衡器内部负责管理各个服务实体的加⼊和退出，外部负责集群地址向内部服务实体地址的转换。有的负载均衡器实现真正的负载均衡算法，有的只⽀持任务的转换。只实现任务转换的负载均衡器适⽤于⽀持ACTIVE-STANDBY的集群环境，在那⾥，集群中只有⼀个服务实体⼯作，当正在⼯作的服务实体发⽣故障的时候，负载均衡器把后来的任务转向另外⼀个服务实体。●内部通信
为了能协同⼯作，实现负载均衡和错误恢复，集群各实体之间必须时常通信，⽐如负载均衡器对服务实体⼼跳测试信息、服务实体间任务执⾏上下⽂信息的通信。
具有同⼀个集群地址使得客户端能访问集群提供的计算服务，⼀个集群地址下隐藏了各个服务实体的内部地址，使得客户要求的计算服务能在各个服务实体之间分布。内部通信是集群能够正常运转的基础，它使集群具有负载均衡和错误恢复的能⼒。1.4集群分类
集群主要分成三⼤类：
●⾼可⽤集群（High Availability Cluster）。
常见的就是两个节点做成的HA集群，它还有很多通俗的不科学的名称，⽐如“双机热备”、“双机互备”、“双机”。⾼可⽤集群保障⽤户应⽤程序持续对外提供服务的能⼒（注意⾼可⽤集群不是⽤来保护业务数据的，⽽是确保⽤户的业务程序对外不间断提供服务，把因软件、硬件、⼈为造成的故障对业务的影响降低到最⼩程度）。●负载均衡集群/负载均衡系统（Load Balance Cluster）
集群中所有的节点都处于活动状态，他们分摊系统的⼯作负载。⼀般Web服务器集群、数据库集群和应⽤服务器集群都属于这种类型。负载均衡集群⼀般⽤于相应⽹络请求的⽹页服务器和数据库服务器。这种集群可以在接到请求时，检查接受请求较少、不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这⼀点上看，负载均衡和容错集群很接近，不同之处是数量上更多。
●科学计算集群（High Performance Computing Cluster）/⾼性能计算（High Performance Computing）集群。
简称HPC集群，这类集群致⼒于提供单个计算机所不能提供的强⼤的计算能⼒。⾼性能计算，可以把它分成若⼲可以并⾏的⼦任务，⽽且各个⼦任务彼此之间没有什么关联。这种类型的应⽤的⼀个共同特征是在海量数据上搜索某些模式，所以把这类计算称为⾼吞吐计算。2操作系统集群
从单⼀处理机主机到多节点皆可构成⾼可⽤性之集群，可混⽤，且跨越系统⼤⼩及性能等级，将各种⽹络适配卡和磁盘⼦系统融合在⼀起来，以满⾜⽤户的应⽤程序、⽹络等⽅⾯的需求。
操作系统集群因不同的处理需求可以构成三种不同的模式：并⾏模式、互备模式、主备模式。
(⼀)同时访问模式（并⾏模式）适⽤在所有处理机必须在相同的⼯作负载及在相同的时间共享相同的数据之环境。(⼆)相互备援模式则是集群中的各个节点分别承担应⽤和任务，并且各个节点之间相互备援。(三)热待机模式则为⼀节点备援任何集群上的另⼀节点。
⽆论选择哪⼀种备援模式，集群所提供的数据访问及备援⽅案都将应⽤程序的执⾏及增长性在避免不正常死机状况下做了最优化处理。
3存储集群
作为⼀项被⼴泛应⽤的技术，集群可提供按任何⽐例增加服务器或者存储资源的性能、容量、可靠性及可⽤性，突破了单机设备的种种限制。传统的存储系统由于受到其物理组成（如磁盘驱动器的数量、所连接服务器的数量、内存⼤⼩和控制器性能）的限制，会造成很多功能上的局限（如⽀持⽂件系统的数量、快照或者复制的数量等）。⼀旦遇到存储系统的瓶颈，就会不断的促使⽤户升级到更⼤的存储系统并添加更多的管理⼯具。3.1集群中可调整的特性
●性能（带宽、IOPS——每秒输⼊输出次数等）可提⾼到满⾜⼤型顺序读或写操作，或者是对时间敏感（Time-Sensitive）的随机读写⾯向事务型处理。
●可⽤性——消除单点故障、透明故障的转移（Failover），提⾼⾃我修复（Self-Heading）能⼒。●存储容量和服务的连接访问（FC、以太⽹和InfiniBand接⼝）。
●可访问性（Accessibility）——包含块级（iSCSI、FC和InfiniBand）或者NAS（NFS、CIFS或者其他私有⽂件系统）和数据共享。
●基于开放或者私有的硬件和软件，使⽤紧密或者松散的互联技术来实现完全不共享、部分共享或完全共享架构（SharedNothing、Shared Something or Shared Everything Architectures）。
通过下表可以看到很多不同类型的集群存储⽅案，其中包括集群和并⾏⽂件系统、集群⽂件服务器、集群NAS、集群iSCSI和FC存储等。⼤多数的集群实现⽅式都满⾜了容量和可⽤性的需求。⼀些集群存储⽅案也⽀持通过控制吞吐量和I/O操作⽅式来对性能进⾏调整，以达到简化和使⽤、管理的⽬的。表格：集群存储的众多特征和例⼦
件级）、可⽤性或者使⽤的难易程度⼏⽅⾯来考核。集群存储并⾮就是那些⾼不可攀的、联合HPC（⾼性能计算）环境⼀起使⽤的⼤型顺序带宽（Sequential Bandwidth）或者并⾏⽂件系统代名词。多⽤途的集群系统⽀持传统的商业应⽤，如电⼦邮件、数据库和在线事务处理（OLTP）等。3.2满⾜不同应⽤性能和服务的需求
清除单点故障对于增强数据可⽤性、可达性和可靠性是⾮常重要的。集群⽅案可以有效防⽌单点故障的发⽣，其N+1冗余特性，以及部件的热插拔特性和⾃我诊断能⼒可保证在错误造成⿇烦前就将其发现、隔离并排除。
还有⼀种具有X+1冗余架构的存储系统⼀直处于灰⾊地带，⼈们对其是否属于集群还存在争议。在N+1冗余架构模式中，存在两个或者更多个（N个）主要I/O节点或控制器，也就是所谓的NAS头和备⽤或故障转移节点，例如EMC的Celerra NSX和Pillar Axiom。是⼚商的命名体系才使得这种N+1模式显得⼗分混乱，如将包含有双控制器的RAID阵列或者双NAS头的⽅案称作提⾼可⽤性的集群。
⼀个集群就是⼀个Gird（⽹格）么?这取决于对Gird的定义，把Gird看做是⼀项服务、架构，还是基于硬件或软件的、跨越距离的其他能⼒。对于怎样才算服务器和存储环境组成了⼀个Gird或者集群这件事情，存在着很多不同的⼚商和⾏业定义和意见。各种集群存储⽅案中的不同之处包括以下⼏个⽅⾯。
1.节点彼此之间如何连接（松散的或紧密的连接，开放或者私有）。2.节点间的I/O性能和负载平衡。
3.适当的硬件、开发和现有产品（off-the-shelf）或⽀持第三⽅服务器或者存储。4.⽂件共享，包含集群⽂件系统软件，基于主机的代理或者驱动。5.本地或者远程的镜像或者复制，及时点（Point-in-time）复制或者快照。
6.具备虚拟化的存储块增长，实现⾃动负载均衡。7.性能⾃适应顺序读写或者随机访问。
8.分布式锁管理（Distributed Lock Management）和集群特性⼀致。
理解集群存储间的不同的含义、类型和实现⽅式，将帮助⽤户挑选最合适的⽅案。集群存储⾮常适合那些持续增长的所有规模的不同环境，实现即时供应（Just-in-time）存储，避免破快性升级和增加管理的复杂性。4Web应⽤集群
Web应⽤服务器集群系统，是由⼀群同时运⾏同⼀个Web应⽤的服务器组成的集群系统，在外界看来，就像是⼀个服务器⼀样。为了均衡集群服务器的负载，达到优化系统性能的⽬的，集群服务器将众多的访问请求分散到系统中的不同节点进⾏处理。从⽽实现更⾼的有效性和稳定性，⽽这也正是基于Web的企业应⽤所必须具备的特性。
⾼可靠性可以看做为系统的⼀种冗余设定。对于⼀个特定的请求，如果所申请的服务器不能进⾏处理的话，那么其他的服务器能不能对之进⾏有效的处理呢？对于⼀个⾼效的系统，如果⼀个Web服务器失败的话，其他的服务器可以马上取代它的位置，对所申请的请求进⾏处理，⽽且这⼀过程对于⽤户来说，要尽可能的透明，使⽤户察觉不到。
稳定性决定了应⽤程序能否⽀持不断增长的⽤户请求数量，它是应⽤程序⾃⾝的⼀种能⼒。稳定性是影响系统性能的众多因素中的⼀种有效的测量⼿段，包括集群系统所能⽀持的同时访问系统的最⼤⽤户数⽬以及处理⼀个请求所需要的时间。在现有众多的均衡负载器负载的⽅法中，⼴泛研究并使⽤的是以下两个⽅法。●DNS负载平衡的⽅法RR-DNS（Round-Robin Domain Name System）●负载均衡器5数据库集群
数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个⼤型服务器的技术，这种技术不但能满⾜应⽤的需要，⽽且⼤幅度的节约了投资成本。数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库⽹关（中间件）的集群技术。
在数据库集群产品⽅⾯，其中主要包括基于数据库引擎的集群技术的Oracle RAC、Microsoft MSCS、IBM DB2 UDB、Sybase ASE，以及基于数据库⽹关（中间件）的集群技术的ICX-UDS等产品。5.1为什么搭建数据库集群
随着经济的⾼速发展，企业规模的迅猛扩张，企业⽤户的数量、数据量的爆炸式增长，对数据库提出了严峻的考验。对于所有的数据库⽽⾔，除了记录正确的处理结果之外，还⾯临着以下⼏⽅⾯的挑战。如何提⾼处理速度，实现数据库的均衡负载。
如何保证数据库的可⽤性、数据安全性、以及如何实现数据集群可扩性。怎么综合解决这些问题成为众多企业关注的焦点。
随着计算机硬件技术的⾼速发展，PC服务器以其⾼性能和低廉的价格⽽倍受⼴⼤客户青睐，在Web应⽤或者⾼性能计算中，为了追求更好的性能以及可⽤性，⼤家都采⽤计算机集群技术（将多台服务器联合起来组成集群来实现综合性能优于单个⼤型服务器的技术）来实现，这种技术不但能满⾜应⽤的需要，⽽且⼤幅度的节约了投资成本。在数据库上，组建集群也是同样的道理，主要有以下⼏个原因：
(⼀)伴随着企业的成长，在业务量提⾼的同时，数据库的访问量和数据量快速增长，其处理能⼒和计算速度也相应增⼤，使得单⼀的设备根本⽆法承担。
(⼆)在以上情况下，若扔掉现有设备，做⼤量的硬件升级，势必造成现有资源的浪费，⽽且下⼀次业务量提升时，⼜将⾯临再⼀次硬件升级的⾼额投⼊。于是，⼈们希望通过⼏个中⼩型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更⾼数据库处理速度时，只要简单的增加数据库服务器就可以得到扩展。
(三)数据库作为信息系统的核⼼，起着⾮常重要的作⽤，单⼀设备根本⽆法保证系统的下持续运⾏，若发⽣系统故障，将严重影响系统的正常运⾏，甚⾄带来巨⼤的经济损失。于是，⼈们希望通过组建数据库集群，实现数据库的⾼可⽤，当某节点发⽣故障时，系统会⾃动检测并转移故障节点的应⽤，保证数据库的持续⼯作。
(四)企业的数据库保存着企业的重要信息，⼀些核⼼数据甚⾄关系着企业的命脉，单⼀设备根本⽆法保证数据库的安全性，⼀旦发⽣丢失，很难再找回来。于是，⼈们希望通过组建数据库集群，实现数据集的冗余，通过备份数据来保证安全性。5.2数据库集群的分类
⼀般来讲，数据库集群软件侧重的⽅向和试图解决的问题划分为三⼤类：
●负载均衡集群（Load Balance Cluster，LBC）侧重于数据库的横向扩展，提升数据库的性能。
●⾼可⽤性集群（High Availability Cluster，HAC）侧重保证数据库应⽤持续不断。⼤部分的数据库集群侧重与此。
●⾼安全性集群（High Security Cluster，HSC）侧重于容灾。只有Oracle RAC能实现以上三⽅⾯。5.3数据库集群按架构分类5.3.1可扩展的分布式数据库架构
数据库的可⽤性和扩展性⼀直是数据库⼚商和⽤户最关注的问题。过去我们不断采⽤⾼端的设备，⽐如使⽤⼩型机和⼤型存储来保证数据库的可⽤性。⽽扩展性主要采⽤向上扩展（scale up）的⽅式，通过增加CPU、内存、磁盘等⽅式提⾼处理能⼒。这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，已经越来越
不适应海量数据对计算能⼒的巨⼤需求。近些年来，分布式系统成为了⼀种趋势，⼈们希望⽤廉价的设备堆叠出具备⾼可⽤性和⾼扩展性的计算集群，从⽽摆脱对⼤型设备的依赖。数据库作为系统架构中的重要组成部分，如何做到既提供⾼可⽤性⼜具备向外扩展（Scale out）的能⼒，数据库⼚商和⽤户都做了很多的探索。(⼀)Oracle RAC
⼏乎每个数据库产品都有集群解决⽅案，Oracle RAC是业界最流⾏的产品。其架构的最⼤特点是共享存储架构（Shared-storage），整个RAC集群是建⽴在⼀个共享的存储设备之上的，节点之间采⽤⾼速⽹络互联。Oracle RAC提供了⾮常好的⾼可⽤特性，⽐如负载均衡和应⽤透明切块（TAF），其最⼤的优势在于对应⽤完全透明，应⽤⽆需修改便可切换到RAC集群。但是RAC的可扩展能⼒有限，⾸先因为整个集群都依赖于底层的共享存储，所以共享存储的I/O能⼒和可⽤性决定了整个集群的可以提供的能⼒，对于I/O密集型的应⽤，这样的机制决定后续扩容只能是Scale up（向上扩展）类型，对于硬件成本、开发⼈员的要求、维护成本都相对⽐较⾼。Oracle 显然也意识到了这个问题，在Oracle的MAA（Maximum Availability
Architecture）架构中，采⽤ASM来整合多个存储设备的能⼒，使得RAC底层的共享存储设备具备线性扩展的能⼒，整个集群不再依赖于⼤型存储的处理能⼒和可⽤性。
RAC的另外⼀个问题是，随着节点数的不断增加，节点间通信的成本也会随之增加，当到达某个限度时，增加节点可能不会再带来性能上的提⾼，甚⾄可能造成性能下降。这个问题的主要原因是Oracle RAC对应⽤透明，应⽤可以连接集群中的任意节点进⾏处理，当不同节点上的应⽤争⽤资源时，RAC节点间的通信开销会严重影响集群的处理能⼒。所以对于使⽤ORACLERAC有以下两个建议：
●节点间通信使⽤⾼速互联⽹络；
●尽可能将不同的应⽤分布在不同的节点上。
基于这个原因，Oracle RAC通常在DSS环境中可以做到很好的扩展性，因为DSS环境很容易将不同的任务分布在不同计算节点上，⽽对于OLTP应⽤，Oracle RAC更多情况下⽤来提⾼可⽤性，⽽不是为了提⾼扩展性。(⼆)MySQL Cluster
MySQL cluster和Oracle RAC完全不同，它采⽤Shared-nothing架构。整个集群由管理节点(ndb_mgmd)，处理节点(mysqld)和存储节点(ndbd)组成，不存在⼀个共享的存储设备。MySQL cluster主要利⽤了NDB存储引擎来实现，NDB存储引擎是⼀个内存式存储引擎，要求数据必须全部加载到内存之中。数据被⾃动分布在集群中的不同存储节点上，每个存储节点只保存完整数据的⼀个分⽚(fragment)。同时，⽤户可以设置同⼀份数据保存在多个不同的存储节点上，以保证单点故障不会造成数据丢失。
MySQL cluster主要由3各部分组成：●SQL服务器节点●NDB数据存储节点●监控和管理节点
这样的分层也是与MySQL本⾝把SQL处理和存储分开的架构相关系的。
MySQL cluster的优点在于其是⼀个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可⽤性和扩展性都可以做到很⾼，更适合OLTP应⽤。但是它的问题在于：
●NDB存储引擎必须要求数据全部加载到内存之中，限制⽐较⼤，但是⽬前NDB新版本对此做了改进，允许只在内存中加载索引数据，数据可以保存在磁盘上。
●⽬前的MySQL cluster的性能还不理想，因为数据是按照主键hash分布到不同的存储节点上，如果应
⽤不是通过主键去获取数据的话，必须在所有的存储节点上扫描，返回结果到处理节点上去处理。⽽且，写操作需要同时写多份数据到不同的存储节点上，对节点间的⽹络要求很⾼。
虽然MySQL cluster⽬前性能还不理想，但是share nothing的架构⼀定是未来的趋势，Oracle接⼿MySQL 之后，也在⼤⼒发展MySQL cluster，我对MySQL cluster的前景抱有很⼤的期待。(三)分布式数据库架构
⽬前，除了数据库⼚商的集群产品以外，解决数据库扩展能⼒的⽅法主要有两个：数据分⽚和读写分离。数据分⽚(Sharding)的原理就是将数据做⽔平切分，类似于hash分区的原理，通过应⽤架构解决访问路由和数据合并的问题。
\"Shard\" 这个词英⽂的意思是\"碎⽚\"，⽽作为数据库相关的技术⽤语，似乎最早见于⼤型多⼈在线⾓⾊扮演游戏(MMORPG)中。\"Sharding\" 姑且称之为\"分⽚\"。
Sharding 不是⼀门新技术，⽽是⼀个相对简朴的软件理念。如您所知，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多MySQL 的潜在⽤户都对MySQL 的扩展性有所顾虑，⽽是否具备分区功能就成了衡量⼀个数据库可扩展性与否的⼀个关键指标(当然不是唯⼀指标)。数据库扩展性是⼀个永恒的话题，MySQL 的推⼴者经常会被问到：如在单⼀数据库上处理应⽤数据捉襟见肘⽽需要进⾏分区化之类的处理，是如何办到的呢? 答案是：Sharding。
Sharding 不是⼀个某个特定数据库软件附属的功能，⽽是在具体技术细节之上的抽象处理，是⽔平扩展(Scale Out，亦或横向扩展、向外扩展)的解决⽅案，其主要⽬的是为突破单节点数据库服务器的I/O 能⼒限制，解决数据库扩展性问题。⽬前的商业数据都有⾃⼰的扩展性解决⽅案，在过去相对来说⽐较成熟，但是随着互联⽹的⾼速发展，不可避免的会带来⼀些计算模式上的演变，这样很多主流商业系统也难免暴露出⼀些不⾜之处。⽐如Oracle 的RAC 是采⽤共享存储机制，对于I/O 密集型的应⽤，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是Scale Up（向上扩展）类型，对于硬件成本、开发⼈员的要求、维护成本都相对⽐较⾼。Sharding 基本上是针对开源数据库的扩展性解决⽅案，很少有听说商业数据库进⾏Sharding 的。⽬前业界的趋势基本上是拥抱Scale Out，逐渐从Scale Up 中解放出来。
Sharding架构的优势在于，集群扩展能⼒很强，⼏乎可以做到线性扩展，⽽且整个集群的可⽤性也很⾼，部分节点故障，不会影响其他节点提供服务。Sharding原理简单，容易实现，是⼀种⾮常好的解决数据库扩展性的⽅案。联机游戏、IM、BSP 都是⽐较适合Sharding 的应⽤场景。但是Sharding对应⽤场景的要求很⾼，因为⼀旦使⽤数据分⽚架构，如果需要跨不同的节点做join，或者统计类型的操作，将会变得⾮常困难，应该尽量避免。所以说Sharding架构会损失部分关系型数据库的特性，⽐如join，从⽽使数据库退化为Key-Value store 类型的存储。所以，Sharding 并不是数据库扩展⽅案的银弹，也有其不适合的场景，⽐如处理事务型的应⽤，它可能会造成应⽤架构复杂或者限制系统的功能，这也是它的缺陷所在。
读写分离是架构分布式系统的⼀个重要思想。不少系统整体处理能⼒并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能⼀劳永逸。针对业务类型特点，需要从架构模式上进⾏⼀系列的调整，⽐如业务模块的分割，数据库的拆分等等。
集中式和分布式是两个对⽴的模式，不同⾏业的应⽤特点也决定了架构的思路。如互联⽹⾏业中⼀些门户站点，出于技术和成本等⽅⾯考虑，更多的采⽤开源的数据库产品(如MYSQL)，由于⼤部分是典型的读多写少的请求，因此为MYSQL及其复制技术⼤⾏其道提供了条件。⽽相对⼀些传统密集交易型的⾏业，⽐如电信业、⾦融业等，考虑到单点处理能⼒和可靠性、稳定性等问题，可能更多的采⽤商⽤数据库，⽐如DB2、Oracle等。
就数据库层⾯来讲，⼤部分传统⾏业核⼼库采⽤集中式的架构思路，采⽤⾼配的⼩型机做主机载体，因为数据库本⾝和主机强⼤的处理能⼒，数据库端⼀般能⽀撑业务的运转，因此，Oracle读写分离式的架构相对MYSQL来讲，相对会少。
读写分离架构利⽤了数据库的复制技术，将读和写分布在不同的处理节点上，从⽽达到提⾼可⽤性和扩展性的⽬的。最通常的做法是利⽤MySQL Replication技术，Master DB承担写操作，将数据变化复制到多台Slave DB 上，并承担读的操作。这种架构适合read-intensive类型的应⽤，通过增加Slave DB的数量，读的性能可以线性增长。为了避免Master DB的单点故障，集群⼀般都会采⽤两台Master DB做双机热备，所以整个集群的读和写的可⽤性都⾮常⾼。除了MySQL，Oracle从11g开始提供Active Standby的功能，也具备了实现读写分离架构的基础。读写分离架构的缺陷在于，不管是Master还是Slave，每个节点都必须保存完整的数据，如果在数据量很⼤的情况下，集群的扩展能⼒还是受限于单个节点的存储能⼒，⽽且对于Write-intensive类型的应⽤，读写分离架构并不适合。
采⽤Oracle读写分离的思路，Writer DB和Reader DB采⽤⽇志复制软件实现实时同步；Writer DB负责交易相关的实时查询和事务处理，Reader DB负责只读接⼊，处理⼀些⾮实时的交易明细,报表类的汇总查询等。同时，为了满⾜⾼可⽤性和扩展性等要求，对读写端适当做外延，⽐如Writer DB采⽤HA或者RAC的架构模式，
Reader DB可以采⽤多套，通过负载均衡或者业务分离的⽅式，有效分担读库的压⼒。
对于Shared-nothing的数据库架构模式，核⼼的⼀个问题就是读写库的实时同步；另外，虽然Reader DB 只负责业务查询，但并不代表数据库在功能上是只读的。只读是从应⽤⾓度出发，为了保证数据⼀致和冲突考虑，因为查询业务模块可能需要涉及⼀些中间处理，如果需要在数据库⾥⾯处理(取决与应⽤需求和设计)，所以Reader DB在功能上仍然需要可写。下⾯谈⼀下数据同步的技术选型问题：
能实现数据实时同步的技术很多，基于OS层(例如VERITAS VVR)，基于存储复制(中⾼端存储⼤多都⽀持)，基于应⽤分发或者基于数据库层的技术。因为数据同步可能并不是单⼀的DB整库同步，会涉及到业务数据选择以及多源整合等问题，因此OS复制和存储复制多数情况并不适合做读写分离的技术⾸选。
基于⽇志的Oracle复制技术，Oracle⾃⾝组件可以实现，同时也有成熟的商业软件。选商业的独⽴产品还是Oracle⾃⾝的组件功能，这取决于多⽅⾯的因素。⽐如团队的相应技术运维能⼒、项⽬投⼊成本、业务系统的负载程度等。
采⽤Oracle⾃⾝组件功能，⽆外乎Logical Standby、Stream以及11g的Physical Standby(Active Data Guard)，对⽐来
说，Stream最灵活，但最不稳定，11g Physical Standby⽀持恢复与只读并⾏，但由于并不是⽇志的逻辑应⽤机制，在读写分离的场景中最为局限。如果技术团队对相关技术掌握⾜够充分，⽽选型⽅案的处理能⼒⼜能⽀撑数据同步的要求，采⽤Oracle⾃⾝的组件完全可⾏。
选择商业化的产品，更多出于稳定性、处理能⼒等考虑。市⾯上成熟的Oracle复制软件也⽆外乎⼏种，⽆论是⽼牌的
Shareplex，还是本⼟DSG公司的RealSync和九桥公司的DDS，或是Oracle新贵Goldengate，都是可供选择的⽬标。随着GoldenGate被Oracle收购和推⼴，个⼈认为GoldenGate在容灾、数据分发和同步⽅⾯将⼤⾏其道。当然，架构好⼀个可靠的分布式读写分离的系统，还需要应⽤上做⼤量设计，不在本⽂讨论范围内。(四)CAP和BASE理论分布式领域CAP理论：
●Consistency(⼀致性), 数据⼀致更新，所有数据变动都是同步的●Availability(可⽤性), 好的响应性能●Partition tolerance(分区容错性) 可靠性
定理：任何分布式系统只可同时满⾜⼆点，没法三者兼顾。
忠告：架构师不要将精⼒浪费在如何设计能满⾜三者的完美分布式系统，⽽是应该进⾏取舍。关系数据库的ACID模型拥有⾼⼀致性+ 可⽤性很难进⾏分区：
●Atomicity原⼦性：⼀个事务中所有操作都必须全部完成，要么全部不完成。●Consistency⼀致性. 在事务开始或结束时，数据库应该在⼀致状态。●Isolation隔离层. 事务将假定只有它⾃⼰在操作数据库，彼此不知晓。●Durability. ⼀旦事务完成，就不能返回。(五)跨数据库事务
2PC (two-phase commit)，2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，也就是说传统关系型数据库要想实现⼀个分布式数据库集群⾮常困难，关系型数据库的扩展能⼒⼗分有限。⽽近年来不断发展壮⼤的NoSQL运动，就是通过牺牲强⼀致性，采⽤BASE模型，⽤最终⼀致性的思想来设计分布式系统，从⽽使得系统可以达到很⾼的可⽤性和扩展性。那么，有没有可能实现⼀套分布式数据库集群，既保证可⽤性和⼀致性，⼜可以提供很好的扩展能⼒呢？BASE模型反ACID模型，完全不同ACID模型，牺牲⾼⼀致性，获得可⽤性或可靠性：
●Basically Available基本可⽤。⽀持分区失败(e.g. sharding碎⽚划分数据库)●Soft state软状态状态可以有⼀段时间不同步，异步。
●Eventually consistent最终⼀致，最终数据是⼀致的就可以了，⽽不是时时⾼⼀致。BASE思想的主要实现有●按功能划分数据库
●sharding碎⽚
BASE思想主要强调基本的可⽤性，如果你需要High 可⽤性，也就是纯粹的⾼性能，那么就要以⼀致性或容错性为牺牲，BASE思想的⽅案在性能上还是有潜⼒可挖的。
现在NoSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别⽅案，⽐如忽视⼀致性，获得⾼可⽤性等等，NOSQL应该有下⾯两个流派：
●Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。●领域模型+ 分布式缓存+ 存储（Qi4j和NoSQL运动），可根据CAP三原则结合⾃⼰项⽬定制灵活的分布式⽅案，难度⾼。
这两者共同点：都是关系数据库SQL以外的可选⽅案，逻辑随着数据分布，任何模型都可以⾃⼰持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对⼀致性的要求程度。
不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合⾮Java如PHP RUBY 等领域，是⼀种可以拿来就⽤的产品，⽽领域模型+ 分布式缓存+ 存储是⼀种复杂的架构解决⽅案，不是产品，但这种⽅式更灵活，更应该是架构师必须掌握的。
⽬前，已经有很多分布式数据库的产品，但是绝⼤部分是⾯向DSS类型的应⽤，因为相⽐较OLTP应⽤，DSS应⽤更容易做到分布式扩展，⽐如基于PostgreSQL发展的Greenplum，就很好的解决了可⽤性和扩展性的问题，并且提供了很强⼤的并⾏计算能⼒。对于OLTP应⽤，业务特点决定其要求：⾼可⽤性，⼀致性，响应时间短，⽀持事务和join等等。MichaelStonebraker提到了⼀种新的数据库产品VoltDB，它的定义是Next-Generation SQL Database for Fast-Scaling OLTPApplications。虽然产品还没有问世，但是从技术资料上来看，它有⼏个特点：
1.采⽤Share nothing架构，将物理服务器划分为以CPU core为单位的Virtual node，采⽤Sharding技术，将数据⾃动分布到不同的Virtual node，最⼤限度的利⽤机器的计算资源；
2.采⽤内存数据访问技术，类似于内存数据库(In-memory database)，区别于传统的数据库(Disk-based database)，消除了传统数据库内存管理的开销，⽽且响应速度⾮常快；
3.每个Virtual node上的操作是⾃治的，利⽤队列技术将并发访问变为串⾏访问，消除了传统数据库串⾏控制的开销(⽐如Latch和Lock)；
4.数据同步写多个副本，不存在单点故障，⽽且消除了传统数据库需要记录redo log的开销。
VoltDB不仅⽀持传统数据库的ACID模型和SQL接⼝，⽽且提供类似NoSQL产品的⾼可⽤性和很强的扩展能⼒，可谓鱼⾁熊掌兼得。CAP理论并不是神话，相信未来类似的数据库产品会不断涌现。(六)数据库和NoSQL
当越来越多的NoSQL产品涌现出来，它们具备很多关系型数据库所不具备的特性，在可⽤性和扩展性⽅⾯都可以做到很好。那么，未来传统的关系型数据库还有优势吗？NoSQL会取代数据库吗？我个⼈认为关系型数据库⾄少在相当长的⼀段时间内，依然是主流，⽽且还有很⼤的发展空间。
第⼀，NoSQL的应⽤场景⾮常局限，某个类型的NoSQL仅仅针对特定类型的应⽤场景⽽设计。⽽关系型数据库则要通⽤的多，使⽤NoSQL必须搞清楚⾃⼰的应⽤场景是否适合，所以说NoSQL对于很多⼈来说是“汝之蜜糖，彼之砒霜”。
第⼆，利⽤关系型数据库配合应⽤架构，⽐如Sharding和读写分离技术，同样可以搭建出具备⾼可⽤和扩展性的分布式数据库集群。
第三，关系型数据库⼚商依然很强⼤，全世界有⼤量的⽤户，需求必然会推动新的产品问世。
第四，硬件的发展⽇新⽉异，⽐如闪存的技术的不断成熟，未来闪存可以作为磁盘与内存之间的cache，或者完全替代磁盘。⽽内存价格越来越低，容量越来越⼤，In-memory cache或database的应⽤越来越⼴泛，可以给应⽤带来数量级的性能提升。数据库⾯临的IO问题将被极⼤改善，数据库也将随着这些新技术⽽焕发第⼆春。
虽然不担⼼关系型数据库的未来，但我们也不能忽视NoSQL的巨⼤⼒量。未来，各种产品和技术⼀定是百
花齐放，关系型数据库依然有很强的⽣命⼒，各种NoSQL产品也会层出不穷，所以完全不⽤担⼼谁将会替代谁，我们要做的就是找到最佳的解决⽅案。有⼈将NoSQL解释成为Not only SQL，我想也是这个原因吧。(七)结论
前⾯探讨了关于数据库可⽤性和扩展性⽅⾯的问题，我们看到每种产品和架构都是有缺陷的，其实架构就是有所取舍的过程，⽬标是⽤最⼩的代价去解决问题。所以找到适合⾃⼰的产品和架构，这才是最重要的。
6Oracle 10g RAC（Real Application Cluster）6.1企业⽹格
现在，企业的IT部门⾯临巨⼤的压⼒，他们需要以最低的成本，最⾼的效率和灵活性，提供优质的服务，同时具有最出⾊的可⽤性和可伸缩性。简⽽⾔之，IT部门需要以最低的成本来完成最多的事情。
企业⽹格能够把这些看似⽆法解决的挑战变成现实。它由⼤规模的低成本商⽤集群组成，显著降低了计算机硬件的成本。
Oracle RAC 技术可为这⼀低成本硬件平台提供⽀持，使其提供优质的服务，并达到或超出昂贵的⼤型SMP 计算机所能提供的可⽤性和可伸缩性等级。通过显著降低管理成本和提供出⾊的管理灵活性，Oracle 为企业⽹格环境提供了强有⼒的⽀持。企业⽹格有着深远的影响，可赋予企业更出⾊的适应性、前瞻性和敏捷性。在企业⽹格中，数据中⼼将可以动态改变⾃⾝特性，以实时⽀持企业瞬息万变的需求。应⽤程序⼯作负载将以服务的形式进⾏管理，同时必需满⾜规定的质量等级。处理资源和存储器将以数据流的形式分配给服务，以确保满⾜规定的质量要求。⽹格中的每⼀处理节点或存储组件可近乎实时地改变⾃⾝的特性，⽽不会对应⽤程序产⽣任何影响。6.2R AC
Oracle RAC ⽀持Oracle 数据库在集群上运⾏真正的应⽤程序。此处的真正应⽤是指RAC 能够⽀持所有类型的主流商业应⽤程序。这包括流⾏的封装产品，如SAP、PeopleSoft 和Oracle E*Business Suite 等，以及⾃主研发的应⽤程序，其中包括OLTP和DSS，以及Oracle 有效⽀持混合OLTP/DSS 环境的独有能⼒。Oracle 是唯⼀提供具备这⼀功能的开放系统数据库的⼚商。Oracle RAC 运⾏于集群之上，为Oracle 数据库提供了最⾼级别的可⽤性、可伸缩性和低成本计算能⼒。如果集群内的⼀个节点发⽣故障，Oracle 将可以继续在其余的节点上运⾏。如果需要更⾼的处理能⼒，新的节点可轻松添加⾄集群。为了保持低成本，即使最⾼端的系统也可以从采⽤标准化商⽤组件的⼩型低成本集群开始逐步构建⽽成。
Oracle 的主要创新是⼀项称为⾼速缓存合并的技术，它最初是针对Oracle9i 真正应⽤集群开发的。⾼速缓存合并使得集群中的节点可以通过⾼速集群互联⾼效地同步其内存⾼速缓存，从⽽最⼤限度地低降低磁盘I/O。⾼速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。数据⽆需在节点间进⾏分区。Oracle 是唯⼀提供具备这⼀能⼒的开放系统数据库的⼚商。其它声称可以运⾏在集群上的数据库软件需要对数据库数据进⾏分区。这对于拥有复杂的数据结构的真正应⽤程序⽽⾔，显得不切实际。⽽且也不可能对集群系统进⾏统⼀变更。如果您添加或删除节点或存储资源，数据则需要完全重新分区。Oracle RAC ⽀持企业⽹格。
企业⽹格是未来的数据中⼼，构建于由标准化商⽤组件构成的⼤型配置之上，其中包括：处理器、⽹络和存储器。Oracle
RAC 的⾼速缓存合并技术提供了最⾼等级的可⽤性和可伸缩性。Oracle 数据库10g 和Oracle RAC 10g 显著降低了运营成本，增强了灵活性，从⽽赋予了系统更卓越的适应性、前瞻性和灵活性。动态提供节点、存储器、CPU 和内存可以在实现所需服务级别的同时，通过提⾼的利⽤率不断降低成本。6.3R AC集成集群件管理
Oracle RAC 10g 在Oracle 数据库10g 运⾏的所有平台上提供了⼀个完整集成的集群件管理解决⽅案。这⼀集群件功能包括集群连接、消息处理服务和锁定、集群控制和恢复，以及⼀个⼯作负载管理框架（将在下⽂
探讨）。⽤户⽆需购买任何第三⽅集群件管理软件。但是，Oracle 仍将继续在特定平台上⽀持选定的第三⽅集群件产品。Oracle RAC 10g 的集成集群件管理具有以下优势：(⼀)成本低。Oracle 免费提供这⼀功能。(⼆)单⼀⼚商⽀持。消除了相互推诿的问题。
(三)安装、配置和持续维护更简单。Oracle RAC 10g 集群件使⽤标准Oracle 数据库管理⼯具进⾏安装、配置和维护。这⼀过程⽆须其它的集成步骤。
(四)所有平台，质量始终如⼀。与第三⽅产品相⽐，Oracle 对新软件版本进⾏了更严格的测试。
(五)所有平台，功能始终如⼀。例如，⼀些第三⽅集群件产品限制了集群内可以⽀持的节点的数量。借助Oracle RAC 10g，所有平台可以⽀持多达64 个节点。⽤户还可以在所有平台上获得⼀致的响应体验，从⽽有效解决了⾼可⽤性挑战，包括服务器节点故障、互连故障以及I/O 隔离现象等。
(六)⽀持⾼级功能。这包括集成监视和通知功能，从⽽在发⽣故障时，在数据库和应⽤层之间实现快速协调的恢复。6.4单⼀系统映像管理
Oracle 企业管理器10g 的功能⼤幅提升，实现了集群数据库部署真正的单⼀系统映像管理。Enterprise Manager 的ClusterDatabase Page 提供了涵盖多个节点的系统状态的单⼀视图。它还可以根据需求更详细地显⽰单独的例程。通过ClusterDatabase Page，⽤户可以：
(⼀)查看整体系统状态，例如：集群数据库内节点的数量及其当前的状态。(⼆)查看所有例程的警报，同时详细观察每⼀警报的根源和其它信息。(三)在集群数据库基础上设置警报阈值。
(四)监视所有例程的性能标准或逐个显⽰，以便逐个进⾏⽐较，或在需要时了解更详细的信息。(五)监视集群⾼速缓存⼀致性情况（例如：全局缓存获取等）。
(六)执⾏集群数据库操作，包括启动备份与恢复，以及开始/停⽌例程等。
(七)通过执⾏诸如开始/停⽌、激活/禁⽤和重新分配服务等操作，以及监视服务性能来管理服务（详细信息请参见下⽂的“⾃动⼯作负载管理”部分）。
(⼋)Oracle 企业管理器10g 还提供了⼀个集群页⾯来查看集群硬件和整个操作系统的状态。在集群⽀持多个数据库时，这⼀特性⾮常实⽤。⽤户可以轻松了解整体集群平台状态，同时也可根据需求详细了解每个独数据库的性能。6.5⾃动⼯作负载管理
使⽤Oracle 数据库10g，应⽤程序⼯作负载可被定义成服务，以便对其进⾏单独管理和控制。在正常运⾏期间和发⽣故障时，DBA 决定分配给相应服务的处理资源。性能标准通过服务进⾏跟踪，同时还可以设置阈值，⼀旦超过这些阈值，即⾃动发出警报。CPU 资源分配和资源消耗控件使⽤资源管理器进⾏管理，以便在提供服务时使⽤。Oracle ⼯具和设施，如JobScheduler、Parallel Query 和Oracle Streams Advanced Queuing 等，也使⽤服务来管理它们的⼯作负载。
使⽤Oracle 数据库10g 可以定义规则，⾃动将处理资源分配给服务。Oracle RAC 10g 例程可根据需要进⾏分配，以便处理单个或多个服务。这些分配规则可动态进⾏修改，以满⾜瞬息万变的业务需求。例如，这些规则可以在每个季度末进⾏修改，以确保有⾜够的处理资源来及时执⾏重要的财务功能；也可以另⾏定义规则，以便在运⾏关键服务的例程发⽣故障时，⼯作负载可以⾃动切换到⼯作负载较少的例程上。
服务通过全局唯⼀名称进⾏识别。例如，⼀个应⽤程序套件可为每⼀个应⽤程序组件定义⼀种服务，诸如总帐、应收账款和订单项等。中间层应⽤程序和客户机在连接到数据库时，可以通过在TNS 连接数据中指定服务名称，选择⼀种服务。但⽆须更改应⽤程序本⾝。6.6⼯作负载监视
Oracle ⾃动⼯作负载仓库10g 使DBA 管理可以针对RAC 和单⼀例程数据库执⾏的服务。响应时间、CPU 消耗，以及其它标准由服务⾃动收集。应⽤程序能够实施其代码来设定标记，根据初始应⽤MODULE 和ACTION 识别服务内的操作，从⽽收集更详细的性能数据。
该⾃动⼯作负载仓库持续维护服务标准。该视图V$SERVICE_METRICS 和V$SERVICE_METRICS_HISTORY 包含过去⼀⼩时内每60 秒的各项服务的测量情况。Oracle 企业管理器10g 中的图形显⽰便于它根据CPU 消耗和其它标准识别顶级服务、顶级模块和顶级操作。
使⽤Oracle 企业管理器10g，可对呼叫响应时间和其它服务级别标准设定阈值，以便在超出这些阈值时能够⾃动⽣成警报。例如，如果性能等级未达到要求的服务级别，DBA 将收到向服务分配额外处理资源的警报。应⽤中间层组件和产品还可以利⽤这⼀数据实现负载均衡。6.7与灾难恢复的Data Guard集成
通过Oracle 企业管理器10g，Oracle Data Guard 的管理组件Data Guard Broker 现在可以与RAC 全⾯集成。与那些采⽤单⼀例程数据库的环境⼀样，涉及Oracle RAC 数据库的Data Guard 灾难恢复环境也⾮常易于管理。
⾃动⼯作负载管理可⽤于在发⽣灾难后重新向备⽤系统提供服务，从⽽确保最关键的服务保持需要的服务级别，与此同时低优先级服务还能在降低的容量下运⾏。这⼀特性可以使备⽤系统的总容量少于主系统，因⽽减少了成本。6.8其他性能改进
除了可管理性⽅⾯的显著改进，Oracle RAC 10g 还提供了⼀系列性能改进，令许多应⽤程序受益。这些包括例程故障恢复时间的改进，⽤于提⾼主要应⽤程序操作性能的若⼲优化，以及针对特定类型的⼯作负载提供性能改进的动态重组。
由于⼀系列优化缩短了路径长度，⽽且允许关键恢复功能并⾏执⾏，所以⼤多数应⽤程序的例程故障恢复速度都加快了。内部实验室测试显⽰，针对最⾼恢复速度⽽配置的应⽤程序的恢复时间缩短了⼀半之多。上述快速连接故障切换特性还⽀持在数据库与应⽤中间层组件和产品之间实现快速、协调的恢复。
其它重要优化还为特定类型的应⽤程序操作提供了性能优势。其中包括减少了事务同步开销，对于⼩型事务来说最明显，如简单的帐户余额更新。消息聚集在适当的时候将多条消息合为⼀条信息，因⽽提⾼了节点之间的⾼速缓存合并通信效率。这为在
节点间⽣成⼤量信息的操作提供了最显著的优势，如检验点、在线重做扫描，以及全表扫描。此外，Oracle Streams ⾼级查询现在使⽤快速⾼速缓存合并通信层来更有效地向远程RAC 例程上的⽤户提供全球事件。
另⼀个重要优化是动态资源重组。如果应⽤程序包含多个⼯作负载，通常⼀个或多个⼯作负载会在很⼤程度上表现出与特定数据资源集的相似性。如果是这样，RAC 10g 将⾃动对其进⾏检测，并将这些资源重组到表现出相似性的例程上。随着⼯作负载的变化和在例程间的切换，该机制可⾃动进⾏调整，以便以优化的⽅式重组资源。此优化改进了性能，且⽆须对应⽤程序或数据布局进⾏任何⼈⼯调节或更改。7总结
集群⼀般有两种，即⾼可⽤和⾼性能集群，⼀般的集群，包括现在的低端双机容错、IBM的HACMP、HP 的MC ServiceGuard都是⾼可⽤性集群，不能做负载均衡；⽽⾼性能集群主要是科学计算、科研等⼀些特殊环境⽤，在现实应⽤中⽐较少。⽽
Oracle的RAC是基于特殊环境下的应⽤系统，要求有操作系统层⾯的分布式锁（DLM）。具体使⽤起来要做相应的规划，⽽且不能随便使⽤，弄不好性能适得其反。
前⾯说过，负载均衡不能完全算⾼可⽤性集群的⼀种，是⾼性能性集群，普通的HA软件没办法⽀持像Oracle RAC⼀样的环境，这不完全是集群软件的功能。
⾼可⽤性集群与负载均衡集群的⼯作原理不同，适⽤于不同类型的服务。通常，负载均衡集群适⽤于提供
静态数据的服务，如HTTP服务；⽽⾼可⽤性集群既适⽤于提供静态数据的服务，如HTTP服务，⼜适⽤于提供动态数据的服务，如数据库等。⾼可⽤性集群之所以能适⽤于提供动态数据的服务，是由于节点共享同⼀存储介质，如SAN阵列。也就是说，在⾼可⽤性集群内，每种服务的⽤户数据只有⼀份，存储在共⽤存储设备上，在任⼀时刻只有⼀个节点能读写这份数据。⾼可⽤性集群对⼀种服务⽽⾔不具有负载均衡功能，它可以提⾼整个系统的可靠性，但不能增加负载的能⼒。当然，⾼可⽤性集群可以运⾏多种服务，并适当分配在不同节点上，⽐如节点A提供Oracle服务，同时节点B提供Sybase服务，这也可以看成是某种意义上的负载均衡，不过这是对多种服务的分配⽽⾔。
负载均衡集群适⽤于提供相对静态的数据的服务，⽐如HTTP服务。因为通常负载均衡集群的各节点间通常没有共⽤的存储介质，⽤户数据被复制成多份，存放于每⼀个提供该项服务的节点上。第⼆章RAC的结构和原理1Oracle的体系结构
要搞清RAC的结构和原理，⾸先要了解Oracle的体系结构，下图是Oracle的体系结构图，可以看出，Oracle 的体系结构由实例（Instance）和数据库组成。
在⼀个服务器中，每⼀个运⾏的Oracle数据库都⾄少与⼀个数据库实例相联系，实例是访问数据库的⼿段，是⽤来访问数据库⽂件集的存储结构及后台进程的集合。
内存结构分为两部分：SGA和PGA。SGA是⽤于2RAC的结构组成和机制
在Oracle9i之前，RAC称为OPS（Oracle Parallel Server）。RAC与OPS之间的⼀个较⼤区别是，RAC采⽤了Cache
Fusion（⾼缓存合并）技术，节点已经取出的数据块更新后没有写⼊磁盘前，可以被另外⼀个节点更新，然后以最后的版本写⼊磁盘。在OPS中，节点间的数据请求需要先将数据写⼊磁盘，然后发出请求的节点才可以读取该数据。使⽤Cache Fusion时，RAC的各个节点间数据缓冲区通过⾼速、低延迟的内部⽹络进⾏数据块的传输。下图是⼀个典型的RAC对外服务的⽰意图，⼀个Oracle RAC Cluster包含了如下的部分：
集群的节点（Cluster node）——2个到N个节点或者主机运⾏Oracle Database Server。
私有⽹络（Network Interconnect）——RAC之间需要⼀个⾼速互联的私有⽹络来处理通信和Cache Fusion。共享存储（shared Storage）——RAC需要共享存储设备让所有的节点都可以访问数据⽂件。
对外服务的⽹络（Production Network）——RAC对外服务的⽹络。客户端和应⽤都通过这个⽹络来访问。2.1R AC结构
RAC是Oracle数据库的⼀个群集解决⽅案，是有着两个或者两个以上的数据库节点协调运作能⼒的。如下图所⽰的RAC结构图：
集群管理器（Cluster Manager）在集群系统中对其他各个模块进⾏整合，通过⾼速的内连接来提供群集节
点之间的通信。各节点之间内连接使⽤⼼跳线互联，⼼跳线上的信息功能确定群集逻辑上的节点成员信息和节点更新情况，以及节点在某个时间点的运⾏状态，保证群集系统正常运⾏。
通信层管理节点之间的通信。它的职责是配置，互联群集中节点信息，在群集管理器中使⽤由⼼跳机制产⽣的信息，由通信层负责传输，确保信息的正确到达。还有⼀些群集监视进程不断验证系统的不同领域运⾏状况。例如，⼼跳监测不断验证的⼼跳机制的运作是否良好。
在⼀个应⽤环境当中，所有的服务器使⽤和管理同⼀个数据库，⽬的是分散每⼀台服务器的⼯作量。硬件上⾄少需要两台以上的服务器，⽽且还需要⼀个共享存储设备；同时还需要两类软件，⼀类是集群软件，另外⼀类就是Oracle数据库中的RAC组件。同时所有服务器上的OS都应该是同⼀类OS，根据负载均衡的配置策略，当⼀个客户端发送请求到某⼀台服务的listener
后，这台服务器根据负载均衡策略，会把请求发送给本机的RAC 组件处理，也可能会发送给另外⼀台服务器的RAC组件处理，处理完请求后，RAC会通过群集软件来访问共享存储设备。
逻辑结构上看，每⼀个参加群集的节点有⼀个独⽴的实例，这些实例访问同⼀个数据库。节点之间通过集群软件的通信层
（Communication Layer）来进⾏通信。同时为了减少I/O的消耗，存在⼀个全局缓存服务，因此每⼀个数据库的实例，都保留了⼀份相同的数据库cache。RAC中的特点如下：
●每⼀个节点的实例都有⾃⼰的SGA；●每⼀个节点的实例都有⾃⼰的后台进程●每⼀个节点的实⼒都有⾃⼰的redo logs●每⼀个节点的实例都有⾃⼰的undo表空间●所有节点都共享⼀份datafiles和controlfiles2.2R AC后台进程
Oracle RAC有⼀些⾃⼰独特的后台进程，在单⼀实例中不发挥配置作⽤。如下图所⽰，定义了⼀些RAC运⾏的后台进程。这些后台进程的功能描述如下。
（1）LMS（Global cache service processes全局缓存服务进程）进程主要⽤来管理集群内数据块的访问，并在不同实例的Buffer Cache中传输数据块镜像。直接从控制的实例的缓存复制数据块，然后发送⼀个副本到请求的实例上。并保证在所有实例的Buffer Cache中⼀个数据块的镜像只能出现⼀次。LMS进程靠着在实例中传递消息来协调数据块的访问，当⼀个实例请求数据块时，该实例的LMD进程发出⼀个数据块资源的请求，该请求指向主数据块的实例的LMD进程，主实例的LMD进程和正在使⽤的实例的LMD进程释放该资源，这时拥有该资源的实例的LMS进程会创建⼀个数据块镜像的⼀致性读然后把该数据块传递到请求该资源的实例的BUFFER CACHE中。LMS进程保证了在每⼀时刻只能允许⼀个实例去更新数据块，并负责保持该数据块的镜像记录（包含更新数据块的状态FLAG)。
RAC提供了10个LMS进程（0~9），该进程数量随着节点间的消息传递的数据的增加⽽增加。
（2）LMON（Lock Monitor Process，锁监控进程）是全局队列服务监控器，各个实例的LMON进程会定期通信，以检查集群中各个节点的健康状况，当某个节点出现故障时，负责集群重构、GRD恢复等操作，它提供的服务叫做Cluster GroupService（CGS）。
LMON主要借助两种⼼跳机制来完成健康检查。
(⼀)节点间的⽹络⼼跳（Network Heartbeat）：可以想象成节点间定时的发送ping包检测节点状态，如果能在规定时间内收到回应，就认为对⽅状态正常。
(⼆)通过控制⽂件的磁盘⼼跳（controlfile heartbeat）：每个节点的CKPT进程每隔3秒钟更新⼀次控制⽂件
的数据块，这个数据块叫做Checkpoint Progress Record，控制⽂件是共享的，所以实例间可以互相检查对⽅是否及时更新来判断。
(三)LMD（the global enqueue service daemon，锁管理守护进程）是⼀个后台进程，也被称为全局的队列服
务守护进程，因为负责对资源的管理要求来控制访问块和全局队列。在每⼀个实例的内部，LMD进程管理输⼊的远程资源请求（即来⾃集群中其他实例的锁请求）。此外，它还负责死锁检查和监控转换超时。
(四)LCK（the lock process，锁进程）管理⾮缓存融合，锁请求是本地的资源请求。LCK进程管理共享资源的实例的资源请求和跨实例调⽤操作。在恢复过程中它建⽴⼀个⽆效锁元素的列表，并验证锁的元素。由于处理过程中的LMS锁管理的⾸要职能，只有⼀个单⼀的LCK进程存在每个实例中。
(五)DIAG（the diagnosability daemon，诊断守护进程）负责捕获RAC环境中进程失败的相关信息。并将跟
踪信息写出⽤于失败分析，DIAG产⽣的信息在与Oracle Support技术合作来寻找导致失败的原因⽅⾯是⾮常有⽤的。每个实例仅需要⼀个DIAG进程。
(六)GSD（the global service daemon，全局服务进程）与RAC的管理⼯具dbca、srvctl、oem进⾏交互，⽤
来完成实例的启动关闭等管理事务。为了保证这些管理⼯具运⾏正常必须在所有的节点上先start gsd，并且⼀个GSD进程⽀持在⼀个节点的多个rac.gsd进程位于$ORACLE_HOME/bin⽬录下，其log⽂件为$ORACLE_HOME/srvm/log/gsdaemon.log。GCS和GES两个进程负责通过全局资源⽬录（Global Resource Directory GRD）维护每个数据的⽂件和缓存块的状态信息。当某个实例访问数据并缓存了数据之后，集群中的其他实例也会获得⼀个对应的块镜像，这样其他实例在访问这些数据是就不需要再去读盘了，⽽是直接读取SGA中的缓存。GRD存在于每个活动的instance的内存结构中，这个特点造成RAC环境的SGA相对于单实例数据库系统的SGA要⼤。其他的进程和内存结构都跟单实例数据库差别不⼤。2.3R AC共享存储
RAC需要有共享存储，提供共享存储的⽅式有很多种⽅式，在共享存储的基础上，需要把⼀些相关的信息存储在共享区域⾥，既然是共享区域，当然就是⼀些需要共享的信息，独⽴于实例之外的信息，如上⾯提到的ocr和votedisk以及数据⽂件都存放在这个共享存储⾥的。
在探讨RAC的时候，经常会讲到OCFS、OCFS2、RAW、ASM等这样的⼀些存储⽅式。OCFS和OCFS2就是
⼀个⽂件系统⽽已，和NFS⼀样，提供⼀种集群环境中的共享存储的⽂件系统，从它的名字⾥就可以看出来：Oracle ClusterFile System。
RAW裸设备也是⼀种存储⽅式，是oracle11g之前的版本中RAC⽀持的存储⽅式，在Oralce9i之前，OPS/RAC 的⽀持只能使⽤这样的⽅式，也就是把共享存储映射到RAW Device，然后把Oracle需要的数据选择RAW device 存储，但是RAW相对于⽂件系统来说不直观，不便于管理，⽽且RAW Device有数量的限制，RAW显然需要有新的⽅案来代替，这样就有了OCFS这样的⽂件系统。当然，这只是Oracle⾃⼰的实现的集群⽂件系统⽽已，还有其他⼚商提供的⽂件系统可以作为存储的选择⽅案。ASM只是数据库存储的⽅案⽽已，并不是cluster的⽅案，所以这⾥ASM应该是区别于RAW和OCFS/OCFS2同⼀级别的概念，RAW和OCFS/OCFS2不仅可以作为数据库存储的⽅案，同时也可以作为Clusterware⾥的存储⽅案，是CRS⾥需要的storage，⽽ASM仅作为数据库的存储⽽已，严格来说仅是RAC中的⼀个节点应⽤（nodeapps）。ASM对于clusterware安装时需要的ocr和votedisk这两项还不⽀持，毕竟ASM本⾝就需要⼀个实例，⽽CRS是完全在架构之外的，这也就是为什么使⽤了ASM的⽅案，却总还要加上OCFS/OCFS2和RAW其中的⼀个原因。各种RAC共享存储⽅式的对⽐如下：
集群⽂件系统——⽀持windows和Linux的OCFS/OCFS2
AIX下的GPFS等⽅式——优点是管理⽅便，表⽰也很直观，但缺点是基于⽂件系统管理软件，⼜要经
过OS的cache处理，性能上和稳定性上都有⽋缺，所以不适合在⽣产环境下使⽤。可以⽀持CRS集群软件⽂件和数据库⽂件。RAW裸设备⽅式——通过硬件⽀持的共享存储系统，直接⽤RAW设备存储，可以⽀持集群软件⽂件和数据库⽂件。
⽹络⽂件系统（NFS）——通过NFS实现共享存储，不过需要经过Oracle认证的NFS才⾏，可以⽀持
CRS集群软件⽂件和数据库⽂件。
ASM——集合RAW⽅式I/O⾼性能和集群⽂件系统易管理等优点，Oracle10g下推出的共享存储⽅式，
但是本⾝ASM就是需要Oracle的实例⽀持，所以ASM仅⽀持数据库⽂件，⽽不⽀持CRS⽂件。2.4R AC数据库和单实例数据库的区别
为了让RAC中的所有实例能够访问数据库，所有的datafiles、control files、PFILE/Spfile和redo log files必须保存在共享磁盘上，并且要都能被所有节点同时访问，就涉及到裸设备和集群⽂件系统等。RAC database在结构上与单实例的不同之处：
⾄少为每个实例多配置⼀个redo 线程，⽐如：两个实例组成的集群⾄少要4个redo log group。每个实例两个redo group。
另外要为每⼀个实例准备⼀个UNDO 表空间。1、redo和undo
很显然，每个实例在做数据库的修改时谁⽤谁的redo和undo段，各⾃锁定⾃⼰修改的数据，把不同实例的操作相对的独⽴开就避免了数据不⼀致。
后⾯就要考虑备份或者恢复时redo log和归档⽇志在这种情况下的特殊考虑了。2、内存和进程
各个节点的实例都有⾃⼰的内存结构和进程结构.各节点之间结构是基本相同的.
通过Cache Fusion（缓存融合）技术，RAC在各个节点之间同步SGA中的缓存信息达到提⾼访问速度的效果也保证了⼀致性。
2.5R AC⼯作原理和相关组件2.5.1RAC⼯作原理
对Oracle单实例的配置和各种后台进程尽⼼探讨后，了解了单实例的后台⼯作⽅式和运⾏逻辑。其实Oracle RAC是多个单实例在配置意义上的扩展，实现由两个或者多个节点（实例）使⽤⼀个共同的共享数据库（例如，⼀个数据库同时安装多个实例并打开）。在这种情况下，每⼀个单独的实例有它⾃⼰的cpu和物理内存，也有⾃⼰的SGA和后台进程。和传统的oracle实例相⽐，在系统全局区（SYSTEM CLOBAL AREA,SGA）与后台进程有着显著的不同。最⼤的不同之处在于多了⼀个GRD,GRD内存块主要是记录此rac有多少个集群数据库与系统资源，同时也会记录数据块的相关信息，因为在rac架构中，每个数据块在每⼀个SGA中都有⼀份副本，⽽rac必须知道这些数据块的位置，版本，分布以及⽬前的状态，这些信息就存放在GRD中，但GRD只负责存放不负责管理，管理的责任则交给后台进程GCS和GES来进⾏。
Oracle的多个实例访问⼀个共同的共享数据库。每个实例都有⾃⼰的SGA、PGA和后台进程，这些后台进程应该是熟悉的，因为在RAC配置中，每个实例将需要这些后台进程运⾏⽀撑的。可以从以下⼏个⽅⾯了解RAC ⼯作原理和运⾏机制。(⼀)SCN
SCN是Oracle⽤来跟踪数据库内部变化发⽣先后顺序的机制，可以把它想象成⼀个⾼精度的时钟，每个Redo ⽇志条⽬，UndoData Block，Data Block 都会有SCN 号。Oracle的Consistent-Read，Current-Read，Multiversion-Block都是依赖SCN 实现。
在RAC中，有GCS 负责全局维护SCN的产⽣，缺省⽤的是Lamport SCN⽣成算法，该算法⼤致原理是：在所有节点间的通信内容中都携带SCN，每个节点把接收到的SCN和本机的SCN对⽐，如果本机的SCN ⼩，则调整本机的SCN和接收的⼀致，如果节点间通信不多，还会主动地定期相互通报。故即使节点处于Idle 状态，还是会有⼀些Redo log 产⽣。还有⼀个⼴播算法（Broadcast），这个算法是在每个Commit操作之后，节点要想其他节点⼴播SCN，虽然这种⽅式会对系统造成⼀定的负载，但是确保每个节点在Commit之后都能⽴即查看到SCN.
这两种算法各有优缺点，Lamport虽然负载⼩，但是节点间会有延迟，⼴播虽然有负载，但是没有延迟。Oracle 10g RAC 缺省选⽤的是BroadCast 算法，可以从alert.log ⽇志中看到相关信息：Picked broadcast on commit scheme to generate SCNS(⼆)RAC的GES/GCS原理
全局队列服务（GES）主要负责维护字典缓存和库缓存的⼀致性。字典缓存是实例的SGA内所存储的对数据字典信息的缓存，⽤于⾼速访问。由于该字典信息存储在内存中，因⽽在某个节点上对字典进⾏的修改（如DDL)必须⽴即被传播⾄所有节点上
的字典缓存。GES负责处理上述情况，并消除实例间出现的差异。处于同样的原因，为了分析影响这些对象的SQL语句，数据库内对象上的库缓存锁会被去掉。这些锁必须在实例间进⾏维护，⽽全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁。LMON、LCK和LMD进程联合⼯作来实现全局队列服务的功能。GES是除了数据块本⾝的维护和管理（由GCS完成）之外，在RAC环境中调节节点间其他资源的重要服务。
为了保证集群中的实例的同步，两个虚拟服务将被实现：全局排队服务（GES），它负责控制对锁的访问。全局内存服务（GCS)，控制对数据块的访问。
GES 是分布式锁管理器(DLM)的扩展，它是这样⼀个机制，可以⽤来管理oracle 并⾏服务器的锁和数据块。在⼀个群集环境中，你需要限制对数据库资源的访问，这些资源在单instance数据库中被latches 或者locks 来保护。⽐如说，在数据库字典内存中的对象都被隐性锁所保护，⽽在库⾼速缓存中的对象在被引⽤的时候，必须被pin所保护。
在RAC群集中，这些对象代表了被全局锁所保护的资源。GES 是⼀个完整的RAC组件，它负责和群集中的实例全局锁进⾏沟通，每个资源有⼀个主节点实例，这个实例记录了它当前的状态。⽽且，资源的当前的状态也记录在所有对这个资源有兴趣的实例上。
GCS,是另⼀个RAC组件，负责协调不同实例间对数据块的访问。对这些数据块的访问以及跟新都记录在全局⽬录中（GRD）,这个全局⽬录是⼀个虚拟的内存结构，在所有的实例中使⽤扩张。
每个块都有⼀个master实例，这个实例负责对GSD的访问进⾏管理，GSD⾥记录了这个块的当前状态信息。GCS 是oracle ⽤来实施Cache fusion的机制。被GCS 和GES 管理的块和锁叫做资源。对这些资源的访问必须在群集的多个实例中进⾏协调。这个协调在实例层⾯和数据库层⾯都有发⽣。实例层次的资源协调叫做本地资源协调；数据库层次的协调叫做全局资源协调。本地资源协调的机制和单实例oracle的资源协调机制类似，包含有块级别的访问，空间管理，dictionary cache、library cache管理，⾏级锁，SCN 发⽣。全局资源协调是针对RAC的，使⽤了SGA中额外的内存组件、算法和后台进程。
GCS 和GES 从设计上就是在对应⽤透明的情况下设计的。换⼀句话来说，你不需要因为数据库是在RAC 上运⾏⽽修改应⽤,在单实例的数据库上的并⾏机制在RAC上也是可靠地。
⽀持GCS 和GES的后台进程使⽤私⽹⼼跳来做实例之间的通讯。这个⽹络也被Oracle 的群集组件使⽤，也有可能被群集⽂件系统（⽐如OCFS)所使⽤。GCS 和GES 独⽴于Oracle 群集组件⽽运⾏。但是，GCS 和GES依靠这些群集组件获得群集中每个实例的状态。如果这些信息不能从某个实例获得，这个实例将被关闭。这个关闭操作的⽬的是保护数据库的完整性，因为每个实例需要知道其他实例的情况，这样可以更好的确定对数据库的协调访问。
GES控制数据库中所有的library cache锁和dictionary cache锁。这些资源在单实例数据库中是本地性的，但是到了RAC群集中变成了全局资源。全局锁也被⽤来保护数据的结构，进⾏事务的管理。⼀般说来，事务和表锁在RAC环境或是单实例环境中是⼀致的。
Oracle的各个层次使⽤相同的GES 功能来获得，转化以及释放资源。在数据库启动的时候，全局队列的个数将被⾃动计算。GES 使⽤后台进程LMD0和LCK0来执⾏它的绝⼤多数活动。⼀般来说，各种进程和本地的LMD0 后台进程沟通来管理全局资源。本地的LMD0 后台进程与别的实例上的LMD0进程进⾏沟通。
LCK0 后台进程⽤来获得整个实例需要的锁。⽐如，LCK0 进程负责维护dictionary cache 锁。
影⼦进程(服务进程）与这些后台进程通过AST(异步陷阱）消息来通信。异步消息被⽤来避免后台进程的阻塞，这些后台进程在等待远端实例的的回复的时候将阻塞。后台进程也能发送BAST(异步锁陷阱）来锁定进程，这样可以要求这些进程把当前的持有锁置为较低级限制的模式。
资源是内存结构，这些结构代表了数据库中的组件，对这些组件的访问必须为限制模式或者串⾏化模式。换⼀句话说，这个资源只能被⼀个进程或者⼀直实例并⾏访问。如果这个资源当前是处于使⽤状态，其他想访问这个资源的进程必须在队列中等待，直到资源变得可⽤。
队列是内存结构，它负责并⾏化对特殊资源的访问。如果这些资源只被本地实例需求，那么这个队列可以本地来获得，⽽且不需要协同。但是如果这个资源被远程实例所请求，那么本地队列必须变成全球化。2.5.2ClusterWare架构
在单机环境下，Oracle是运⾏在OS Kernel 之上的。OS Kernel负责管理硬件设备，并提供硬件访问接⼝。Oracle 不会直接操作硬件，⽽是有OS Kernel代替它来完成对硬件的调⽤请求。
在集群环境下，存储设备是共享的。OS Kernel 的设计都是针对单机的，只能控制单机上多个进程间的访问。如果还依赖OSKernel的服务，就⽆法保证多个主机间的协调⼯作。这时就需要引⼊额外的控制机制，在RAC中，这个机制就是位于Oracle 和OS Kernel 之间的Clusterware，它会在OS Kernel之前截获请求，然后和其他结点上的Clusterware协商，最终完成上层的请求。
在Oracle 10G之前，RAC 所需要的集群件依赖与硬件⼚商，⽐如SUN,HP,Veritas. 从Oracle 10.1版本中，Oracle 推出了⾃⼰的集群产品. Cluster Ready Service(CRS),从此RAC 不在依赖与任何⼚商的集群软件。在Oracle 10.2版本中，这个产品改名为：Oracle Clusterware。
因篇幅问题不能全部显示，请点此查看更多更全内容