简介
当今世界是一个信息化的世界，我们的生活中无论是生活、工作、学习都离不开信息系统的支撑。而信息系统的背后用于保存和处理最终结果的地方就是数据库。因此数据库系统就变得尤为重要，这意味着如果数据库如果面临问题，则意味着整个应用系统也会面临挑战，从而带来严重的损失和后果。
如今“大数据”这个词已经变得非常流行，虽然这个概念如何落地不得而知。但可以确定的是，随着物联网、移动应用的兴起，数据量相比过去会有几何级的提升，因此数据库所需要解决的问题不再仅仅是记录程序正确的处理结果，还需要解决如下挑战：
当数据库性能遇到问题时，是否能够横向扩展，通过添加服务器的方式达到更高的吞吐量，从而充分利用现有的硬件实现更好的投资回报率。
是否拥有实时同步的副本，当数据库面临灾难时，可以短时间内通过故障转移的方式保证数据库的可用性。此外，当数据丢失或损坏时，能否通过所谓的实时副本（热备）实现数据的零损失。
数据库的横向扩展是否对应用程序透明，如果数据库的横向扩展需要应用程序端进行大量修改，则所带来的后果不仅仅是高昂的开发成本，同时也会带来很多潜在和非潜在的风险。
面对上述挑战一个显而易见的办法是将多个服务器组成一组集群，这样一来就可以充分利用每一台服务器的资源并将客户端负载分发到不同服务器上，随着应用程序负载的增加，只需要将新的服务器添加到集群即可。
本篇文章将对集群的概念、形式以及目前主流的数据库集群技术进行探讨。
数据库集群的形式
数据库的集群和扩展不像应用程序扩展那样容易，因为从数据库端来说，一旦涉及到了集群，往往会涉及到数据库层面的同步，因此从是否存在数据冗余这个角度来讲，我们可以从大面上把数据库集群分为以下两种形式：
Share-Disk架构
Share-Disk架构是通过多个服务器节点共享一个存储来实现数据库集群，两台机器最简单的Share-Disk架构如图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.Share-Nothing冗余架构
在Share-Nothing架构中，每一个节点都拥有自己的内存和存储，都保留数据的完整副本。通常来说，又可以分为两种，可以负载均衡和不可以负载均衡。
