王晓燕

摘要： 分布式数据库提供更加强大的并发处理能力、更好的资源扩展性以及架构弹性，近年来被广泛应用于商业领域。本文通过对分布式数据库的深入研究以及多种部署方案的对比分析，提出适用于某企业互联网数据平台的数据部署方案。

关键词： 分布式数据库； 集中式数据库； 共享数据库集群； 非共享数据库集群

中图分类号：TP392

文献标志码：A

文章编号：2095-2163（2017）04-0056-04

0引言

近年来，随着互联网企业的快速发展，分布式数据库系统已广泛应用于商业领域。较之传统的集中式数据库架构，其性能优势在于能够提供更为强大的并发处理能力、更为优质的资源扩展性和架构弹性，但却在数据一致性方面略弱于集中式数据库。业界较为流行的分布式数据库架构主要分为4种：多活共享数据库集群、大规模平行处理数据库（MPP）、分布式数据文件处理系统（典型产品Hadoop）和基于数据中间件调度管理的非共享数据库集群[1]。其中，多活共享数据库集群和基于数据中间件调度管理的非共享数据库集群更适用于面向客户交易的应用场景，而其它2种架构则主要适用于大数据分析的应用领域。

某企业在自身互联网应用平台建设过程中，根据其金融行业背景及业务特点，并结合现有技术能力和管理水平，研发设计并实现了一种面向大型互联网应用平台的基于多活共享数据库集群和非共享数据库集群相结合的分布式数据库系统架构。

1技术应用简介

目前业界成熟的多活共享数据库集群主要通过Oracle RAC和DB2 pureScale两种技术产品展开核心研究，并且仅在计算资源层面上研发获得了分布式架构，而在数据的逻辑结构层面并未真正推行分布式设计。基于数据中间件调度管理的非共享数据库集群的最佳实现是采用MyCAT中间件+MySQL數据库组成的分布式集群。该架构中，数据可被灵活地垂直拆分和水平切分，是真正意义上的分布式数据库系统架构，但却也在一定程度上提升了与其相关的技术复杂度和管理复杂度。

国内互联网应用平台的案例中，大型互联网公司出于对降低成本及技术发展自主可控等因素的考虑，更倾向于使用MySQL分布式数据库技术方案。而金融企业考虑到开源数据库产品的技术风险较大，自身技术研发和维护能力有限等因素，更倾向于使用由商用数据库产品（Oracle、DB2等）构建的分布式数据库方案。但也有数家机构技术理念颇显前卫，正尝试在互联网应用平台建设中使用开源技术及产品，并采取循序渐进的稳健策略，先在外围应用系统中使用，而随着开源技术和产品成熟度提高及自身技术团队和能力建设的加强，则逐步向重要应用系统形成有益拓展与推广。

2产品选型分析

DB2 pureScale技术在近几年才趋于成熟和商用，使用案例极少，容易在运用时遭遇首发故障，需经过市场和时间检验。Oracle RAC技术问世已达十余年，且得到业界的普遍认可，并在金融领域推出较多使用案例，因而呈现出颇高的技术成熟度。MySQL分布式数据库架构的灵活性和扩展性均为较好，成本投入经济实惠，在超大规模互联网应用平台案例中业已得到复杂交易和超高强度并发交易场景的实际检验。

基于前述讨论可知，综合考虑到互联网应用领域的IT架构特点、金融行业的风险要求，以及引入并掌握多种主流数据库产品技术对企业未来发展提供更加灵活、更为多元化的IT服务能力则将具有可观重大的现实意义。因而研究中摒弃传统的“小型机+DB2数据库”技术架构，而是选择更为开放的“X86服务器平台+Oracle或MySQL数据库”的技术路线。

3数据应用场景分析

该企业数据应用场景主要分为3类：前端交互应用类数据、中端交易应用类数据、后端账务核算及平台管控类数据。其中，前端交互应用类数据主要包括：网银、商户、营销活动、交易推送等；该类数据不采用分库分表设计思想，因此集中式数据库设计可降低技术复杂度。而中端交易应用类数据主要包括：账户、支付、产品、客户等。该类数据采用分库分表设计思想，旨在更好地满足应用产品及服务的快速部署和迭代的需求，故采用分布式数据库设计将更为现实合理，可极大地提高数据拆分或整合的灵活性和扩展性。后端核算及管控类数据主要包括账务核算、平台管理、平台监控等。核算账务类数据对数据一致性要求极高，而平台管理及监控等数据的规模较小，无需采用分库分表设计，故采用集中式数据库结构更为适合。

4数据库系统设计目标

针对互联网应用平台的相关特性要求，对数据库系统设计方案提出以下定制目标[2]：

1）高可用性。互联网应用平台数据库系统应在逻辑和物理层面提供良好的高可用性设计，确保设备硬件及数据逻辑副本具有多份冗余。

2）高并发处理能力。互联网应用平台数据库系统不但要具备正常日间交易的处理能力，还要能在特殊时段或秒杀场景下平稳地应对高并发交易量的冲击。

3）可扩展性。互联网应用平台数据库系统能够良好地适应业务交易量的发展趋势，在各种性能和容量资源方面都具有强大的可扩展能力。

4）灵活性。针对应用系统的快速迭代和变更，互联网应用平台数据库系统应配备较强的部署灵活性。能够较好地适应数据拆分和整合的变化需求。

5）业务连续性。互联网应用平台数据库系统应形成较强的容灾能力，能够在人为和自然灾害发生后尽快恢复系统服务状态，尽可能降低数据丢失量和影响范围，同时符合数据安全要求的关键性指标也可得到有效控制与保障。

5数据库系统技术方案

为满足互联网应用平台数据库系统的设计目标要求，提出3种技术方案。在此，给出研究论述如下。

5.1A方案

A方案基于Oracle RAC的数据库双活集群设计思想，全部采用高端4路X86机架式服务器，根据不同应用需求建立4组Oracle RAC数据库双活集群，每组集群由2台物理服务器组成。利用Oracle RAC技术实现本地高可用和性能负载均衡。endprint

集群A部署的数据库包括：网银、商户、营销活动、交易推送等；集群B部署的数据库包括：账户和支付；集群C部署的数据库包括：产品和客户；集群D部署的数据库包括：账务核算、平台管理、平台监控等。研究中，A方案部署结构设计如图1所示。

随着业务发展和性能需要，可将数据库集群规模由2个节点在线扩充至4个节点。在集群B和C部署的数据库，可通过新建RAC集群B′和C′实现数据模块的水平拆分。数据库内部的表可通过分片设计以提高数据结构的使用性能和容量。

数据库的文件和数据全部存放在外接共享存储阵列上，并利用存储底层远程复制技术实现数据容灾。若未来需要建立异地容灾环境，则采用Oracle ADG技术将主生产中心的数据异步复制到异地容灾环境。

5.2B方案

B方案基于Oracle RAC和MySQL的数据库混合架构设计思想，主要采用2种硬件架构的服务器类型：部署Oracle RAC集群的服务器采用高端4路X86机架式服务器，其结构与A方案类似；部署MySQL數据库的服务器采用中端2路X86机架式服务器。利用MySQL主从复制技术实现高可用集群[3]，同时给每个集群配备一个准同步复制的只读数据库，通过读写分离模式提高性能负载。

Oracle RAC集群A部署企业网银、商户、营销活动、交易推送等数据库；RAC集群B部署核算、平台管理、监控等数据库；建立2组MySQL高可用集群分别部署账户、支付和产品、客户等数据库。

随着业务增长及性能要求不断提高，可对后端交易类应用的数据库进行多节点水平切分来构建数据模块的分拆部署，提高数据库的整体性能。数据库内部的表可通过分片设计提高数据结构的使用性能和容量。

数据库的存储可以采选2种处理模式。其中，Oracle RAC数据库集群的数据文件存放于外接共享存储阵列；MySQL数据库是将数据文件存放于数据库服务器的内置硬盘（SSD硬盘或闪存卡，满足数据库高读写性能要求），并利用RAID10对其进行数据保护和性能提升。采用内置硬盘的存储方案不受制于共享式存储阵列和SAN资源承载能力以及空间束缚，能够更为快速、灵活地扩充数据库服务器节点。

容灾方面，Oracle RAC集群将利用存储底层远程复制技术实现容灾。而MySQL分布式数据库的主从复制技术无法实时同步复制，不能保证数据零丢失，因此普遍采用的容灾策略是尽量把数据模块缩小、打散，并选择多站点部署（3个及以上）。该策略可使MySQL数据库极大地降低对容灾环境的依赖，由容灾架构变为分布式多活架构，严格控制故障和灾难对数据的影响范围，减少数据丢失量。

因此，B设计方案是将交易类应用的数据库横向拆分成2个数据单元，每个单元均包含相互关联的账户、支付、产品、客户信息。将2个数据单元分别部署在主生产中心和同城灾备中心，通过数据库主从异步复制技术（RPO>>0）在对端建立容灾数据库环境；若网络资源存在局限性而难以达成跨站点部署，可先将MySQL高可用集群全部部署于主生产中心，同城灾备中心仅存放异步复制的数据库容灾环境，设计不足即是将会产生大量数据丢失。未来须通过机房环境和网络资源的改善，逐步实现跨更多站点的分布式部署架构。也可将数据库文件存放在外接共享存储阵列，利用SRDF技术实现数据同步复制的同城灾备中心，确保数据零丢失，但在一定程度上却会降低数据库部署的灵活性。

研究中，B方案部署结构设计则如图2所示。

5.3C方案

C方案基于Oracle多种技术结合的数据库架构设计思想。在服务器选型方面，采用2种硬件架构的服务器类型：部署Oracle RAC集群的服务器采用高端4路X86机架式服务器，其结构与A方案类似；部署Oracle ADG高可用数据库集群的服务器采用中端2路X86机架式服务器。高可用集群内部节点之间采用数据同步复制技术确保本地数据零丢失，并通过读写分离提高性能负载。

Oracle RAC集群A部署企业网银、商户、营销活动、交易推送等数据库；RAC集群B部署核算、平台管理、监控等数据库；建立4个Oracle ADG高可用集群分别部署后端交易类应用的账户、支付、产品、客户等数据库；也可建立2个数据库高可用集群，每个集群分别部署2个数据库，需要根据非功能测试和验证后确定最终方案。

面对业务增长及性能要求的不断提高，Oracle RAC集群可通过动态扩充节点来增强处理能力。而针对后端交易类应用的数据库，当单个高可用集群资源性能不足时可快速建立一个新集群，将数据库水平切分为若干数据模块，部分迁移至新建集群，达到提高该数据库整体性能的研究效果；数据库内部的表可通过分片设计改进数据结构的使用性能和容量。若某个数据库需要提升读操作性能，可利用ADG技术为该数据库实例建立2个只读副本。

数据库的数据文件都存放在外接共享存储阵列上，并通过存储底层远程复制技术实现数据的同城容灾。未来机房环境、网络资源及存储资源满足条件时，可借鉴B方案将容灾架构调整为跨站点多活架构。

研究中，C方案部署结构设计即如图3所示。

6结束语

面对开源数据库技术的互联网应用正进入普遍优化实施的潮流趋势下，企业的互联网应用平台的项目建设既要注重相关技术产品的安全稳定运行，更重要的是客观理性地认识到这种技术趋势在其自身良好发展背景下所体现出的合理性和必然性。因此，综合考虑技术发展、方案可行性、应用适配[CM（26]性、成本投入、运维管理及自身发展等诸多方面因素，最终选择基于Oracle RAC双活集群和MySQL分布式集群相结合的方案B作为该企业互联网应用平台的数据库系统技术方案。互联网应用平台的数据库系统建设是一个非常复杂、庞大的项目，除了最为关键的架构问题外，还有很多技术细节问题需要寻求有效解答。比如MySQL数据库的分片方案、分布式SQL语句的编写规范、分布式数据库系统的数据迁移和运维管理体系等。本文旨在讨论互联网应用平台数据库系统架构层面的设计与分析，其他技术问题仍有待在后续工作中展开重点深入的探讨与研究。

参考文献：

[1] 周英飚. 通用无共享数据库集群研究与实现[J]. 计算机工程与应用，2007，43（32）：156-160.

[2] 陈争航. 分布式数据库系统研究与应用[D]. 成都：西南交通大学，2014.

[3] 陈冠华. 基于消息中间件的高可用MySQL集群的研究[D]. 武汉：华中科技大学，2007.

[4] 胡金柱，谭支鹏. 分布式对象数据库系统中的对象管理策略[J].小型微型计算机系统，2001，22（1）：96-99.

[5] 戴婉荣. 基于分布式数据库的数据同步机制的研究与应用[D]. 武汉：武汉理工大学，2010.

[6] 苏燕强. Oracle分布式数据库及其应用研究[J]. 计算机应用与软件，2004，21（8）：36-37，121.

[7] 陈珉喻，喻丹丹，徐国庆. 分布式数据库系统中数据一致性维护方法研究[J]. 国防科技大学学报，2002，24（3）：76-80.endprint