系统架构设计师【论文-2013年 试题4】: 论分布式存储系统架构设计（包括写作要点和经典范文）
论分布式存储系统架构设计（2013年 试题4）
分布式存储系统（Distributed Storage System)通常将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。 请围绕“论分布式存储系统架构设计”论题，依次从以下三个方面进行论述。
- 概要叙述你参与分析和开发的分布式存储系统项目以及你所承担的主要工作。
- 简要说明在分布式存储系统架构设计中所使用的分布式存储技术及其实现机制，详细叙述你在具体项目中选用了哪种分布式存储技术，说明其原因和实施效果。
- 冗余是提高分布式存储系统可靠性的主要方法，通常在分布式存储系统设计中可采用哪些冗余技术来提升系统的可靠性？你在具体项目中选用了哪种冗余技术？说明其原因和实施效果。
写作要点
一、简要描述所参与分析和开发的分布式存储系统项目，并明确指出在其中承担的主要任务和开展的主要工作。
二、说明在分布式存储系统架构设计中所使用的四种主要分布式存储技术，并根据考生所参与的实际项目，详细叙述所选用的一种分布式存储技术，并说明选择该技术的原因和实施效果。
在分布式存储系统架构设计中所使用的分布式存储技术主要包括四类：
- 集群存储技术。集群存储系统是指架构在一个可扩充服务器集群中的文件系统，用户不需要考虑文件是存储在集群中什么位置，仅仅需要使用统一的界面就可以访问文件资源。当负载增加时，只需在服务器集群中增加新的服务器就可以提高文件系统的性能。集群存储系统能够保留传统的文件存储系统的语义，增加了集群存储系统必须的机制，可以向用户提供高可靠性、高性能、可扩充的文件存储服务。
- 分布式文件系统。分布式文件系统是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。分布式文件系统以透明方式链接文件服务器和共享文件夹，然后将其映射到单个层次结构，以便可以从一个位置对其进行访问，而实际上数据却分布在不同的位置。用户不必再转至网络上的多个位置以查找所需的信息。
- 网络存储技术。网络存储系统就是将“存储”和“网络”结合起来，通过网络连接各存储设备，实现存储设备之间、存储设备和服务器之间的数据在网络上的高性能传输。为了充分利用资源，减少投资，存储作为构成计算机系统的主要架构之一，就不再仅仅担负附加设备的角色，逐步成为独立的系统。利用网络将此独立的系统和传统的用户设备连接，使其以高速、稳定的数据存储单元存在。用户可以方便地使用浏览器等客户端进行访问和管理。
- P2P网络存储技术。P2P网络存储技术的应用使得内容不是存在几个主要的服务器上，而是存在所有用户的个人电脑上。这就为网络存储提供了可能性，可以将网络中的剩余存储空间利用起来，实现网络存储。人们对存储容量的需求是无止境的，提高存储能力的方法有更换能力更强的存储器，另外就是把多个存储器用某种方式连接在一起，实现网络并行存储。相对于现有的网络存储系统而言，应用P2P技术将会有更大的优势。P2P技术的主体就是网络中Peer,也就是各个客户机，数量是很大的，这些客户机的空闲存储空间是很多的，把这些空间利用起来实现网络存储。
三、冗余是提高分布式存储系统可靠性的主要方法，冗余的存储结构可以保旺部分服务器失效时，数据服务仍可正常访问。常用的冗余技术包括：数据备份，数据分割，门限方案，纠错编码和纠删编码等。考生根据所参与的实际项目指出采用了何种冗余技术，并说明其原因和实施效果。
经典范文
范文一
摘要
分布式数据库系统把应用所需的数据存放在多个数据库服务器上，完成某个数据操作要涉及到访问多个服务器，这适用于某种特定需要的应用。我在主持设计开发的一个MIS系统中，为了达到了在低速网络通道下有效提高应用程序性能的目的，使用了Sybase的分布式数据库技术。我设计的这个系统是采用典型的c／s结构，但许多客户端连接服务器的网络采用电话线拨号，速度有限，传统Windows 界面的客户端应用程序相应速度比较慢。考虑到B／S结构也避免不了大量数据从服务器端传输到客户端，我认为WEB界面并不能有效解决这个问题，所以采用了优化数据库结构的方法，把数据分两部分存放，基础数据放客户机，会员资料主要采用键码放服务器，应用程序再现数据时从服务器取键码，到客户机取对应的解释，由于键码的数据量少，网络传输便快。在构建这个分布式数据库系统的过程中，我着重研究并解决了数据同步和事务协调的问题，取得了良好的应用效果。我认为，分布式数据库系统的技术在Intenet时代正当其道，大有发展前景。
正文
分布式数据库系统把数据存放在多个数据库服务器上，当应用提取所需数据时，要访问多个服务器，综合多点数据才能完成。分布式数据库技术在很多场合得到了应用。譬如某企业随着业务量的扩大，原有数据库服务器已经达到了容量和性能极限，如果不希望丢弃原有投资，可以建立另外一套新的数据库，跟原有的系统组成一个分布式数据库系统，给应用提供透明统一的数据访问。还有，如果某企业分成多个业务部门，而且地域分散，可以在某个部门放置单独的数据库服务器，用于存放该部门最常用的数据，而部门和部门之间相互引用的数据可以通过分布式数据库技术来方便地完成。分布式数据库不是简单地把集中数据库分散实现，而是针对某种特定应用需要而诞生，它必然具有自己特有的性质和特征，需要在上面做许多的工作，来满足应用的要求。
我在设计、开发一个MIS系统时，针对应用的需要而引入分布式数据库技术，取得了良好的效果。该系统针对会员资料的管理而设计，用于管理会员入会、缴纳会费、申请资助、办理资助审批、关系转移、退会和注销手续等等业务流程。分三个级别的应用权限–基层单位级、总公司级和集团公司级，各个级别只能操作各自范围内的业务数据。该系统采用典型的c／s结构，后台数据库采用Sybase，前端应用采用PB开发工具来设计标准的Windows 操作界面。我在其中任系统分析和数据库设计的角色，担任了调查业务需求、业务建模和数据库建模、数据库设计以及指导应用程序测试、优化系统和应用的性能等等一系列工作。
由于客户端地域的分散，遍及多个省境内，许多使用该系统的基层单位连接服务器数据库的网络采用电话线拨号方式，速度有限，在使用客户端应用程序时感觉界面速度很慢。经过分析，认识到许多操作都要从服务器中取数据，速度慢就慢在数据访问上。服务器是没有性能瓶颈的，问题出在网络速度上。不可能要求众多使用客户改善和升级他们的网络，只能充分挖掘软件的潜力，来适应这种低速网络的使用模式。
经探讨，结合关系数据库的知识，认识到，应用程序的每一次数据库操作，都要访问多个相关联的表，其中，有会员资料表和基础数据表，会员资料表中存放许多的键码值，在基础数据表中有键码相应的解释。键码值的数据量比较少，而基础数据是静态的，几乎不会更改。如果考虑把会员资料放在服务器上，基础数据放在客户端，当应用程序中访问数据时，总是从服务器上存取会员资料，从客户端提取会员资料中键码的相应解释。由于键码的数据量少，便减少了网络上传递的数据量，从而提高了界面的响应速度。
同时考虑到基层单位总是操作自己所属的部分会员，增删转移操作少，会员列表比较固定，而每一项业务操作都涉及到要从会员列表中查找定位到某个会员，所以会员列表是最常访问的数据项。把会员列表从会员资料数据中抽取出来，也放置在客户端，这样，便进一步改善了性能。
把数据分散存放只是工作的第一步，接下来要考虑应用程序怎样访问这种分布式数据。开发应用时，如果每一功能都针对两个数据库进行，就带来了很多麻烦。所以，我们研究了Sybase的分布式数据库技术，决定采用了CIS（组件集成服务）部件，来合并两个数据库成一个统一的分布式数据库。应用程序只要连接一个数据库，就可以透明统一访问到两个数据库中的数据。
该技术具体实施方法是，在客户端数据库中建立一个对服务器数据库的远程访问服务名，包含访问地址、登录用户名、登录密码等等关键的连接信息；并且对服务器中会员资料数据表建立一个本地代理表，结构和服务器中远程表完全一样，它是访问服务器中会员资料的中转和代理。客户端应用程序访问本地代理会员资料表时，实际上是通过预定义的远程访问服务名中包含的连接信息到服务器中对应的实际会员资料表中访问数据。这种访问对于客户端完全透明，感觉不到是从物理上独立的两个服务器中存取数据。所以，这种数据库结构是典型的分布式数据库。
部署这种分布式数据库不是难事，只要在客户端和服务器上安装12.0版以上的数据库服务器，在客户端服务器上建立远程服务名和代理表即可。由于Sybase数据库的安装支持脚本方式，在客户端应用程序的标准安装过程中，嵌入Sybase数据库的安装和配置脚本，就自动化地完成了所有工作。
在实际使用该分布式数据库系统的过程中，遇到了几个问题。第一，数据同步。客户端基础数据不是绝对静态的，也有变化，因此在服务器端要设置一个统一的基准，称为主点数据。客户端总是复制使用，称为复制点数据。如何及时感知到服务器端主点数据的变化，有效率地复制到客户端，是个难题。Sybase针对这种应用场合，提供了复制服务器技术，但为了避免过于复杂，我们实际采用应用程序来管理同步。当服务器端主点数据有了更改时，保存一个相应的标识和时间戳，客户端应用在登录服务器时，检查这种标识，一检测到了数据有更新，就首先下载，然后再进入系统正常使用。这种方法实现起来，增加了额外的开发量，且不能判别绕过应用程序对数据的直接修改，但是，是最简单和有效的方法。
第二个问题是事务协调问题。物理上独立的两个数据库，在协同操作时，如果服务器正好停机或者网络故障，完整的一个事务没能完成，就会“事务崩溃”。虽然Sybase CIS内嵌了两阶段提交技术，能够自动恢复。但是应用程序在这种情况下，敏感性不够，操作界面会无端凝固，影响了使用的方便性。我们针对PB对于连接的判断和感知，用了一个小小编程技巧，使应用程序能够及时感知到数据库连接故障，及时停止和恢复事务，使操作界面表现友好灵活。
以上遇到的这些问题，都找到了解决办法。分布式数据库技术的应用并不是非常复杂，它往往为解决特定问题、满足特定需要而被采纳，使用得当，会给应用带来了许多便捷。
在当今信息社会里，互联网络带来了相互连通的便捷，而且知识爆炸，数据的分布式访问是个必然趋势。潮流兴起的XML技术，提供了各种平台数据库之间的一个公共数据访问标准，可能会用来构建更加灵活、适应性更强的分布式数据库技术。
范文二
摘要
本文通过XXX高速公路收费系统（以下简称收费系统），来论述分布式数据库的设计与实现。收费系统是我公司近年来接的较为大型的项目，管理结构为三层结构：公司级、收费中心级、收费站级，各级之间即可独立的完成自身业务，又有自上而下的管理关系。收费中心、收费站均为三层c／s结构，公司级采取B／S结构。该系统的数据库也按照三层来设计，收费站存放本站的所有流水数据，收费中心存放所有数据，公司本部存放查询用汇总数据，收费站与收费中心使用事务复制来同步数据，而收费中心与公司本部使用快照复制来同步数据，并且使用分级的方法来测试收费站、收费中心与公司本部之间的数据同步。
在本项目的开发过程中，我担任了数据库的设计工作。
正文
2020年10月-2021年12月我公司开发了高速公路收费系统（以下简称收费系统），收费系统项目从管理层面分为三层结构：公司级、收费中心级和收费站级。
- 公司本部：供领导、运营部、财务部等业务部门了解业务情况、检查工作。B／S 结构各部门通过Web服务器查询数据库服务器，而公司数据库服器定时要求中心数据库服务器复制汇总数据。
- 收费中心：收费系统的管理中心下达管理制度，管理数据到收费站，接收统计收费站的收费数据，上报汇总数据到公司，负责日常的管理工作。
- 收费站：具体进行收费的单位，收费车道的数据通过通信系统实时上传到收费站数据库保存、分类、汇总，并且实时传送收费中心下达的数据库管理，并通过通信子系统下载到车道收费机上具体实施。
系统采用三层c／s与B／s的混合结构，收费中心与收费站为三层c／s结构，而公司级为B／S结构。我在项目中担任了数据库的设计工作，负责数据库的设计、测试及实施。
数据库设计：此收费系统的结构较为复杂，分为公司级、收费中心、收费站三级管理结构，既可独立工作，又有管理的联系。数据实时传送到收费站数据库服务器，再实时传送到收费中心数据库服务器。在数据库设计方面我们按物理的分布也分为三层结构。
在收费站，根据系统的需求分析的结果，一辆车通过收费站时产生的最基本的数据有：通过日期、时间、车型、收费类型及收费金额，因为收费标准不轻易改变，考虑到我们采用的是专用的车道收费机，存储量较小，所以收费金额项在此处不计入数据库，上传至收费站数据库服务器后，可以用车数乘以此类车型的收费标准而得到。当车道收费机上传数据到数据库时，还要加上工班、车道及收费员信息，保证数据的唯一性，所以我们把日期、时间、工班、车道、收费员、收费类型、车型设为组合主键，为车辆流水数据。收费员下班后还要上缴实收金额，因此还要保存实收金额，包括日期、工班、收费员及实际收费金额，为工班收费数据。在此基础上，分析、汇总数据，得到以下几类数据：
- 业务类型数据：车辆流水数据、工班收费数据、车道开通情况、收费员上班情况；
- 扩展的数据：为了查询、打印的方便、高效，流水表经过分类汇总，产生了以车道分类统计的车流量表（日、月）、以收费员来分类统计的收费金额表（日、月）及不收费车辆统计表；
- 管理类型数据：收费标准、收费员信息、收费站信息、车道信息、工班信息、收费类型信息；从全局应用的角度出发，各收费站存放本站的数据，收费中心的数据库则存放所有数据，并对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性、可用性，使系统易于扩充，也提高了局部应用的效率，减少了通讯代价，同时也使得各处理机之间的相互干扰降到最低。
- 公司总部存放所有收费站的汇总数据，通过浏览器进行查询。
数据的分布：在收费中心数据库服务器与收费站数据库服务器的数据关系中，由于收费站的数据是收费中心数据的子集，我们采用了水平分片的方式，通过并运算实现关系的重构。在收费中心数据库服务器与公司总部数据库服务器的数据关系中，数据是按照其应用功能来划分的，所以我们采用了垂直分片的方式。
数据分布在多个地点，为了保证数据的一致性及完整性，我使用了事务复制和快照复制两种数据同步的方式，在收费中心与收费站之间使用事务复制，而在收费中心和公司总部之间使用快照复制。
对于业务类型的数据，收费站在本地存放收费车辆的实时数据，而用户也要求收费中心也要实时的收费车辆数据，延迟不超过2秒，所以我采用事务复制进行业务数据的同步，收费站只需将更新的数据发送到收费中心的数据库即可。具体过程如下，把收费站的数据库作为出版者和分发者，收费中心的数据库作为订阅者，对收费站的数据建立快照代理，并在分发数据库中记录同步状态的信息。每一个使用事务复制的收费站数据库均有自己的日志读取代理，运行在分发者上并连接出版者。分发代理的任务是将分发数据库中保持的事务任务直接推动到订阅者。当推订阅被创建时，每个为立即同步而建立的事务出版物通过自己的分布代理运行在分发者上并与订阅者相连。
而管理型的数据是在收费中心设置，虽然修改的频度不是很大，但在修改后即要发生作用，所以也采用事物型复制，收费中心为出版者，收费站为订阅者。将管理型的数据发布到各收费站。
由于公司总部不需要实时更新，所以收费中心数据库服务器与公司总部服务器之间的数据同步设置为快照复制，公司总部数据库中建立收费中心表的快照，对这些数据的修改在收费中心进行，把收费中心数据库服务器设置为出版者，出版物为汇总数据，公司总部数据库服务器设置为订阅者，快照代理将准备包含有被出版数据表的结构与数据的快照文件，在分发者上存储这些文件，并在分发者的分发数据库中记录同步任务。在收费中心数据库服务器上建立一个作业，设置为每天早上8点更新一次（收费日的天为8点到第二天8点），公司总部就能得到截止到前一天所有收费站的汇总数据。
测试：数据库设计好了，就要对它进行测试。我们的测试策略为分步测试：首先测试收费站数据的正确性及完整性，在多台收费机上同时输入几组车型、收费类型的数据，查询数据库的流水数据是否正确，再看汇总数据是否正确；收费站正确后，再测试收费中心的数据的正确性、完整性及延时；再测试公司总部的数据正确性、完整性。
一开始我们把所有的表都建立在一个出版物中，但在测试中我们发现，由于收费站一个表的错误而造成的复制的中断，经常要重新配置复制，所有的表都要重新选择及设置一遍，非常繁琐，我们采取一个表建立一个出版物的方法来简化操作，只要恢复出错的复制，其他的复制仍然能正常执行，而且哪一个表的复制发生中断也很明确，不仅简化了操作，也加快了处理时间，就是日后用户维护起来也简单明了。
在设计过程中，基于查询及安全性的需要，我们大量的使用了视图，第一加快了查询速度；第二也防止了人为因素造成的数据的更改。
按照以上的设计方案实施后，完全满足高速公路系统对数据实时性和完整性的要求，系统目前只在内部使用，而以后全省的高速公路收费系统实行联网，在外网上发布信息，那时数据的安全性及查询的响应速度将是我们考虑的重点。
原文地址：https://blog.csdn.net/cui_yonghua/article/details/140495302
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！