细说数据库集群技术

　　信息系统作为企业的神经中枢，在企业的发展过程中起着极其重要的作用，成为保障企业快速发展的重要因素。数据库是用来保存最终计算结果的，所以是整个信息系统中最重要的组成部分，企业的数据库系统应该非常稳健，可是在企业中，决策者可能会发现，为什么我无法访问决策所需的数据，为什么我的应用系统引用的是上周的数据，为什么用户不能查询到实时准确的数据，为什么系统经常出现无法访问，为什么用户经常反映系统的速度非常缓慢，用户体验很差，为什么经常会造成数据丢失？为什么总是不停地更换更高配置的服务器也不能解决这些问题？

　　这些问题的答案其实很简单，传统的数据处理方式由于技术限制已无法满足企业需求。只有实时的数据采集方式，才能为正确的决策提供精准分析的数据支撑，降低信息延迟，保证快速的业务响应，并推动业务价值的提升，只有合理的分担用户的访问压力，才能提升系统的反映速度，带来更好的用户体验，只有保证冗余的数据结构才能保证数据的安全，只有系统具备非常好的伸缩性才具备良好的扩展能力。在接下来的内容中我们将探讨如何解决这些问题。

　　当今世界是一个信息化的世界，我们的生活中无论是生活、工作、学习都离不开信息系统的支撑。而信息系统的背后用于保存和处理最终结果的地方就是数据库。因此数据库系统就变得尤为重要，这意味着如果数据库如果面临问题，则意味着整个应用系统也会面临挑战，从而带来严重的损失和后果。

　　如今“大数据”这个词已经变得非常流行，虽然这个概念如何落地不得而知。但可以确定的是，随着物联网、移动应用的兴起，数据量相比过去会有几何级的提升，因此数据库所需要解决的问题不再仅仅是记录程序正确的处理结果，还需要解决如下挑战：

　　1、当数据库性能遇到问题时，是否能够横向扩展，通过添加服务器的方式达到更高的吞吐量，从而充分利用现有的硬件实现更好的投资回报率。

　   2、是否拥有实时同步的副本，当数据库面临灾难时，可以短时间内通过故障转移的方式保证数据库的可用性。此外，当数据丢失或损坏时，能否通过所谓的实时副本（热备）实现数据的零损失。

　　3、数据库的横向扩展是否对应用程序透明，如果数据库的横向扩展需要应用程序端进行大量修改，则所带来的后果不仅仅是高昂的开发成本，同时也会带来很多潜在和非潜在的风险。

　　面对上述挑战一个显而易见的办法是将多个服务器组成一组集群，这样一来就可以充分利用每一台服务器的资源并将客户端负载分发到不同服务器上，随着应用程序负载的增加，只需要将新的服务器添加到集群即可。

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

　　数据库集群的背景

　　随着经济的高速发展，企业规模的迅猛扩张，企业的用户数量、数据量呈爆炸式增长，在这样一个不断增长的环境下，对数据库提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战：如何提高处理速度，实现数据库的负载均衡；如何保证数据库的可用性、数据安全性以及如何实现数据集可扩性？怎么综合解决这些问题成为众多企业关注的焦点。

　　随着计算机硬件技术的高速发展，PC服务器以其高性能和低廉的价格而倍受广大客户青睐，在WEB应用或高性能计算中，为了追求更高的性能、以及可用性，大家都采用计算机集群技术（将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术）来实现，这种技术不但能满足应用的需要，而且大幅度地节约了投资成本；在数据库上，组建集群也是同样的道理，主要有以下几个原因：

　　原因一：伴随着企业的成长，在业务量提高的同时，数据库的访问量和数据量快速增长，其处理能力和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，若扔掉现有设备做大量的硬件升级，势必造成现有资源的浪费，而且下一次业务量提升时，又将面临再一次硬件升级的高额投入。于是，人们希望通过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更高数据库处理速度时，只要简单地增加数据库服务器就可以得到扩展。

　　原因二：数据库作为信息系统的核心，起着非常重要的作用，单一设备根本无法保证系统的持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。于是，人们希望通过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测故障并转移故障节点的应用，保证数据库的持续工作。

　　原因三：企业的数据库保存着企业的重要信息，一些核心数据甚至关系着企业的命脉，单一设备根本无法保证数据的安全性，一旦发生丢失，很难再找回来。于是，人们希望通过组建数据库集群，实现数据集的冗余，通过多份数据来保证安全性。

　　数据库集群的形式

　　数据库的集群和扩展不像应用程序扩展那样容易，因为从数据库端来说，一旦涉及到了集群，往往会涉及到数据库层面的同步，因此从是否存在数据冗余这个角度来讲，我们可以从大面上把数据库集群分为以下两种形式：

　　Share-Disk架构

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

　　在此基础之上，Share-Disk架构又分为单活和双活，双活即为集群中的每一个节点都可以同时对外提供服务，而单活为集群中只有一个节点可对外提供服务，集群中的其他服务器作为冗余在“活”的节点出现故障时接替该服务器成为对外提供服务的节点。该类架构最典型的产品就是SQLServerFailoverCluster(SQLServer故障转移集群)、NEC的EXPRESSCLUSTER、ROSE的ROSEHA。这种方式的弊端也是显而易见的，如下：

　　①硬件资源的严重浪费，同一时间集群中只有一台服务器活着，其他服务器只能作为冗余服务器。

　　②集群无法提升性能，因为只有一台服务器可用

　　③存储方面存在单点故障，除非在存储层级保证高可用，通常需要昂贵的SAN存储。

　　因此该类方案仅仅可以做到服务器层面的高可用，无法带来性能的提升，也无法解决存储单点故障的问题。因此如果不搭配其他高可用或负载均衡的技术，存在的意义并不是很大。

　　另一类技术是Share-Disk中的双活的技术，与单活技术不同的是，双活的技术虽然也是共享磁盘，但集群中的所有节点都可以对外提供服务，典型的产品就是Oracle的RAC。RAC的技术性非常的高，因此需要水平比较高的人来运维系统。RAC设计的初衷并不是为了性能，而是为了高可用和可扩展性，如果应用程序不是针对RAC架构设计和开发的，则将应用程序迁移到RAC上由于blockcontention(blockbusywaits)可能会导致性能的急剧下降，并且节点越多性能下降越明显。

　　Share-Nothing架构

　　Share-Nothing架构又分为两种，首先是分布式架构。将数据库中的数据按照某一标准分布到多台机器中，查询或插入时按照条件查询或插入对应的分区。

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

　　在Share-Nothing架构中，每一个节点都拥有自己的内存和存储，都保留数据的完整副本。通常来说，又可以分为两种，可以负载均衡和不可以负载均衡。

　　首先谈谈不可负载均衡的集群，在不可负载均衡的技术中，集群中的节点会被分为主节点和辅助节点，主节点向外提供服务，辅助节点作为热备（二阶段事务提交）或暖备（不需要保证事务同步），同时有可能使得辅助节点提供只读的服务。使用这个架构的技术包括：SQLServerAlwaysOn，SQLServerMirror，OracleDataGuard这种架构带来的好处包括：

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

　　②辅助节点由于和主节点完全独立且数据同步或准同步，因此主节点出现数据损坏后，可以从辅助节点恢复数据（自动或手动）

　　③由于Share-Nothing架构使用了本地存储（或SAN），相较于Share-Disk架构在慢速网络时有非常大的性能优势

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

　　①扩展能力非常有限

　　②对性能没有提升，因为涉及到各节点的数据同步，甚至带来性能的下降

　　③辅助节点如果可读，虽然提升性能，但需要修改前端应用程序，对应用程序不透明

　　另一类Share-Nothing架构中，是允许负载均衡的。所谓负载均衡就是就是将对数据库的负载分布到集群中的多个节点上，在集群中的每一个节点都可以对外提供服务，从而达到更高的吞吐量，更好的资源利用率和更低的响应时间。前端通过代理进行调度。使用该类架构的技术包括：MySQL上的Amoeba(架构如图3）MySQL上的HAProxy（如图4所示），格瑞趋势(www.grqsh.com)在SQLServer上的Moebius集群(如图5所示)。

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

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

　　①由于每一个节点都可以对外提供服务，因此可以提升性能

　　②扩展性得到提升，可以通过向集群添加节点直接进行Scale-Out扩充

　　③由于前端应用通过代理连接到集群，而集群中的每一个节点都保持完整的数据集，因此不存在分片不到位反而造成性能下降的问题，因此对应用程序端完全透明

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

　　数据库集群的分类

　　一般来讲，数据库集群软件根据侧重的方向和试图解决的问题划分为三大类：负载均衡集群（Loadbalancecluster，LBC）侧重于数据库的横向扩展，提升数据库的性能；高可用性集群（Highavailabilitycluster，HAC）侧重保证数据库应用持续不断；高安全性集群（HighSecuritycluster，HSC）侧重于容灾。

　　按照集群的架构可分为：共享磁盘型，非共享磁盘型。

　　当前各大主要商业数据库上应用的集群

　　①Oracle'sRealApplicationCluster(RAC)

　　②MicrosoftSQLClusterServer(MSCS)

　　③IBM'sDB2UDBHighAvailabilityCluster(UDB)

　　④SybaseASEHighAvailabilityCluster(ASE)

　　⑤MySQLHighAvailabilityCluster(MySQLCS)

　　⑥基于IO、磁盘或操作系统等非数据库引擎的集群

　　小编结语：

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

　　更多内容尽在课课家教育！