数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术，这种技术不但能满足应用的需要，而且大幅度的节约了投资成本。数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。
在数据库集群产品方面，其中主要包括基于数据库引擎的集群技术的Oracle RAC、Microsoft MSCS、IBM DB2 UDB、Sybase ASE，以及基于数据库网关（中间件）的集群技术的ICX-UDS等产品。
1为什么搭建数据库集群
随着经济的高速发展，企业规模的迅猛扩张，企业用户的数量、数据量的爆炸式增长，对数据库提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战。
如何提高处理速度，实现数据库的均衡负载。
如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性。
怎么综合解决这些问题成为众多企业关注的焦点。
随着计算机硬件技术的高速发展，PC服务器以其高性能和低廉的价格而倍受广大客户青睐，在Web应用或者高性能计算中，为了追求更好的性能以及可用性，大家都采用计算机集群技术（将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术）来实现，这种技术不但能满足应用的需要，而且大幅度的节约了投资成本。在数据库上，组建集群也是同样的道理，主要有以下几个原因：
(一) 伴随着企业的成长，在业务量提高的同时，数据库的访问量和数据量快速增长，其处理能力和计算速度也相应增大，使得单一的设备根本无法承担。
(二) 在以上情况下，若扔掉现有设备，做大量的硬件升级，势必造成现有资源的浪费，而且下一次业务量提升时，又将面临再一次硬件升级的高额投入。于是，人们希望通过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更高数据库处理速度时，只要简单的增加数据库服务器就可以得到扩展。
(三) 数据库作为信息系统的核心，起着非常重要的作用，单一设备根本无法保证系统的下持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。于是，人们希望通过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测并转移故障节点的应用，保证数据库的持续工作。
(四) 企业的数据库保存着企业的重要信息，一些核心数据甚至关系着企业的命脉，单一设备根本无法保证数据库的安全性，一旦发生丢失，很难再找回来。于是，人们希望通过组建数据库集群，实现数据集的冗余，通过备份数据来保证安全性。
2数据库集群的分类
一般来讲，数据库集群软件侧重的方向和试图解决的问题划分为三大类：
l 负载均衡集群（Load Balance Cluster，LBC）侧重于数据库的横向扩展，提升数据库的性能。
l 高可用性集群（High Availability Cluster，HAC）侧重保证数据库应用持续不断。大部分的数据库集群侧重与此。
l 高安全性集群（High Security Cluster，HSC）侧重于容灾。
只有Oracle RAC能实现以上三方面。
3数据库集群按架构分类
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节点间的通信开销会严重影响集群的处理能力。所以对于使用ORACLE RAC有以下两个建议：
l 节点间通信使用高速互联网络；
l 尽可能将不同的应用分布在不同的节点上。
基于这个原因，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各部分组成：
l SQL服务器节点
l NDB数据存储节点
l 监控和管理节点
这样的分层也是与MySQL本身把SQL处理和存储分开的架构相关系的。
MySQL cluster的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP应用。但是它的问题在于：
l NDB存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前NDB新版本对此做了改进，允许只在内存中加 载索引数据，数据可以保存在磁盘上。
l 目前的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理论：
l Consistency(一致性), 数据一致更新，所有数据变动都是同步的
l Availability(可用性), 好的响应性能
l Partition tolerance(分区容错性) 可靠性
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
关系数据库的ACID模型拥有 高一致性 可用性 很难进行分区：
l Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
l Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。
l Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。
l Durability. 一旦事务完成，就不能返回。
(五) 跨数据库事务
2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，也就是说传统关系型数据库要想实现一个分布式数据库集群非常困难，关系型数据库的扩展能力十分有限。而近年来不断发展壮大的NoSQL运动，就是通过牺牲强一致性，采用BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。
那么，有没有可能实现一套分布式数据库集群，既保证可用性和一致性，又可以提供很好的扩展能力呢？BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
l Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
l Soft state软状态 状态可以有一段时间不同步，异步。
l Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。
BASE思想的主要实现有
l 按功能划分数据库
l sharding碎片
BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。
现在NoSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
l Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
l 领域模型 分布式缓存 存储 （Qi4j和NoSQL运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。
这两者共同点：都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。
不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 分布式缓存 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。
目前，已经有很多分布式数据库的产 品，但是绝大部分是面向DSS类型的应用，因为相比较OLTP应用，DSS应用更容易做到分布式扩展，比如基于PostgreSQL发展的 Greenplum，就很好的解决了可用性和扩展性的问题，并且提供了很强大的并行计算能力。对于OLTP应用，业务特点决定其要求：高可用性，一致性， 响应时间短，支持事务和join等等。Michael Stonebraker提到了一种新的数据库产品VoltDB，它的定义是Next-Generation SQL Database for Fast-Scaling OLTP Applications。虽然产品还没有问世，但是从技术资料上来看，它有几个特点：
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，我想也是这个原因吧。
(七) 结论
前面探讨了关于数据库可用性和扩展性方面的问题，我们看到每种产品和 架构都是有缺陷的，其实架构就是有所取舍的过程，目标是用最小的代价去解决问题。所以找到适合自己的产品和架构，这才是最重要的。