简介

随着网络用户和移动端用户的高增长，大数据、人工智能、数据挖掘等新名词频频出现，这背后一定会有在几何级增长的数据，依靠的也同样是用于保存和处理数据的基础，数据库。
由此，数据库面临的不仅仅是记录程序正确的处理结果，还需要解决如下挑战：

• 当数据库性能遇到问题时，是否能够横向扩展，通过增加服务器的方式达到更高的吞吐量，从而充分利用低成本的硬件实现更高的性能
• 是否拥有实时同步的副本，在数据库服务器面临灾难时，可以短时间通过故障转移的方式保证数据可用性。此外，在数据丢失或者损坏时，能否通过所谓的实时副本(热备份)实现数据的零损失。
• 数据库的横向拓展是否对应用程序透明。如果数据库进行横向拓展还需要应用程序进行大量修改，那么后果将不仅仅是提升的开发成本，同时也会带来很多潜在以及非潜在的风险。

面对上述问题，解决方法就是将多台服务器组成一组集群，通过集群就可以充分利用每台服务器的资源并且将访问压力负载分发到不同服务器上。而随着系统性能压力的增加，只需要在集群中添加新的服务器即可。

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

数据库集群的形式

数据库的集群和拓展同应用程序拓展不同，从数据端来说，一旦涉及到集群，则往往会涉及到数据库层面的数据同步。因此从是否存在数据冗余这个角度来说，我们可以从大面上将集群分为以下两种形式

Share-Disk架构

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

简单的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架构又分为两种
首先是分布式架构。将数据库中的数据按照某一标准分布到多台机器中，查询或插入时按照条件查询或插入对应的分区。
另一种是每一个节点完全独立，节点之间通过网络连接，通常是通过光钎等专用网络。

Share-Nothing架构

在Share-Nothing架构中，每一个节点都拥有自己的内存和存储，都保留数据的完整副本。
通常来说，又可以分为两种，可以负载均衡和不可以负载均衡。
首先谈谈不可负载均衡的集群，在不可负载均衡的技术中，集群中的节点会被分为主节点和辅助节点，主节点向外提供服务，辅助节点作为热备（二阶段事务提交）或暖备（不需要保证事务同步），同时有可能使得辅助节点提供只读的服务。使用这个架构的技术包括：SQL Server AlwaysOn，SQL Server Mirror，Oracle Data Guard这种架构.
这种方式带来的好处包括：

• 辅助节点数据和主节点保持同步或准同步，当搭配第三方仲裁后，可以实现自动的故障转移，从而实现了高可用
• 辅助节点由于和主节点完全独立且数据同步或准同步，因此主节点出现数据损坏后，可以从辅助节点恢复数据（自动或手动）
• 由于Share-Nothing架构使用了本地存储（或SAN），相较于Share-Disk架构在慢速网络时有非常大的性能优势

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

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

而在允许负载均衡中，负载均衡就是就是将对数据库的负载分布到集群中的多个节点上，在集群中的每一个节点都可以对外提供服务，从而达到更高的吞吐量，更好的资源利用率和更低的响应时间。前端通过代理进行调度。使用该类架构的技术包括：MySQL上的Amoeba(架构如图3，摘自MySQL大师陈畅亮的博客：Ubuntu10下MySQL搭建Amoeba系列（文章索引）)，MySQL上的HA Proxy（如图4所示），格瑞趋势(www.grqsh.com)在SQL Server上的Moebius集群(如图5所示)。

图3 MySQL上的Amoeba架构

图4 HA Proxy架构

图5 SQL Server上的Moebius集群

可负载均衡的Share-Nothing架构的好处是每台服务器都能提供服务，能充分利用现有资源，达到更高的吞吐量。
其中Amoeba中可能会涉及到数据分片，数据分片的好处是对于海量数据的处理更加高效，但同时也引入了其他问题，比如说需要应用程序端对应数据分片进行调整、跨分片节点查询的处理问题、每一个数据分片节点是否能够承受各自业务负载的高峰问题等。
该类架构需要实施的人员水平比较高，且需要应用层面做调整，因此更适合于互联网企业。

另一类不涉及到数据分片的架构，比如一种可以使用组合方案，比如说Oracle RAC+F5。另一种是使用单个厂商提供的方案，比如说SQL Server上的Moebius。这类方案集群中的每个节点都会对外提供服务，因此有如下好处：

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

但相比较于MySQL的数据分片，该类方案的弊端也显而易见，因为每一个节点都需要完整的数据集，因此需要占用更多的存储空间。

小结

本文从一个比较高的层面谈到了数据库集群技术。
从数据库应用层面的Share-Disk集群直到集群的最高形式-能够提供负载均衡的集群，并列举了一些主流的商用产品。
集群的存在意义是为了保证高可用、数据安全、扩展性以及负载均衡。如果现在的集群产品不能包含这几个特性，而业务场景也需要，也可以将和一些现有的技术结合来实现，但毕竟不是每一个人都是数据库专家，即使给你一堆工具和材料你也做不出来iPhone，因此在系统设计之初就对数据库方面的方案有所考虑会免去很多麻烦。

参考
数据库集群技术漫谈