《基于智能移动终端的分布式管理平台的设计与实现》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。
硕士学位论文基于智能移动终端的分布式管理平台的设计与实现DESIGNANDIMPLEMENTOFDISTRIBUTEDMANAGEMENTPLATFORMBASEDONTHESMARTMOBILEDEVICES朱旭哈尔滨工业大学2016年12月万方数据 国内图书分类号：TP311.1学校代码：10213国际图书分类号：004.45密级：公开硕士学位论文基于智能移动终端的分布式管理平台的设计与实现硕士研究生:朱旭：导师:张乃通：教授申请学位:工程：硕士学科:电子与通信工程：所在单位:深圳研究生院：答辩日期:20：16年12月授予学位单位:哈尔滨工业大学：万方数据 ClassifiedIndex:TP311.1U.D.C:004.45DissertationfortheMasterDegreeinEngineeringDESIGNANDIMPLEMENTOFDISTRIBUTEDMANAGEMENTPLATFORMBASEDONTHESMARTMOBILEDEVICESCandidate：ZHUXuSupervisor：Prof.ZHANGNaitongAcademicDegreeAppliedfor：Master’sDegreeofEngineeringSpeciality：ElectronicandCommunicationEngineeringAffiliation：ShenzhenGraduateSchoolDateofDefence：December2016Degree-Conferring-Institution：HarbinInstituteofTechnology万方数据 摘要摘要移动互联网技术以及移动通信技术近些年来取得了飞速的发展，同时带动了以智能手机为代表的智能移动终端制造领域相关技术的快速发展。在当下移动互联网时代，移动终端产品更新换代的速度远远高于传统计算机更新速度，且智能移动终端的数量远远高于计算机的数量，已经在人们日常生活中扮演着非常重要的角色。然而，由于移动终端的硬件性能过剩，导致了在移动终端上海量的资源处于闲置的状态无法使用。本文的主要的研究目标就是实现对以智能手机为代表的智能移动终端上闲置资源的利用。所采取的主要技术路线是：参考借鉴目前现有的计算机领域中与分布式相关的存储、计算以及资源调度方面的系统架构，自己设计并实现一套基于智能移动终端的分布式管理平台，该平台需要实现对移动终端上闲置的资源进行调用；同时针对移动终端的特点，有针对性的对平台进行相应的优化。论文基于Hadoop分布式系统和Kubernetes分布式系统架构和原理的基础上，借助移动互联网技术，设计并实现了一套基于智能移动终端的分布式管理平台。该平台能够实现对智能移动终端上的闲置的存储和计算资源加以整合并实际利用起来。针对移动终端自身特性带来的文件存储的可靠性和有效性问题，分别提出了基于LT喷泉码和基于信道自适应分配的两种解决方案，分别提升了文件在以移动终端为基础的平台上存储可靠性以及传输的有效性；为了避免影响用户对移动终端的正常操作，提出了终端忙碌状态策略、存储资源自动释放策略以及计算池策略。通过上述的方案跟策略使得平台的可用性得到了进一步的提升。关键词：移动互联网；智能移动终端；分布式系统；喷泉码；Hadoop；Kubernetes-I-万方数据 AbstractAbstractMobileInternettechnologyandmobilecommunicationtechnologyinrecentyearshasmaderapiddevelopmentandithasledtosmartphonesastherepresentativeoftheintelligentmobileterminalmanufacturingtechnology-relatedrapiddevelopmentatthesametime.DuringthecurrenteraofmobileInternet,mobileterminalproduct’supdateismuchfasterthanthetraditionalcomputer’supdate,andthenumberofsmartmobileterminalsismuchmorethanthenumberofcomputers.Lthasplayedaveryimportantroleinpeople’sdailylives.However,duetotheexcessivehardwareperformanceofthemobileterminal,itisimpossibletousealargeamountofresourcesonthemobileterminalswhichareinanidlestate.Themainresearchgoalofthispaperistousetheidleresourcesonsmartmobileterminals.Themaintechnicalrouteistodesignandimplementadistributedmanagementsystembasedonintelligentmobileterminalbyreferringtotheplatformarchitectureofstorage,computingandresourceschedulingwhicharerelatedtodistributedsysteminpresentcomputerfield.Theplatformneedstoachievethemobileterminal’sidleresourcesandmakesomeoptimizationsforthedifferencebetweenthemobileterminalsandthecomputer.BasedonthedeepunderstandingofHadoopdistributedsystemandKubernetesdistributedsystem’sarchitectureandprinciple,adistributedmanagementplatformbasedonintelligentmobileterminalisdesignedandrealizedbymeansofmobileInternettechnology.Thisplatformcanrealizetheintegrationandpracticalutilizationoftheidlestorageandcomputingresourcesonthesmartmobileterminals.Inordertosolvetheproblemofreliabilityandvalidityoffilestoragecausedbymobileterminal'sowncharacteristics,twosolutionsbasedonLTfountaincodeandchannel-basedadaptiveallocationareproposed,whichenhancethefileonmobileterminal-basedsystemStoragereliabilityandtransmissionefficiency.Inordertoavoidaffectingthenormaloperationofthemobileterminalbytheusers,theterminalbusystatusstrategy,storageresourceautomaticreleasestrategyandcomputingpoolstrategiesareproposed.Throughtheaboveprogramsandstrategies,thesystem’savailabilityhasbeenfurtherimproved.Keywords：mobileinternet,smartmobiledevices,distributedsystem,fountaincode,hadoop,kubernetes-II-万方数据 目录目录摘要..........................................................................................................................IAbstract.......................................................................................................................II第1章绪论...........................................................................................................11.1课题研究的背景...................................................................................................11.2课题研究目的和意义...........................................................................................31.3国内外研究现状...................................................................................................41.3.1分布式相关系统研究现状.......................................................................41.3.2Hadoop分布式系统概述...........................................................................41.3.3Kubernetes编排调度系统概述.................................................................71.3.4当前分布式系统能够解决的问题与不足................................................91.4本文的主要内容和结构安排...............................................................................9第2章基于智能移动终端的分布式管理平台设计.............................................112.1引言.....................................................................................................................112.2平台整体设计方案.............................................................................................112.3平台架构设计.....................................................................................................122.3.1物理层架构设计.....................................................................................122.3.2逻辑层架构设计.....................................................................................132.4平台功能设计.....................................................................................................162.4.1文件功能设计.........................................................................................162.4.2任务功能设计.........................................................................................202.4.3调度系统设计.........................................................................................222.4.4监控功能设计.........................................................................................252.5本章小结.............................................................................................................27第3章基于智能移动终端的分布式管理平台实现.............................................283.1引言.....................................................................................................................283.2平台整体实现方案.............................................................................................283.3平台各个组件开发.............................................................................................293.3.1智能移动终端应用APP开发................................................................293.3.2WebUI网页端、mdfsctl命令开发.........................................................303.3.3服务器Server端开发.............................................................................313.4平台功能测试.....................................................................................................323.4.1文件系统测试.........................................................................................32-III-万方数据 目录3.4.2监控系统测试.........................................................................................343.4.3任务及调度系统测试.............................................................................353.5本章小结.............................................................................................................37第4章基于智能移动终端的分布式管理平台优化.............................................384.1引言.....................................................................................................................384.2平台文件可靠性优化.........................................................................................384.2.1传统冗余备份方案.................................................................................384.2.2喷泉码方案.............................................................................................404.2.3LT码.........................................................................................................404.2.4LT喷泉码在分布式存储中的应用......................................................444.2.5喷泉码方案开销分析.............................................................................474.3平台有效性优化.................................................................................................474.3.1传输数据压缩方案.................................................................................474.3.2节点分级及节点筛选方案.....................................................................484.3.3信道自适应分配方案.............................................................................504.4平台用户体验优化.............................................................................................544.4.1终端忙碌状态策略.................................................................................544.4.2存储资源自动释放策略.........................................................................554.4.3任务池策略.............................................................................................564.5本章小结.............................................................................................................57结论.......................................................................................................................58参考文献...................................................................................................................59攻读硕士学位期间发表的论文及其它成果...........................................................63哈尔滨工业大学学位论文原创性声明和使用权限...............................................64致谢.......................................................................................................................65-IV-万方数据 第1章绪论第1章绪论1.1课题研究的背景移动互联网是当前时期互联网和移动这两个概念共同催化的产品，移动互联网继承了移动这个特点，使得网络的接入变得更加的方便，同时具有网络的特性，使得人们能够随时随地的通过身边的移动互联网设备接入到网络当中来。在移动互联网下运营商充当提供通信基础设施的角色，提供移动互联网数据传输所需要的数据通道，而互联网相关的公司则在运营商提供的基础设施的基础上开发各种移动互联网应用，例如微信、今日头条等。移动互联网应用包含很多的种类，主要有类似于微信的这种社交类，倩女幽魂的这种游戏类，咕咚运动的这种运动类，优酷视频的这种多媒体类，墨迹天气的这种工具类等等。移动通信技术在最近些年获得了长足的进步，给移动互联网贡献了非常有效的技术基础，使得互联网真真切切的融入到我们每一个人的生活当中。由于移动互联网具有移动这一特性，给很多传统的互联企业的业务提供了新的增长点，给这些传统的互联网公司提供了更多转型的机会，使得互联网公司能够将其业务广泛的拓展到其他各个领域中来。便携这个特性使得移动互联网与传统的基于计算机的互联网相比，在相关领域的发展会更加的有优势。用户可以借助移动互联网这个平台随时随地的接入到互联网当中，解决了人们日常生活中的各种各样的难题，使我们的生活变得更加的丰富多彩。因为移动互联网是以能够介入网络的移动设备为基础的，所以，网络以及移动终端的发展对移动互联网的发展起到至关重要的作用。与互联网系统进行比较，移动互联网差异性主要体现在一下几处[1]。（1）移动性。因为移动互联网的基础是智能移动设备，使得我们能够更加方便的接入到网络当中来。（2）实时性。由于目前人们的除了工作以外的时间更多的都是一些碎片化的时间，由于移动互联网具有实时的访问特性，人们可以在碎片化的时间中利用移动互联网来处理相关的事物，而不用担心没有时间去处理重要的事情。移动互联网的实时性极大的推动了移动互联网应用的发展，让人们的碎片化的时间变得不那么的无聊。（3）感知性。移动物联网的主要载体是移动终端，移动终端通过其自身的摄像头、触摸屏、距离感应传感器、陀螺仪等传感器能够感知用户的实际操作，-1-万方数据 哈尔滨工业大学工程硕士学位论文相比于传统的互联网，移动互联网的这种感知性使得移动互联网应用有着更加广阔的应用范围。（4）安全性。由于移动互联网应用的迅速发展，使得各种各样的应用安装在我们身上的移动终端上。许多类似于联系人、社交聊天记录、购物记录等应用当中的数据相对于传统的互联网更加的涉及个人的隐私问题，所以说，移动互联网需要在保护个人隐私的安全性上作出相应的保障。（5）网络和硬件的局限性。由于移动互联网过分的依赖于无线通信网络以及移动终端，无线网络速度的大小以及移动终端性能的好坏直接影响到移动互联网的发展。随着这些年3G、4G等相关无线通信技术的不断发展以及移动终端运算能力的不断加强，移动互联网应用也变得更加的丰富，更加复杂的应用能够在移动互联网的平台上得以实现。未来5G无线通信网络以及移动芯片计算能力的不断发展，势必会进一步的拓展移动互联网应用向着更加丰富，更加广泛的方向发展，不断的方便人们的生活。移动互联网在目前的阶段来说，已经进入了人们日常生活的方方面面当中，旅行票务、影视餐饮、网络购物等人们日常生活方面都充满了移动互联网的身影。以苹果的IOS和Google的Android操作系统为代表的移动终端操作系统运行在各式各样的移动终端上[2]。这些各式各样的移动终端已经充分的在各行各业发挥着巨大的作用，使得人们工作的效率变得非常的高。同时，也推动了很多产业的进一步发展，为社会的发展贡献了巨大的力量。当移动终端的硬件条件成为移动互联网的发展瓶颈的时候，必然会迫使着移动终端的硬件和软件迅速的发展[3]，而实际的情况也是这样。移动终端性能不断提升以及各种传感器在移动终端上的植入，使得越来越多的移动互联网应用能够运行在移动终端上。每一次移动终端上的突破都将会给移动互联网应用的发展提供新的增长点，都将会推动经济在相关领域的发展。随着智能移动终端的不断发展，移动终端的影响力变得越来越大，人们生活的方方面面现在有已经离不开移动终端了。移动终端作为移动互联网应用的实际运行的主体，随着移动互联网应用的长足发展，与之相关的很多技术也得到了相当程度的进步。移动终端基于普通计算机上的操作系统的平台，同时具有非常强大的计算能力以及高速无线网络访问以及快速接入的能力。目前，移动终端已经有很多个发展方向，包括智能手机、平板电脑、智能汽车等领域均有移动终端的接入。随着移动终端上各种技术不断的发展，将会有越来越多的新型移动终端设备诞生。随着移动终端相关领域的技术的不断进步，移动终端将会进入到更广-2-万方数据 第1章绪论阔的领域当中来。同时，移动终端系统借助于当下的人工智能以及云计算[4]技术，在可见的未来在更多的领域产生出巨大的功效，不断的完善各个领域，不断的给产业增添新的活力，不断的促进社会进的发展。1.2课题研究目的和意义移动互联网技术在最近这几年取得了非常快速的发展，移动互联网快速发展的使得移动终端的制造水平得以提升，移动设备的出货量猛增，使得人人可以使用的上移动设备。与之相关联的是基于移动互联网的应用的迅速发展，社会上对基于移动互联网的应用的需求量也变得越来越大。移动物联网技术的快速发展以及移动互联网应用需求的不断提升，使得对智能移动终端性能的要求不断上升，推动着移动终端硬件不断的迭代更新。然而，由于硬件发展的过于迅速，导致移动终端上存在大量闲置未使用的资源，造成了资源的浪费。由于智能移动终端的数量极其的庞大，使得移动终端上闲置资源的体量也非常的大，如果能够把这部分资源整合起来并加以利用，将会给整个移动互联网领域带来一笔非常巨大的财富。然而，由于移动终端相比于传统的计算机还存在着许多的不同。智能移动终端接入网络的方式主要是移动运营商的3G、4G网络或者是Wi-Fi网络，网络的稳定性和可靠性相对于传统的有线网络要差很多，网络传输的时延、带宽等性能也要比传统的有线网络差的很多，而且，终端个体之间网络传输条件差异性很大。同时，由于智能移动终端型号众多，个体差异化很大，导致各个移动终端上可利用的资源情况也大不相同，这就给资源的整理以及利用带来了巨大的挑战。其次，由于智能移动终端的主体是用户，利用终端上的闲置资源必须要在保证不影响用户正常操作移动终端的基础上来执行，这使得在利用移动终端上的闲置的计算和存储资源要比传统的计算机的资源调用起来要更加的困难，在实际操作过程中面临的挑战将会更加的严峻。本文就上述三个方面的内容着手进行研究，首先通过移动互联网技术以及智能移动终端相关技术，构建平台的基本架构，初步实现通过平台来控制智能移动终端，并实现对智能移动终端上存储资源以及计算资源的调用；其次，通过引入喷泉编码方案以及信道自适应方案实现对平台存储可靠性以及有效性的优化；最终，通过终端忙碌状态策略、资源自动释放策略和资源池策略实现平台针对用户体验的优化，降低平台运行对移动终端日常操作带来的影响。-3-万方数据 哈尔滨工业大学工程硕士学位论文1.3国内外研究现状1.3.1分布式相关系统研究现状分布式系统是一套基于软件的系统，该系统以网络为基础，是一种计算机硬件的配置方式和相应的功能配置方式[5]。该系统由许多个普通计算机作为基本工作节点所构成，各个计算机节点通过基础的网络之间相互协调工作构成统一的整体。系统中采用的是分布式的计算框架，将原本由中央处理器运行的任务进行拆分，分配给集群中节点上的各个CPU上面来运行，使得分散在不同设备上的CPU之间能够进行协作，共享整个系统的软件以及相关的外部设备。通过这种分布式的结算方式，提升了整个系统的计算能力，同时大大简化了集中式主机的结构。分布式该系统在运行的时候花费比较低，且系统的运维会比较容器，同时方便进行系统规模的扩展，已经逐渐的成为计算机系统领域非常火热的研究课题。目前现有的分布式文件系统主要有Apache的hadoop[6]、ClusterFileSystem，HP，Intel等公司联合推出的Lustre[7]系统、卡耐基梅隆大学的OpenAFS和FastDFS等[8]。而使用最为广泛的是Hadoop[9]分布式系统。Hadoop在目前的移动互联网大背景下应用非常的广泛，Google，Baidu，Facebook，Yahoo，淘宝等互联网公司都拥有自己的Hadoop集群，用于处理每天产生的海量的日志数据以及其他的业务数据，分布式系统起到了至关重要的作用。而分布式资源调度系统应用最多的是Google的kubernetes分布式资源调度管理系统。该系统以物理机或者虚拟机作为节点，将docker容器作为应用的最小执行单元，通过其自带的编排调度系统，根据各个节点的资源情况进行合理的容器资源编排调度。1.3.2Hadoop分布式系统概述Hadoop是一个适合大数据的分布式存储和计算的平台，是Apache基金旗下一款基于Java来实现的开源的分布式软件框架，该软件能够实现在大量廉价计算机集群的基础上实现对大数据的并行分布式计算。Hadoop分布式平台架构最主要的部分是分布式文件存储系统HDFS（Hadoopdistributedfilesystem）和MapReduce分布式计算框架[10]。Hadoop分布式平台以普通计算机为基础节点。相对于集中式的计算机，Hadoop分布式系统具有可靠性高、扩展性好、效率高和运行成本低等特点，在大数据处理中的应用非常多。-4-万方数据 第1章绪论Hadoop系统的核心架构如图1-1所示。整个系统分为管理节点master和子节点slave。管理面master上有NameNode和JobTracker两个组件，而节点面slave上有DataNode和TaskTracker两个组件。NameNode和DataNode是HDFS中的功能组件，负责管理节点和存储节点上的分布式文件存储相关功能。JobTracker和TaskTracker是MapReduce分布式并行计算框架中的功能组件，负责管理节点和存储节点上的分布式计算相关功能。管理节点NameNode组件JobTracker组件子节点DataNode组件TaskTracker组件DataNode组件TaskTracker组件DataNode组件TaskTracker组件图1-1Hadoop系统基本架构HDFS分布式文件系统是Hadoop开源框架平台上使用的文件系统。HDFS适合部署在普通的计算机上，具有可靠性高、吞吐量大等特点[11]。HDFS是主从结构，HDFS是主从结构的体系框架，一个HDFS集群通常由一个NameNode节点与多个DataNode节点组成[12]。NameNode组件作为系统当中的管理面节点组件，负责管理集群中的文件先关操作以及控制用户对集群系统中节点的实际访问。DataNode节点在Hadoop系统当中充当的角色是实际存储节点[13]，集群中的普通计算机都是DataNode节点，用于管理本节点上的文件存储。整个Hadoop系统各个节点之间的通信都是在TCP/IP协议的基础上来构建的，客户端和NameNode节点之间的通信协议[14]是ClientProtocol，而DataNode和NameNode之间的通信协议是DatanodeProtocol。Hadoop平台上的HDFS文件系统中文件读写操作流程如图1-2所示。HDFS基本的存储策略是将一个大的文件分成多个文件块，生成的多个文件块存储在系统的数据节点上。NameNode管理系统文件的命名以及目录相关的操作。同时，NameNode管理节点在本地上存储保存了原文件在系统存储节点上实际存储的位置相关记录，也就是文件的元数据（Metadata）。DataNode节点用来响应和处理来自用户端的文件度和写的操作。同时，DataNode节点也要执行文件块的新建、移除、复制等一系列的操作指令。-5-万方数据 哈尔滨工业大学工程硕士学位论文元数据(文件名,副本数,...):NameNode/home/foo/data,3,...元数据操作客户端文件块操作读取DataNodesDataNodes副本文件块机架1机架2客户端图1-2HDFS文件读写操作原理图运行在Hadoop分布式平台上的MapReduce实际上是一种分布式并行计算框架，适合大规模的并行计算。整个框架围绕着Map和Reduce这两个概念展开，这两个概念来源于矢量编程以及函数式编程。通过MapReduce这个框架，能够很方便的让开发者将已经写好的程序转移到分布式系统上来运行，HDFS文件系统上的MapReduce任务的基本过程如图1-3所示。HDFS输入排序第1块mapHDFS输出合并排序HDFS第2块mapreduce第0块副本排序第N块map图1-3HDFS系统上MapReduce工作原理图-6-万方数据 第1章绪论首先从HDFS文件系统中获取多组输入数据块（split），每个数块对应一个map任务；其次，在每个map任务执行完成之后，对每个任务的结果进行相关的处理并进行复制，进入reduce函数处理阶段；然后，将复制的各个map任务的输出结果进行合并（merge）作为reduce函数处理阶段的输入；最后，执行reduce函数得出最终的计算结果，并将最终的计算结果保存到HDFS中，完成整个MapReduce计算任务。1.3.3Kubernetes编排调度系统概述Kubernetes是由Google在2014年启动的一个项目，Google公司通过15年的技术经验的积累，同时吸收网上社区内的一些优秀的方案跟设计一同构建了Kubernetes。Kubernetes是一个以Docker容器为基础的容器分布式容器管理调度架构，通过Kubernetes可以实现在虚拟机集群或者是物理机集群上调度和运行Docker容器，同时提供了Docker容器的部署、拓展和管理等功能的开源的容器管理平台。Kubernetes的架构整体上可以分为管理面节点（Master）、子节点（Node）这两个部分。管理面主要负责Node节点的监控以及整个系统的管理；Node节点主要向系统提供资源，并执行管理面下发的相关任务；对外访问接口主要是为了向用户提供管理该系统平台的命令和Web显示页面，基本的架构由1-4给出。图1-4Kubernetes系统软件核心架构-7-万方数据 哈尔滨工业大学工程硕士学位论文管理面节点上有多个功能组件，APIServer是系统的管理入口，内置了对系统当中内容的操控；Scheduler组件负责容器调度；ControlManager组件是系统当中的管理控制器；ETCD用于系统信息持久化存储的一种分布式数据库。Node节点上同样含有多个功能组件，kubelet是运行在Node节点上与管理面之间通信的组件，是沟通管理面Master节点和Node节点之间的非常重要的桥梁。kube-proxy是用于实现外部用户能够跨机器访问容器中的应用所设计的组件，该组件运行在Kubernetes集群中每个Node节点上。Pod作为Kubernetes分布式容器调度系统最基本的调度单元，一个Pod当中可以封装一个或多个容器，一般来说包含某一个应用所需所有部件。Pod在从创建到运行的整个生命周期中，主要分为Creating、Waiting、Pending和Running这四个阶段，每个阶段有明显的区分时刻，Pod创建的过程如图1-5所示。UserkubectlAPIServeretcdSchedulerkubeletDocker创建Pod提交podsPod写入周期性获取节点和Pod信息给Pod选定节点创建绑定信息写入绑定信息周期性获取本地绑定Pod信息创建&启动PodUserKubectlAPIServeretcdSchedulerkubeletDockerCreatingWaitingPendingRunning图1-5Pod创建过程中生命周期图在图1-5中，当用户（User）通过Kubernetes的命令工具kubectl向APIServer发起一个新建Pod的请求过后，APIServer会接收到来自User的用户请求，User的请求信息包含需要创建的Pod的相关配置信息。APIServer接收到User发来的请求过后，会进行相关的认证、资源配置和授权等相关的验证操作。在通过-8-万方数据 第1章绪论一系列的验证过后，APIServer会创建一个Pod对象并且将信息参数存储到ETCD当中，此时的Pod的状态为Creating。调度系统中会给所有状态为Creating的Pod设置一个等待缓冲区，Pod需要先进入缓冲区，才能够被Scheduler进行调度，Pod进入等待缓冲区过后，状态将由Creating变成Waiting。Scheduler通过向APIServer的API接口定期的进行访问，从中获取可以使用的节点信息列表以及等待调度的Pod信息，通过一定的调度策略，将需要调度的Pod调度到相关的工作节点上，并将相关的绑定信息写入ETCD当中，Pod调度的整个过程可以称之为绑定。Pod被成功的绑定工作节点上后，Pod的状态由Waiting变成Pending。Kubelet运行在每个工作的子节点上，Kubelet会定期的向APIServer发起请求，获取该工作节点上所有的Pod的信息，如果发现有新的Pod运行信息，在该节点上创建并且运行相关的Pod，Pod的状态由Pending变成Running，完成整个Pod创建的生命周期。上述Pod的创建过程就是整个Kubernetes分布式资源调度系统基本的调度流程，后序设计的平台将参照这一调度流程，来实现针对移动终端的分布式资源调度系统。1.3.4当前分布式系统能够解决的问题与不足传统的分布式的节点以计算机为单位[15]，通过将一定数量的计算机通过网络连接的方式构建一个计算机集群，将海量文件的计算和存储任务分散给集群中的计算机来执行，对移动互联网时代下海量数据进行存储和计算[16]。然而，在当下移动互联网占据统治地位时期，用户的主体是移动终端，移动终端的数量远远大于传统分布式系统集群中计算机的数量，移动终端上存在着海量的可利用资源。传统的分布式系统依赖于以计算机为节点的集群，但是在面对智能移动终端的时候，无法适用[17]。如何利用移动互联网时代移动终端庞大的资源是传统分布式系统没能实现的，所以，一种能够利用移动终端资源的移动分布式管理平台成为了当下移动互联网时代新的需求[18]。1.4本文的主要内容和结构安排本文以智能移动终端为基础，设计了一套基于移动互联网的分布式平台[19]。系统架构借鉴了Hadoop分布式系统和Kubernetes分布式资源管理调度系统。该平台能够实现对智能移动终端上的闲置的存储和计算资源加以整合利用，实现了通过智能移动终端来执行相关的分布式存储和计算任务。同时，针对分布式存储由计算机向移动终端拓展遇到的可靠性[20]和有效性问题两大难题，分别提出了基于LT喷泉码和基于信道自适应分配的两种解决方案。LT喷泉码方-9-万方数据 哈尔滨工业大学工程硕士学位论文案相对于传统分布式系统的文件冗余备份方案，平台文件的可靠性得到了很大程度的提升；而信道自适应分配方案相对于传统分布式系统的平均分配方案，使得平台文件传输的有效性得到了很大的提升[21]。通过提出的两套方案能够很好的解决面向移动终端的分布式存储遇到的可靠性和有效性这两大难题。文章基本结构由图1-6给出。服务器Server有效性WebUI可靠性终端应用用户体验相关领域系统设计系统开发功能测试系统优化调研逻辑/物理架构文件系统系统组件监控系统系统功能任务系统图1-6本文整体结结构图本文的主要研究内容如下：（1）在参考借鉴Hadoop和Kubernetes系统框架基础上，设计了一套面向智能移动终端的分布式管理平台的整体框架。（2）借助移动互联网技术，完成系统平台的搭建并实现设计的功能目标。（3）对实现的平台进行优化和改进，来提升系统的有效性和可靠性。（4）针对用户体验进行优化，以降低平台运行对用户正常操作移动终端时的影响。-10-万方数据 第2章基于智能移动终端的分布式管理平台设计第2章基于智能移动终端的分布式管理平台设计2.1引言上一章节介绍Hadoop分布式系统上的HDFS分布式文件存储系统和MapReduce分布式计算框架，同时也介绍了分布式容器资源调度系统Kubernetes。本章将在上一章节介绍的内容的基础上，给出基于智能移动终端的分布式管理平台的平台设计方案，包括了系统的物理层和逻辑层架构设计以及平台功能的设计。2.2平台整体设计方案要搭建和实现一套系统平台，整个过程可以简单的分为三个步骤：系统设计、系统实现和系统优化。系统设计包括系统的物理层架构设计、逻辑层架构设计以及系统功能的设计。系统的实现包括技术路线的选用以及系统具体的搭建实现。在实现系统基本功能的基础上，系统的优化通过调整系统的实现方式，调整技术参数，优化系统的技术指标。所设计的系统平台的基本设计目标是：通过该系统平台实现对智能移动终端上闲置的存储和计算资源的调用。所设计的系统平台的基本设计原则主要有一下几个。（1）需针对移动终端不同的网络、资源等状态进行差异化处理。（2）不涉及到移动终端上用户的任何个人敏感信息操作。（3）平台在移动终端设备上运行时，让用户无感知。（4）不干扰使用者对移动终端设备的日常使用。整体设计实现的基本过程如下。步骤一：明确系统平台的设计目标以及确定系统的功能性和技术指标。步骤二：根据系统的设定目标和系统的基本功能来设计系统，包括物理、逻辑和功能设计。步骤三：选定技术路线方案，搭建并实现平台的基本架构。步骤四：当前所选的技术路线和实现方法无法实现既定的系统功能，重复步骤三及时的调整技术路线和实现方法，重新搭建系统。步骤五：基本功能可以实现的条件下，如果系统的技术指标未能达到设定的要求，那么重复步骤三调整系统的实现方式。-11-万方数据 哈尔滨工业大学工程硕士学位论文步骤六：系统平台各项参数达到设计指标，最终完成平台的设计与实现。基本过程由图2-1给出。开始明确系统目标确定系统的功能，量化指标调整技术路线、实现确定技术路线方法系统编程实现否是否实现系统基本功能优化实现方式是否系统指标是否达标是完成系统设计结束图2-1系统平台整体设计流程图2.3平台架构设计2.3.1物理层架构设计物理层是整个平台最底层的硬件设备，是支撑整个系统的基础，整个管理系统运行在相关的硬件基础平台上。整个分布式管理平台整体上可以分为三个部分，分别是前端系统和后端系统以及中间用于连接的网络系统[22]。前端系统主要包含众多的移动终端[23]节点（Node）。移动终端通过3G/4G的移动通信基站或者802.11AP的Wi-Fi热点接-12-万方数据 第2章基于智能移动终端的分布式管理平台设计入英特网。后端系统主要包括后台服务器（Server）、数据库（DB）以及用户客户端（Client）设备，物理层的基本架构由图2-2给出。Client图2-2平台的物理层架构图文献[24]详细介绍了移动文件系统当中信息通信的问题，本系统的通信主要依赖于英特网以及TCP/IP通信协议。服务器是整个分布式管理平台的核心，主要承担以下几个任务：第一，用来进行整个移动分布式管理平台与移动终端和用户客户端之间所有的数据通信；第二，用于实现对系统平台的资源进行相应的整合及调用；第三，用于监测和管理整个系统的状态。数据库用来存储系统中文件的元数据和其它系统相关的信息。关于用户如何接入系统，文献[24]给出了比较详细的介绍。用户的客户端设备是用户管理和运行整个系统的入口，可以是计算机或者是移动设备。用户通过客户端设备以web网页的形式接入分布式管理平台的管理控制台，可以管理和操作整个分布式管理平台。2.3.2逻辑层架构设计在参考传统的Hadoop分布式平台的基本逻辑结构下，沿用文献[6]中介绍的Hadoop系统的基本逻辑服务结构，参考文献[23]中提到的移动环境下应用的服务，并加入了针对移动终端的状态监测服务组件。系统平台的基本逻辑架构分为管理面和节点面，管理面节点Master是系统整体的控制中心，节点面子节点Node是系统中实际的资源提供主体。整个逻辑层面主要由6个基本组件所组成，分别是服务器上的FileManager、Job-13-万方数据 哈尔滨工业大学工程硕士学位论文Manager和ResourceManager以及移动终端节点上的FileController、TaskController和ResourceController，所设计的基于移动互联网的分布式管理平台的基本逻辑架构如图2-3所示。Master管理节点FileManagerJobManagerResourceManager组件组件组件Node子节点FileControlerJobControlerResourceControler...FileControlerJobControlerResourceControler组件组件组件组件组件组件图2-3系统的逻辑层架构图FileManager负责整个平台的文件管理，FileController负责本移动终端节点上的文件管理，所有移动终端节点上的FileController均由服务器上的FileManager统一进行管理。服务器上的JobManager用来分配、管理和执行平台中需要运行的任务，同时追踪和监测各个节点上的TaskController，对节点反馈的运算结果进行最终的合并任务。节点上的TaskController用来监测移动终端从接收服务器上接收到的计算任务，追踪在移动终端节点上任务的运行情况，并将任务的结果反馈给JobManager。ResourceController用来监测移动终端节点的各种状态并发送给ResourceManager，ResourceManager用来对平台中所有节点的状态进行管理和监测，最终实现在移动分布式管理平台上的分布式文件存储和分布式计算任务，各个组件的基本信息由表2-1给出。表2-1系统平台各组件功能表组件名称所在节点实现功能FileManagerMaster负责系统文件管理，包括文件下发、删除、回传。JobManagerMaster负责系统任务管理，包括任务的分发和回收。ResourceMaster负责监控所有Node节点的资源信息以及状态信息。FileControllerManagerNode负责节点上文件操作，包括下载、上传、删除等。Resource负责监控节点上的资源情况以及网络状况和任务执NodeController行情况，并将节点监控数据反馈给管理面节点。TaskControllerNode负责管理该节点上的任务操作，包括执行和反馈。-14-万方数据 第2章基于智能移动终端的分布式管理平台设计在表2-1中所列出的6个基本组件的基础上，图2-4描述了整个基于智能移动终端的分布式管理平台的核心运行架构图。在基本的6个功能组件的基础上添加了Scheduler（调度器）、APIServer（服务器）、ControlManager（控制中心）、mdfslet（执行单元）、MySQLSQLite（数据库）组件，下面介绍这些组件的基本功能。（1）APIServer：管理面的数据交换中心，Node节点以及用户操作平台的控制信息均发送到APIServer，然后再由各个组件来执行先关的操作。（2）ControlManager：整个平台的控制组件，处理包括文件、任务、节点管理等。（3）Scheduler：当用户提交相关的任务到平台的时候，JobManager会将计算任务进行拆分，Scheduler从ResourceManager那里获取可用的节点信息，然后将拆分后的任务按照一定的计算调度规则分配给指定的Node节点。（4）mdfslet：定期从APIServer处获取该节点上的任务信息，发现有新的任务的话，立即执行相关的任务。（5）MySQLSQLite：MySQL位于管理面，用于保存整个平台的信息，包括节点的状态信息、文件信息、任务信息等。SQLite位于Node节点，保存本节点的资源情况和状态信息，同时保存节点上执行的任务以及文件相关的信息。mdfsctlWebUI心跳机制Master管理节点Node子节点list机制APIServermdfsletResourceControllerResourceSchedulerManagerJobManagerFileManagerTaskFileControllerControllerControlManagerMySQLSQLite图2-4设计的系统平台核心架构图Node节点和管理面之间的通信机制主要有两个，分别是心跳机制以及list机制。心跳机制主要用于节点状态监测，ResourceManager定时向管理面APIServer发送心跳信息，心跳信息中包括ResourceManager收集到的节点上的资源情况以及文件和任务的执行情况。List机制主要用于任务的接收，mdfslet-15-万方数据 哈尔滨工业大学工程硕士学位论文定时从APIServer获取节点上的信息列表List，List中出现新的任务项的话，mdfslet及时将任务项交由TaskController和FileController来执行。2.4平台功能设计基于智能移动终端的分布式管理平台的主要功能模块主要可以分为以下几个部分，分别是文件管理系统、任务管理系统、节点状态监控系统和任务编排调度系统，与Hadoop中介绍的传统的分布式文件系统保持一致。文件管理系统的功能是负责整个平台的文件操作，主要包含文件上传、文件查看、文件删除和下载功能[25]。任务管理系统负责整个平台的任务管理，主要包含任务的接收、拆分、下发、监控、结果处理等。节点状态监测系统的功能是用来监测移动终端节点的各种状态，主要包括硬件信息、网络信息、存储信息以及节点上文件块以和任务执行的相关信息。调度系统主要的功能是监控各个工作子节点的资源及网络通信状态，同时将ControlManager拆分好的子任务在子节点的监控信息的基础上调度到各个子节点上面去。2.4.1文件功能设计分布式文件存储系统的基本思想是：将文件分割成指定大小的文件块，分散的存储在不同的存储节点上[22]。图2-5为传统的以计算机为存储节点的分布式文件存储系统原理图，主要分为控制节点和存储节点，存储节点为普通的PC，所有的节点和管理节点一般来说处于同一个局域网中。在传统的分布式存储系统中，控制节点负责将一个大文件按照指定的大小分割成指定个数的文件块，将分割过后的文件块分散的存储在集群上的不同存储节点上，同时在控制节点上存储文件分布的Metadata。当设计一个以智能移动终端为存储节点分布式文件系统[26]的时候，存储节点和以及各组件之间的通信方式和传统的以PC为存储节点的分布式系统会有所区别。图2-6是以移动终端为存储节点的分布式文件存储的原理图，移动终端通过通信基站、Wi-Fi热点等其他方式接入互联网，与后端控制节点建立连接。由于移动终端处在不同条件的网络中，使得各节点信道传输条件存在很大差异，而且，移动网络的稳定性比局域网要差很[27]多。所以，在设计基于移动终端的分布式文件存储系统的时候，需要针对智能移动终端和PC之间的差异做相关的差异化处理，使得所设计的平台更加适合于智能移动终端。-16-万方数据 第2章基于智能移动终端的分布式管理平台设计文件块文件块存储节点1存储节点n文件块存储节点6文件文件块文件块存储节点2控制节点存储节点5文件块文件块存储节点3存储节点4图2-5传统分布式文件存储系统原理图文件块文件块存储节点n存储节点1文件块其它存储节点5文件通信基站文件块控制节点文件块存储节点2WiFi热点存储节点4文件块存储节点3图2-6移动分布式文件存储系统原理图从前面章节介绍的平台架构可知，所设计的基于智能移动终端的分布式管理平台的文件存储方面主要由管理面的FileManager和节点上的FileController两个功能组件来完成。基于这两个组件，完成设计的文件操作流程的基本架构流程。在FileManager和FileController这两个组件的基础上，整个系统的文件操作还涉及到APIServer、FileManager、FileController、Scheduler、MySQL组-17-万方数据 哈尔滨工业大学工程硕士学位论文件，各个组件在文件操作中承担的主要任务如下。（1）APIServer：用来接收用户的文件操作请求，同时也是文件流进出系统的出入口，负责整个系统中数据的交互。（2）FileManager：负责将用户上传的文件信息按照一定的规则进行分块，并借助Scheduler将文件块调度到不同的存储节点上。（3）Scheduler：负责处理FileManager发送过来的文件调度请求，在处理分析各个存储节点资源和状态参数的基础上，按照一定的调度规则，将文件调度到正常工作的存储节点上。（4）FileController：节点上的FileController负责处理从APIServer那里获取的文件操作相关信息，如果发现有新的文件操作，立即执行相关的文件操作。（5）MySQL：用于存储文件在各个存储节点上分布的元数据。各个组件的协同操作使得整个文件管理系统能够正常的工作，实现文件的读、写等相关的操作。图2-7中描绘了文件管理系统的工作流图，接下来详细的介绍文件的读写操作过程。读取APIServerFileManager元数据MySQL客户端组件组件数据库节点节点节点节点节点节点终端群2终端群1SchedulerFileManagerAPIServer客户端组件组件组件写入MySQL数据库图2-7文件管理系统文件读写过程图-18-万方数据 第2章基于智能移动终端的分布式管理平台设计（1）文件写操作过程。首先，用户Client想APIServer发起文件写的操作并将文件上传到APIServer中；然后，FileManager组件从APIServer那获取用户上传的文件信息，将文件进行分块等相关的预处理操作，并将文件块的分配调度任务发送给Scheduler进行调度；其次，Scheduler接收从FileManager那发送过来的调度任务，依据相关的调度规则将文件块调度到可用的系统当中的存储节点上；最后，存储节点上的FileController在接收到文件存储的操作的时候，接收相应的文件块，并保存在本地，完成整个文件的写入操作。（2）文件读操作过程。当客户端Client需要进行文件读取操作的时候，首先，向AIPServer服务器发送文件读的请求，并在请求中添加上文件的识别标识信息；然后，AIPServer将文件度的操作的信息转发给FileManager组件；FileManager从MySQL数据库当中根据文件的识别标识信息将文件的分布存储信息metadata查找出来；最后，FileManager根据metadata信息通过APIServer从各个存储节点将文件块取回来，进行相关的合并处理过后，通过APIServer回传给用户。在参考Hadoop系统的元数据结构的基础上，提出了针对移动终端的元数据结构，文件的元数据如图2-8所示。元数据File0part-11Node1100kB1File0part-11Node3100kB1File0part-22Node2100kB1File0part-33Node6100kB1File0part-44Node8100kB1移动终端12134图2-8所设计文件管理系统的元数据图文件的分块信息保存在MySQL数据库当中，一个文件块有一条记录，每条记录含有文件号、文件块序号、文件块标识符、所在移动终端编号、文件块-19-万方数据 哈尔滨工业大学工程硕士学位论文所占用存储空间等文件的先关信息。文件号用于唯一确定一个文件。文件块序号标明了文件块在原文件中的位置，文件块标识符用来唯一识别这个文件块，移动终端编号表明该分块文件所存储的是哪一个移动终端，唯一标识移动终端。文件块所占用存储空间表明了文件保存在移动终端当中文件块的大小。文件块状态表明了该文件块是否正常的发送到了移动终端上。在图2-8中，移动终端作为整个移动分布式管理平台的存储单元，以指定大小的分块文件的形式存储文件。移动节点在保存分块文件的同时，会在本地数据库中生成该节点上所有文件块的列表清单，记录该节点上所有分块文件的信息。2.4.2任务功能设计任务系统负责整个平台的任务管理，主要包含任务接收、任务的拆分、任务下发、任务监控、任务执行、和任务结果处理。从之前章节的平台核心的架构可以知道，任务系统主要由管理面的JobManager和节点上的TaskController两个组件来试实现，与文献[28]中介绍的Hadoop的map/reduce编程框架类似，任务系统架构由图2-9给出。Master管理节点Scheduler组件JobManager组件MySQL数据库Reduce任务APIServer组件Node子节点mdfslet组件mdfslet组件mdfslet组件TaskControllerTaskControllerTaskController......组件组件组件Map任务1...Map任务NMap任务1...Map任务NMap任务1...Map任务N图2-9所设计任务系统结构图除了上述介绍的管理面和节点面的两个组件以外，还需要使用到管理面的APIServer、MySQL、Scheduler和节点上的mdfslet组件，各个组件在任务系统-20-万方数据 第2章基于智能移动终端的分布式管理平台设计中的功能如下。（1）APIServer：接收用户发送的计算任务请求，并把计算任务请求转发给JobManager来进行处理。（2）JobManager：对从APIServer那里接收到的计算任务进行分解，分解成多个Map任务和Reduce任务，将相关信息保存在管理面MySQL数据库当中，并将分解后的任务信息提交给Scheduler调度器来进行调度。（3）TaskController：负责运行管理面下发的计算任务，并将计算结果通过mdfslet组件反馈给管理面。（4）MySQL：负责存储任务相关的信息，包括任务的完成情况、子任务个数、耗时等相关信息。（5）mdfslet：负责节点与管理面之间的数据通信服务，通过APIServer接收到节点上需要运行的计算任务信息，然后，将计算任务发送给节点上的JobController来负责运行，最终还需要将JobController提交的任务运行结果反馈给管理面。上述几个功能组件之间相互协调工作，共同实现了整个平台的计算工作。图2-10介绍了从创建一个计算任务到计算任务最终实际运行的整个流程。节点节点节点节点节点节点终端群2终端群1SchedulerJobManagerAPIServer创建任务客户端组件组件组件MySQL数据库图2-10创建任务过程图整个任务从下发的执行步骤如下。步骤一：用户向管理面的APIServer接口发送创建任务的指令，并把相关-21-万方数据 哈尔滨工业大学工程硕士学位论文的信息同时也发送给APIServer。步骤二：APIServer接收到用户发送来的计算任务，将计算任务转发给JobManager。步骤三：JobManager接收到计算任务过后，将计算任务进行拆分，并将拆分后的调度任务交给Scheduler进行调度。步骤四：Scheduler监控节点的资源使用情况，将JobManager提交的调度任务进行调度，并将相关的任务调度信息写入管理面MySQL数据库。步骤五：节点上的msfdlet组件从APIServer处获取到新的计算任务，并将计算任务转交给节点上的TaskController来执行。步骤六：TaskController接收计算任务并开始实际在节点上运行计算任务，并将计算结果通过msfdlet反馈给管理面。步骤七：管理面JobManager接收到节点反馈的结算结果后，对所有反馈的计算结果进行进一步的处理，得出最终的任务计算结果。2.4.3调度系统设计整个调度系统的核心组件是Scheduler调度器，Scheduler调度器在系统主要承担着文件和计算任务的调度工作。Scheduler对文件和计算任务的调度在工作原理上是相同的，都是将执行的工作单元调度到能够工作的工作节点上去，工作单元可以是文件存储单元，也可以是计算单元。Scheduler在进行调度的时候，需要根据各个工作节点的状态来进行判定，然后根据相关的调度规则对工作单元进行调度。表2-2定义了工作单元的几个工作状态类型。当节点处于Ready状态的时候，才可以被调度器Scheduler认为是可以使用的节点，其它的状态认为是不可使用的。表2-2Node工作节点状态类型状态类型名称类型介绍工作节点处于在线，资源充足，可以执行相关计算或者存储任Ready务。工作节点处于离线状态，不能接收管理面下发的任务指令信NotReady息。工作节点处于在线状态，但是节点的可用资源不足，无法完成Insufficient管理面发送的任务信息。-22-万方数据 第2章基于智能移动终端的分布式管理平台设计调度器调度的最小执行单元设定为一个Task，Scheduler的调度过程参考Kubernetes的调度过程来实现，所有的组件以及组件之间的工作方式有些不同。整个Task生命周期主要可以分为Creating、Scheduling、Waiting、Finishing这四个阶段，各个部分含义如表2-3所示。表2-3Task的生命周期各个阶段阶段名称发生时刻Creating用户提交任务，管理面相将任务分成Task为单位的最小单元。Scheduling最小操作单元进入调度队列，状态由Creating编程Scheduling。WaitingTask被分配后，进入待处理阶段。节点执行完管理面下发的计算任务的时候，Task工作单元的状态变Finishing成最终的Finishing。基于智能移动终端设备的调度系统由图2-11给出。TaskClientMdfsctlAPIServerMySQLSchedulermdfsletController创建Job任务Job/FileManager提交`Job`写入Tasks周期获取节点和Tasks任务信息为Task选定创建Task节点绑定信息写入绑定信息周期性获取本地绑定Task信息创建&执行Task任务TaskClientmdfsctlAPIServerMySQLSchedulermdfsletControllerCreatingSchedulingWaitingFinishing图2-11Task创建过程中生命周期图-23-万方数据 哈尔滨工业大学工程硕士学位论文整个调度系统在参考kubernetes系统中各个组件的功能的基础上，结合kubernetes的Pod在创建过程中的生命周期，设计了基于智能移动终端设备的调度过程。下面将通过新建一个任务为例子，来描述在任务创建过程当中各个组件之间是如何来进行协调的，深入介绍所设计的面向移动终端的调度系统。在图2-11中，当用户Client通过系统当中的命令工具mdfsctl向APIServer发起一个新建任务作业的请求过后，APIServer会接收到来自Client的用户请求，Client的请求信息包含需要创建的任务的相关配置信息。APIServer接收到Client发来的请求过后，会进行相关的认证、资源配置和授权等相关的验证操作。在通过一系列的验证过后，APIServer会根据任务类型分别转发到FileManager或者是JobManager来进行进一步的处理。FileManager和JobManager对任务进行处理过后，将任务信息提交给Scheduler进行调度，创建Task对象并且将信息参数存储到MySQL数据库当中，此时的Task的状态为Creating。调度系统中会给所有状态为Creating的Task设置一个等待缓冲区，Task需要先进入缓冲区，才能够被Scheduler进行调度，Task进入等待缓冲区过后，状态将由Creating变成Scheduling。Scheduler通过向APIServer的API接口定期的进行访问，从中获取可以使用的节点信息列表以及等待调度的Task信息，通过一定的调度策略，将需要调度的Task调度到相关的工作节点上，并将相关的绑定信息写入MySQL数据库当中，Task调度的整个过程可以称之为绑定。Task被成功的绑定工作节点上后，Task的状态由Scheduling变成Waiting，等待节点来执行。mdfslet运行在每个工作的子节点上，mdfslet会定期的向APIServer发起请求，获取该工作节点上所有的Task的信息，如果发现有新的Task运行信息，在该节点上创建并且运行相关的Task，Task的状态由Waiting变成Finishing，完成整个Task创建的生命周期。上述Task的创建过程就是所设计平台当中分布式资源调度系统基本的调度流程。基本调度算法采用平均分配算法，该算法的基本原理是：在节点处于Ready工作状态且资源处于可用的情况下，将Task任务平均分配给各个节点，每个节点分配的Task任务数量如式（2-1）所示。allTaskNumnodeTaskNum（2-1）readyNodeNum式中nodeTaskNum——分配到每个节点的任务单元个数；allTaskNum——总的任务单元个数；readyNodeNum——当前可用节点个数。-24-万方数据 第2章基于智能移动终端的分布式管理平台设计2.4.4监控功能设计监控系统主要用来监控集群中各个工作几点的资源使用情况以及自身的网络状况，供信息给系统进行分析。状态监测系统主要由管理面的ResourceManager、APIServer、MySQL和工作节点上的ResourceController两个功能组件来实现，监控系统的基本结构如图2-12所示，两个组件的基本功能如下。（1）ResourceController：在子节点上收集当前节点的硬件信息、资源使用信息、网络信息、存储文件块信息等，并将收集到的信息通过心跳Heartbeart信息反馈给管理面节点的APIServer。（2）APIServer：将节点通过心跳信息传送上来的监控信息转发给管理面的ResourceManager组件，交由该组件来进行处理。（4）ResourceManager：处理节点上收集到的监控信息，对节点的状态进行分析归类等操作，作为Scheduler调度器的参考信息。（5）MySQL：负责保存节点的状态以及监控信息。通过图2-12给出的监控系统的工作结构，整个监控系统工作流程如下。步骤一：ResourceController组件收集节点信息，并发送到管理面。步骤二：APIServer接收到节点心跳信息后，转发给ResourceManager。步骤三：ResourceManager处理节点上传的监控数据，并进行相应处理。步骤四：ResourceManage定时清除未发送信息的终端设备。Master管理节点ResourceManagerMySQLAPIServer组件组件数据库心跳信息心跳信息Node子节点ResourceResourceResourceController组件Controller组件Controller组件硬件信息网络信息硬件信息网络信息硬件信息网络信息文件块文件块文件块信息信息信息图2-12Task监控系统结构图-25-万方数据 哈尔滨工业大学工程硕士学位论文ResourceController采集到的节点硬件信息由表2-4所列出，包括终端的唯一IMEL识别码、终端型号、终端操作系统、系统版本、存储空间、处理器和内存等终端硬件信息。针对这些硬件系统参数，通过相关算法得出移动终端的计算和存储性能分数，该性能分数用来衡量移动终端的计算和存储能力。ResourceController采集到的终端节点的网络信息表2-5所列出，包括终端接入网络的模式2G、34、4G、Wi-Fi、系统当前的网络接入速度以及延时这几个参数，利用相关算法在参考网络参数的情况下计算得出系统的网络性能分数。ResourceController采集到的终端节点上的文件块信息由表2-6所列出，包括文件块的唯一识别码ID[29]、所处位置等信息。这些信息记录了本地文件信息，该信息存储在移动终端的本地数据库当中。所设计的平台在需要调用在线的移动终端的存储资源和计算资源的时候，优先选用网络性能分数和计算及存储性能分数高的工作节点，如果工作节点的网络性能或者存储计算性能比较差的很容易造成终端节点无法正常的完成分布式存储或者计算任务，无法正常完成相关任务，造成平台的可用性降低。表2-4ResourceController采集的节点硬件信息参数含义单位OS终端操作系统/NodeID移动终端唯一IMEL码/SystemId所在系统唯一识别码/PhoneType终端型号/OSVersion操作系统版本/LocalStorage终端本地存储空间ByteRestLocalStorage终端本地剩余存储空间ByteProvideStorage终端提供给系统的存储ByteRestProvideStorage终端提供给系统给的剩空间ByteRam终端的可用内存大小余存储空间MBTotalRam终端总的内存大小MBCpuUsageCPU使用率%CpuFrequency终端的CPU主频大小kHzCoreNumber终端的CPU核心数个-26-万方数据 第2章基于智能移动终端的分布式管理平台设计表2-5ResourceController采集的节点网络信息参数含义单位NetType终端的联网方式2G/3G/4G/Wi-FiNetDelay网络延时msNetSpeed终端传输带宽Byte/s表2-6ResourceController采集的本地文件块信息参数含义单位BlockID文件块的唯一识别码/FileID文件块所属文件的唯一识别码/NodeId文件块所在节点的IMEL吗/BlockName文件块名称/FileSerialNumber文件块在源文件中位置序号/BlockPath文件块保存的地址/BlockSize文件块的大小ByteBlockSetTime文件块生成时间/2.5本章小结本章节在上一章介绍Hadoop系统以及Kubernetes系统的基础上，给出了基于智能移动终端的分布式管理平台的整体设计方案。在整体设计方案的基础上，设计了该系统平台的基本逻辑架构。同时，基于所设计的基本逻辑架构，设计了平台的功能，包括文件功能、任务功能、调度系统和监控功能。本章节的主要介绍的是整个平台的架构以及功能方面的设计，后序系统平台的具体实现将主要参考本章节的设计来实现。-27-万方数据 哈尔滨工业大学工程硕士学位论文第3章基于智能移动终端的分布式管理平台实现3.1引言上一章节介绍了基于智能移动终端的分布式管理平台的设计，包括整体设计方案、物理层逻辑层架构设计以及平台基本功能的设计。本章节将会在前一章节的平台设计基础上具体开发实现该平台，包括服务器Server端、Android客户端以及Web用户控制端的开发，以及通过各个组件之间的协作来具体实现系统平台各个功能。3.2平台整体实现方案在平台设计的基础上，要利用移动互联技术来实现这样一个基于移动互联网的分布式管理平台，需要做的主要工作可以围绕三个部分展开，分别是移动终端（App）应用开发、用户控制台（Web）开发和网络服务器（Server）的开发，结构如图3-1所示。移动终端应用App是移动终端接入平台和运行分布式任务的工具，通过该工具实现移动终端上应该具有的所有功能。用户控制台是以WebUI网页以及mdfsctl命令工具的形式提供用户管理接入平台的入口。通过该控制台，用户可以查看系统平台状态以及执行相关的文件操作以及分布式计算任务。Server在系统平台当中充当服务器角色，管理面的基本功能组件都运行在Server上，负责处理所有和移动终端以及用户端之间的数据通信以及所有的文件及任务的管理。ServerWebApp图3-1系统平台实现基本结构图-28-万方数据 第3章基于智能移动终端的分布式管理平台实现3.3平台各个组件开发所设计的平台实际运行的组件由三个核心部分组成，分别是移动终端上运行的Application、后端运行的Server以及用户实际操控平台的WebUI前端页面，接下来详细介绍各个组件的开发。3.3.1智能移动终端应用APP开发考虑到移动终端应用的特性，最终选用基于Android的智能手机来进行开发。由于Android系统的开放程度较高且可定制，所以选用基于Android操作系统智能终端来进行开发将会是最好的选择。终端应用开发的基本软件硬件参数由表3-1所列出。移动终端上有三个逻辑功能服务模块，分别是FileController、TaskController、ResourceController和mdfslet，且各自提供不同的功能。在Android应用当中通过使用系统的Service服务来实现设计的逻辑功能模块，每一个逻辑模块对应一个应用中的Service服务。应用需要保存一些终端的参数信息以及终端上本地存储的文件块信息，通过Android系统自带的SQLite数据库来存储相关的信息。通过上述的多个Service服务以及本地的SQLite数据库搭建实现了应用的基本结构。终端上运行的Android应用能够通过Service服务能够实现终端文件管理组件FileController、任务管理组件TaskController、状态监测组件ResourceController和通信组件mdfslet的相关功能。表3-1终端及应用信息参数项参数值开发语言Java终端操作系统Android系统版本4.0+终端处理器架构ARM应用开发环境AndroidStudio终端本地数据库SQLite开发完成的安卓应用基本界面由图3-2给出。图3-2（a）是节点上的功能组件ResourceController收集到的节点本地的资源和网络使用情况，存储在Android智能终端本地的SQLite数据库当中，可以在APP中查看到监控到的参数信息，同样，ResourceController会将监控到的信息通过心跳信息发送管理面-29-万方数据 哈尔滨工业大学工程硕士学位论文的Master节点上。图3-2（b）节点上的功能组件TaskController运行完管理面下发的Task任务后保存在Android智能终端本地的SQLite数据库当中的任务运行信息，包括任务的ID、参数、和运行结果等信息，相关的信息会通过mdfslet组件上传到管理面。图3-2（c）是节点上的功能组件FileController从管理面接收到存储的文件块后保存在Android智能终端本地的SQLite数据库当中的文件块的相关信息，包括文件块的唯一识别编码、名称、大小等所属初始文件信息等相关信息。a）节点本地监控信息b）节点本地任务信息c）节点本地文件块信息图3-2安卓终端应用示意图3.3.2WebUI网页端、mdfsctl命令开发用户控制台是以Web网页的形式呈现的，用户通过控制台能够很好的访问和操作整个分布式管理平台。整个控制台的开发使用的是Html语言，配合响应式布局的页面，让网页可以适配不同的屏幕，使得用户可以在各种可以运行Web浏览器设备上访问和操作分布式管理平台，WebUI的界面如图3-3所示。图3-3为开发完成的用户操作和管理分布式系统的WebUI界面，用户借助前端网页来对系统平台进行操作和管理。用户在控制台上可实现以下几个功能。（1）状态监控。监控所有节点的资源情况以及运行情况，同时监控任务以及文件先关的信息。（2）修改系统平台配置信息。查看和修改系统的相关配置信息，包括文件块大小、是否启动压缩等。-30-万方数据 第3章基于智能移动终端的分布式管理平台实现（3）文件管理。对分布式系统进行文件操作，包括文件上传、删除等。图3-3开发的平台WebUI界面图3.3.3服务器Server端开发服务器Server是整个分布式管理平台的核心，整个服务器的基本信息参数由表3-2所列出。表3-2服务器硬件及软件信息参数项参数值服务器操作系统Windows服务器型号WindowsServer2008R2CPU型号IntelXeonE5-2650RAM大小4GB服务器平台容器Apache-Tomcat-6.0.20平台类型JavaWeb系统数据库MySQL5.5.40JDK版本1.6.0_25服务器逻辑框架SSH整个服务是搭建在以Windows操作系统为基础的硬件服务器上。服务器容器选择的是开源的Apache的Tomcat，数据库选择的是Oracle旗下开源的-31-万方数据 哈尔滨工业大学工程硕士学位论文MySQL。移动终端和客户端通过不同的网络接口和Web服务器进行通信，不同的网络接口具有着不同的功能。服务器中有三个不同的逻辑功能模块，分别是FileManager文件管理组件、JobManager任务管理组件和ResourceManager状态管理组件。服务器上这些逻辑功能模块根据设定的要求以封装好的函数的形式存在于网络接口服务当中，当客户端或者是移动终端通过某一个接口访问服务器的时候，服务器根据接口的功能，调用合适的函数来提供相关的逻辑功能服务。整个管理面都工作在服务器上，Server端的开发平台使用的IDE是MyEclipse，如图3-4所示。图3-4服务器server的开发IDE界面3.4平台功能测试在整个平台的三个主要部分Server、APP和WebUI都开发完成的基础上，需要针对当初平台设计的功能进行相关的测试，确保开发的系统平台能够实现开始设定的功能目标，主要的功能有文件管理、状态监控、计算任务以及调度系统，下面分别介绍这几个功能的测试。3.4.1文件系统测试平台中的文件存储是将文件分块存储到不同的终端节点上[19]，主要涉及到的逻辑功能模块是终端节点上的FileController组件和服务器上的FileManager-32-万方数据 第3章基于智能移动终端的分布式管理平台实现组件。用来测试的文件信息参数由表3-3所列出。表3-3测试的文件信息文件名文件大小文件类型applicationContext.xml7kBXML配置文件Localhost2016-03-01.log140kB日志文件mdfs.sql16kB数据库数据文件schools.txt100kB文本格式文件通过将这四个文件上传至系统平台，来测试系统分布式文件存储的功能。为了便于观察，测试文件存储的时候只有一台IMEL码为000000000000000的移动终端连接至平台，那么这台移动终端将会把所有的文件块都下载到本地。服务器上的FileManager负责找出网络状况及存储资源好的节点，将文件分配给这些节点，并将文件的分布元数据存到数据库当中。实际测得的FileManager生成的元数据如表3-4所示，系统平台默认的文件块大小是50kB。FileManager生成的文件分布信息即元数据中，将文件块重新命名，命名规则是所在文件ID加上“_”符号再加上文件的序列号，文件后缀名不变。通过上传文件测得FileManager的功能正常。表3-4FileManager生成的文件分布信息文件块ID所在文件ID节点IMEL块名称块大小块序列号2543300000000000000033_1.xml7kB12553500000000000000035_1.sql16kB12563900000000000000039_1.txt50kB12573900000000000000039_2.txt50kB22583800000000000000038_1.log50kB12593800000000000000038_2.log50kB22603800000000000000038_3.log40kB3节点上的FileController负责管理终端节点上本地的分块文件，实际测得IMEL码为000000000000000的终端节点本地的目录下存储的文件块的详细信-33-万方数据 哈尔滨工业大学工程硕士学位论文息如表3-5所示。表3-5是测试使用的Android手机的文件下存储的文件块列表，可以看出，Controller已经将该节点上应该存有的文件块都已经下载下来，Controller实现了其所设计的功能。表3-5Android终端本地目录下的文件块文件名文件序号文件大小33_1.xml17kB35_1.sql116kB38_1.log150kB38_2.log250kB38_3.log140kB39_1.txt250kB39_2.txt350kB3.4.2监控系统测试系统的监控功能主要涉及终端节点上的ResourceController组件和服务器上的ResourceManager组件。ResourceController模块的功能是采集终端节点的硬件信息、网络信息和分块文件信息,并将信息上传至服务器。ResourceManager负责将ResourceController上传的信息进行处理。在测试ResourceController和ResourceManager的功能过程中，使用了包括虚拟机在内的一共10台安卓智能终端，ResourceController组件收集节点的监控信息，如图3-5所示。a）节点资源状态信息b）节点存储文件信息图3-5Android客户端上监控数据-34-万方数据 第3章基于智能移动终端的分布式管理平台实现移动终端上ResourceController服务收集的移动终端的硬件和网络信息如图3-5（a）所示，所收集的本地文件块信息如图3-5（b）所示。从图3-5中可以看出，Android应用当中的ResourceController服务很好的实现了其应当具有的功能。服务器上的ResourceManager服务模块是负责管理终端应用上的ResourceController模块所上传的节点硬件和网络信息，监测节点的计算和存储性能以及网络状态，监测到的基本信息如表3-6、3-7所示。通过表这两个表，ResourceManager服务模块能够很好的管理和监测系统中所有的终端节点的硬件信息和网络状态信息，能够实现平台功能设计中的基本监控功能。表3-6ResourceManager生成的节点信息列表1OSCpuNodeIDSystemIdCompanyPhonetypeOSRamCoresVersFreq4946011Xiaominoteandroid4.4.1291300437630031MeizuMX5android5.129451183847170371MeizuM353android4.4.18061000456452711LGENexus4android4.1.46651100112表3-7ResourceManager生成的节点信息列表2NodeIdStorageRestStorageNetTypeNetSpeed4946013104857610485762G865953763007104857610485764G69755471703110485761048576Wi-Fi5235645271104857610485763G59523.4.3任务及调度系统测试平台中的分布式计算主要涉及到两个功能模块，分别是服务器上的JobManager和移动终端上的JobController。服务器将计算任务下发至移动终端，移动终端上的JobController功能模块监测终端上任务运行的情况，并将任务运行的结果反馈给服务器上的JobController,服务器上的JobController控制服务器将节点传送上来的计算结果进行最终的处理，得出最终的计算结果。-35-万方数据 哈尔滨工业大学工程硕士学位论文为了测试平台的分布式计算功能，有针对性的设计了一个有代表性的移动分布式计算任务，日志文件中的信息检索。首先，将需要进行检索的日志文件通过系统分散的存储到不同的移动终端上；其次，服务器给含有这些日志文件块的移动终端发送检索任务；移动终端在接收到计算任务后，对保存在本地的文件块进行检索，运行初步计算任务，并将检索结果传回服务器；最后，服务器将各个移动终端上传上来的检索结果进行汇总，得出最终的检索结果。日志文件块的分布情况如表3-8所示。150kB大小的日志文件被分割成50kB大小的3个文件块存储在三个不同的移动终端上。在这三个终端上运行的检索子任务的基本信息如表3-9所示，检索的内容为包含“手机扫码”字段的日志信息。表3-8日志文件块分布信息文件块ID节点IMEL码文件块名称文件块大小文件块序列号340000000000000000102_1.log50kB1341867246023763007102_2.log50kB2342866646023375986102_3.log50kB3表3-9节点上任务信息任务ID所在节点IMEL码文件块ID运行时间任务是否完成5700000000000000034011ms完成588672460237630073416ms完成598666460233759863424ms完成图3-6（a）为终端上计算任务的信息，图3-6（b）为生成的最终检索任务结果。通过对最终的计算结果进行测试表明，移动终端能够很好的执行服务器下发的对于终端本地文件的检索任务。所以，通过所设计实现的以智能移动终端为基础的分布式管理平台能够很好的利用移动终端自身的计算资源，使得该平台能够将各个移动终端上的计算资源加以整合利用，很好的完成了利用终端计算资源这一设计目标。同时，终端节点上执行的文件检索任务的执行过程可以看出，该任务实际上同时调用了移动终端上的计算资源和存储资源，使得两种资源能够协调且同时被平台调用，使得所设计实现的平台能够适应更多更复杂的计算任务，提升整个平台的适应性和可扩展性。-36-万方数据 第3章基于智能移动终端的分布式管理平台实现a）节点上保存的任务信息b）管理面生成的最终计算结果图3-6节点和Web端的任务信息3.5本章小结本章在上一章的内容基础上，详细介绍了系统平台实现的具体过程，同时详细介绍了智能终端应用的开发实现、服务器端开发实现以及Web控制端及相关控制指令的设计与实现。在完成了各部分功能组件开发的基础上，同时也对平台的主要功能进行了相应的测试，实现了所设计的平台基本功能。相比于传统的以计算机为节点的分布式系统，本文所设计的平台主要的优势在于以下几个方面：（1）针对的主要目标是智能移动终端，能够将移动终端上分散的资源进行整合和利用；（2）监控系统会采集比传统分布式系统更详细的更多维度的监控数据；（3）会对各个移动终端的网络状况、硬件性能和资源状况进分析和评级，对每个移动终端上的资源调用执行差异化调度方案。-37-万方数据 哈尔滨工业大学工程硕士学位论文第4章基于智能移动终端的分布式管理平台优化4.1引言上一章节介绍了平台中的各个组件的开发实现以及平台功能的具体实现。本章节将在该系统平台基本功能已经实现的基础上，对系统平台当中存在的问题进行相应的优化，包括系统文件存储的可靠性优化、数据传输有效性优化以及实际用户体验的优化。4.2平台文件可靠性优化在设计和实现了平台的基本功能的基础上，由于移动终端和普通计算机在很多方面存在着差异性，所以平台依旧存在着很多可以优化的地方。包括工作节点和管理面之间数据传输的有效性、存储在节点上文件的可靠性、不影响用户正常操作等可以优化的地方将会在本章中来进行相关的介绍。本节首先介绍文件存储可靠性的优化。由于移动终端通过移动网络接入系统平台当中，信道条件比传统的局域网差很多，这给终端节点上文件可靠性带来了很大的挑战。平台的文件可靠性描述是：在分布式系统出现节点故障造成节点上存储文件丢失情况下，文件保持完整性的能力。由于所设计的平台是以智能移动终端为基本的工作节点，而移动终端出现异常的概率要远远大于普通的PC，所以，需要针对这一问题做有针对性的优化方案，来保证平台当中文件存储的可靠性。4.2.1传统冗余备份方案传统的HDFS[24]分布式文件系统的可靠性解决方案[30]：冗余备份。分布式系统的文件冗余备份方案的基本思想是：通过将文件的所有文件块进行冗余备份，冗余的文件块和原文件块存储在不同的节点上。当一个节点发生故障造成节点上数据丢失的时候，可以从别的存储节点获取丢失的数据，从而保证平台中文件的完整性，进而提升系统平台的可靠性。一个文件在系统平台中的文件块总数表示如下（4-1）所示：nm*(w1)（4-1）式中n——总的文件块个数；m——初始文件块个数；-38-万方数据 第4章基于智能移动终端的分布式管理平台优化w——文件冗余度。其中，n、m和w均为整数。假设每个文件块故障率为f，n个总的文件块在满足备份文件块不存储在同一个节点条件的基础上，平均存储到每一个存储节点，则该文件保持完整的概率的表达式如式（4-2）所示。jpi1li（4-2）式中p——文件完整概率；j——总的节点个数；li——i个节点正常工作时文件保持完整概率。图4-1描述了在m=50，w=2以及j=50的情况下，不同故障率f对应的文件保持完整概率的情况。1m=50,w=2,j=500.90.80.70.6文件完整率0.50.400.050.10.150.20.250.3节点故障率图4-1冗余备份完整度仿真图通过仿真结果可以看出，在冗余备份方案下，随着节点故障率的增加，文件保持完整的概率在降低[31]，使得冗余备份方案在节点故障率高的情况下无法为文件提供高完整性。由于传统分布式系统的节点故障率非常小，使得传统的分布式系统在冗余备份方案下文件可以保持高可靠性。然而，在面向以移动终端为存储节点的分布式存储时，由于移动终端节点的故障率远大于计算机节点-39-万方数据 哈尔滨工业大学工程硕士学位论文的故障率，传统的冗余备份方案在面向移动终端的分布式存储中性能低下，所以需要采用另外的可靠性存储方案。4.2.2喷泉码方案采用喷泉码方案的必要性在于：由于传统的冗余备份方案的弊端在于每个文件块之间相互独立，互不相关，当某一个文件块丢失的时候，无法通过别的文件块来进行恢复，造成原文件的不完整，直接导致了在高节点故障率的情况下，无法保证文件的高可靠性。现在需要一种方案，在该方案中文件块之间存在着一定的相互关系，使其携带尽可能多的信息，当某个文件块丢失的时候，可以通过别的文件块通过一定的方式进行恢复，这样就可以保证文件在高文件块故障率下保持高可靠性，而数字喷泉编码就是符合条件的这样一种方案。数字喷泉（DigitalFountian）的概念[32]最早由JohnByers和MichaelLuby等人在1998年首次提出，其是针对大规模数据传输以及可靠广播的特点及需求提出的一个比较理想的解决方案。数字喷泉的基本概念[33]是：在数据的发送端，通过将需要发送的原始数据划分成许多数据块，然后对生成的数据块执行编码操作，输出的是编码过后的数据块流[34]。在数据的接收端，只要接收到一定数量的数据块，就能够通过相关的译码操作将原始的数据给恢复出来，无需关系所接收到的数据块的顺序问题。数据的发送端像喷泉一样源源不断的产生编码后的数据块，所以称之为喷泉编码。首个实现喷泉编码技术的是LT码[35]，由MichaelLuby在2002年首次提出。由于数字喷泉码具有低译码复杂度、不需要反馈、能够适应变化信道状况等优点[36]，使得数字喷泉码在可靠广播传输、空间信息网络、深空通信、分布式存储等领域得到了非常广泛的应用。4.2.3LT码LT码[37]（LubyTransformCode）是第一种实现数字喷泉码的编码，LT码可以在原始数据的基础上[38]，生成任意长的一个编码数据流，每个编码包通过相同的算法独立生成[39]。数据接收端在接收到一定数量以上的编码数据时，就能以极高的概率通过计算恢复出原始信息。该码具有编译码简单、译码开销较小和低编译码复杂度等优点。由喷泉码的概念可知，发送端能够无限的产生并输出编码后的喷泉码，所以，LT码是一种无速率码[40]（Ratelesscodes）。LT码的整个编码过程如图4-2所示，编码步骤如下。步骤一：将原始数据分成k个长度相同的原始的数据包，在1~k范围内按-40-万方数据 第4章基于智能移动终端的分布式管理平台优化照某一个编码度数分布Ω随机选取一个整数d，其中k称之为原始数据的码长，d称之为编码数据包的度数。步骤二：从原始k个数据包中随机抽取d个不同的原始数据包。步骤三：将随机抽取的d个数据包执行异或运算，得出一个编码包。在该度数分配下使得LT码每个编码包的平均编码复杂度为O(logk),度数分布1,2,3,4,......,D表示了从1~D整数中随机选取到整数d的概率为Ωd的概率分布情况，D为能够随机取到的最大值。编码度数分布的函数表达式[41]可写成式（4-3）的形式。2D1(x)xx......x（4-3）123D12345···k-1k原始数据度数分布d度概率异或+10.0520.430.140.06编码包....图4-2LT码编码示意图定义nn()k为接收端在接收到的编码包个数，(nk)/k为译码步骤中的译码开销，接收端在接收到n个编码包之后，就能够通过相关的译码算法开始译码过程。其中最常用的LT码解码算法是参考文献[33]中提到的BP（BeliefPropagation）算法，该算法的译码复杂度为On(log)n。BP算法译码过程如图4-3所示，基本译码步骤如下。步骤一：从编码包中找到任意的一个度数是1的编码包，如果当前的编码包中不存在度数为1的编码包[42]，那么停止解码；如果能够找到度数为1的编码包，那么就可以根据该码块将与其连接的原始数据块进行恢复，同时删除这个度数为1的编码包，如图4-3（b）所示。步骤二：将已经恢复的原始数据块和与这个数据块相连接的所有进行模二加，消除这个数据块在与之相连的编码块中的模二分量，同时双向图中的相应的边删除掉，将去掉模二分量的编码包度数减1，如图4-3（c）所示。-41-万方数据 哈尔滨工业大学工程硕士学位论文步骤三：重复的执行步骤一和步骤二，一直到最终的译码结束。译码结束以后，如果原始数据当中的所有的数据块都成功恢复了，那么就译码成功了[43]，如果有数据块没有恢复，那么译码失败，就需要获取更多数量编码块才能够继续执行译码。如图4-3（d），4-3（e）和4-3（f）所示。从LT码的编解码过程中可以看出，合理的度数分布将会直接影响到LT码的译码成功率，进而直接影响到LT码的性能，是决定LT码性能的关键[44]。首先来说，应该使得码块的平均度数尽可能的小，来降低创建每个码块所需要的计算量；其次来说，又应该给较大的度数一定的抽取概率，才能够在编码包数量nk的情况下尽可能的覆盖所有的原始数据块，使得编码块中包含的原始数据块信息尽可能的多，以提高译码成功率。原始数据块编码包111011011110a）找度为1码块b）恢复初始码块c）删除模二分量10101011111d）重复a)b)c)操作e）重复a)b)c)操作f）译码结束图4-3LT码译码示意图最早使用的LT码度数分布函数是MichaelLuby提出的理想孤波分布[45]（IdealSolitionDistribution,ISD），此分布的概率密度函数如式（4-4）所示。1d＝1k()d1（4-4）dk＝2,3,...,dd(1)式中k——原始数据块个数;-42-万方数据 第4章基于智能移动终端的分布式管理平台优化d——度数值；(d)——度数分布概率密度。从理想孤波分布的概率分布中能够看出，度数d=1被抽取的概率的概率非常的低，同时高度数d并没有被赋予一定的抽取概率，这就造成了在理想孤波分布下，LT码的译码成功率并不高[46]。为了解决理想孤波分布带来的问题，MichaelLuby在理想孤波分布基础上提出了增加了一个调节函数(d)的改进型度数分布，以增加度数d=1以及高度数被抽取的概率，从而增加理想孤波分布的译码性能，进而提高译码鲁棒性。添加了调节函数的改进过后的度数分布称之为鲁棒孤波分布RSD（RobustSolitionDistribution）。(d)调节函数如式（4-5）所示。其中，sckln(k/)表示度数为1的编码块个数的期望值，将其称之为波纹值[47]，波纹值的不同的取值将会对LT码的编译码性能有产生非常大的影响[37,47]。参数c是一个经验常数值，一般的取值范围是c(0.001,0.05)。skd＝123...,()-1，，，kdsssktd()ln()d＝kgs（4-5）k0ds式中s——度数为1的码块期望值;——容许的译码失败率的上限。鲁棒孤波分布RSD的概率密度函数(d)如式（4-6）所示。(d)(d)(d)（4-6）Z其中Z是调节函数和理想孤波分布ISD的归一化数值，如式（4-7）所示。在理想信道中，接收端只要接收到的编码包个数n'kZ，则就可以以成功率不小于1-的概率译码成功。kZ((d)(d))[48]（4-7）d1图4-4给出了在k=100条件下，随着译码开销的增加，ISD与RSD两种度数分布下译码结果的对比，详细仿真参数由表4-1给出。从图4-4中可以看出，在原始数据块个数k=100的条件下，随着译码开销的增大，ISD和RSD两种分布情况下LT码的BP算法译码失败率在减小；同时，RSD分布的译码-43-万方数据 哈尔滨工业大学工程硕士学位论文失败率要低于ISD分布的译码失败率，可见RSD分布的译码性能要好于ISD分布的译码性能。表4-1ISD和RSD两种分布解码仿真参数及取值参数含义取值k原始数据块个数100c经验值常数0.03容许译码失败率上限0.01译码开销0~21ISD,k=1000.9RSD,k=1000.80.70.60.5译码失败率0.40.30.20.1000.20.40.60.811.21.41.61.82译码开销图4-4ISD和RSD译码结果对比图4.2.4LT喷泉码在分布式存储中的应用喷泉码在分布式领域中有着很多的研究，参考文献[49]给出了喷泉码在分布式系统中可以应用的范围，文献提出了基于喷泉码的存储系统的概念。本文在此基础上，将LT喷泉码应用到了高节点故障率的移动分布式存储中，提升文件在分布式存储系统中的完整性，进而提升平台的可靠性。基于LT喷泉码的分布式存储原理如图4-5、4-6所示。-44-万方数据 第4章基于智能移动终端的分布式管理平台优化原始文件···文件块1文件块2文件块3文件块kLT码编码器···编码文件块移动终端移动终端移动终端图4-5存储文件编码过程图图4-5是将原始文件进过喷泉编码产生文件码块存储到移动终端节点上的示意图，整个存储的步骤如下。步骤一：将原始文件转换成二进制，并分割成k个长度相等的原始数据块。步骤二：通过对k个原始数据块进行基于RSD的LT编码，并产生k(1)个编码文件块。步骤三：将k(1)个编码文件块均匀的存储在以移动终端为基础的存储节点上。图4-6是从移动终端节点上回收提取文件码块解码出原文件的示意图移动终端移动终端移动终端···编码文件块LT码解码器原始文件图4-6提取文件解码过程图-45-万方数据 哈尔滨工业大学工程硕士学位论文文件提取的步骤如下。步骤一：从在线的移动终端节点中提取节点上的编码文件块。步骤二：在获取一定编码文件块的基础上进行LT解码[50]。步骤三：将成功解码的二进制文件恢复成初始原文件完成文件的提取。在传统的冗余备份方案中，存储在节点上的文件块含有的自身数据信息，读取文件时必须包含每一个文件块才能保证文件的完整性。在基于LT码的分布式存储方案中，相对于传统的冗余备份方案的优势在于，存储在节点上的编码文件块含有多个原始文件块数据信息，在读取文件的时候，丢失的码块上的码源信息可以通过别的编码快通过解码进行恢复，在节点出现很高的离线率的时候，可以给文件存储提供更高的可靠性[51]。在LT码方案下文件完整率p的表达式如式（4-8）所示，式中，nk·(1)为编码后总的码块个数，li表示有i个节点正常工作时候节点上存储KZ个编码块的概率。jiijipi1(1)Cni((1f)f)l（4-8）LT码方案与传统方案完整性结果对比如图4-7所示，仿真参数由表4-2给出，图4-7详细的描述了两种可靠性方案随着节点故障率的提升，保证文件完整性的概率的走势。1冗余方案0.9LT方案0.80.70.6文件完整率0.50.400.050.10.150.20.250.3节点故障率图4-7冗余备份方案和LT码方案可靠性仿真结果图-46-万方数据 第4章基于智能移动终端的分布式管理平台优化表4-2LT码方案和冗余备份方案可靠性仿真参数及取值参数含义取值m冗余备份方案原始数据块个数50w冗余备份方案冗余度2KLT码方案原始数据块个数50cLT码方案经验值常数0.01εLT码方案译码开销2f两种方案的故障率0~0.3j节点个数50KZLT译码时需要的文件块个数59从图4-7中可以看出，在相同的冗余情况下（冗余备份方案冗余度w=2、LT码方案译码开销2），传统的冗余备份方案随着故障率的增加急剧下降，在节点故障率为30%时，传统备份方案完整率只有33.8%，而LT码方案完整率达到99.9%，极大的提升了文件存储的可靠性。4.2.5喷泉码方案开销分析基于喷泉编码的文件可靠性优化方案在提高文件可靠性的同时，给系统平台增加了一些额外的开销，就是对原始文件块的编解码操作。在采用RSD分布的情况下，每个编码块的平均编码时间复杂度为O(logk)，其中k为原始文件块。采用BP算法来进行译码，译码的时间复杂度为On(log)n，其中n为接收端接收到的编码块的个数。从编码和译码开销的时间复杂度可以看出，喷泉编码方案给系统平台带来的额外的计算开销的时间复杂度都不高，处于可接受的范围内，增加的系统平台开销也处于可控的范围内。4.3平台有效性优化4.3.1传输数据压缩方案由于移动终端与系统平台之间的信息交互完全依赖于移动互联网，而移动互联网中数据流量资源相对于传统的分布式系统局域网中的流量资源要有限的多。如何高效的利用移动终端的数据流量资源将成为系统性能优化的核心。其中对有效的方法便是数据压缩，通过数据压缩，能够很大程度上降低移动终端-47-万方数据 哈尔滨工业大学工程硕士学位论文与后台系统之间的数据通信量，提升整个平台的性能。本系统由于是基于JavaWeb集成框架，所以选用JDK自带的原生GZIP压缩方法来压缩数据。图4-8出了在未使用数据压缩和使用数据压缩这两种情况下移动终端下载文件块的耗时情况。通过测试同一台移动终端在相同网络条件下下载相同的文件块所耗用的时间来监测数据压缩对于平台性能的提升。测试使用的文件块大小为50kB至500kB，文件块个数为4，测试使用的移动终端接入网络的模式是Wi-Fi，Wi-Fi带宽为4Mbit/s。从图4-8结果可以看出，使用压缩算法后500kB文件块变成了22kB，大小缩小了95%以上，通过使用合适的数据压缩方法，能够极大程度上减少移动终端和后台系统之间的数据通信量，从而提升整个平台的传输性能。50004500未使用压缩使用压缩400035003000）ms2500耗时（20001500100050000100200300400500文件块大小（kB）图4-8使用压缩与未使用压缩耗时对比图4.3.2节点分级及节点筛选方案由于所设计的面向智能移动终端的分布式管理平台是以智能移动终端为基本工作节点的，而智能移动终端连接到管理面的方式是通过移动网络或者Wi-Fi网络来实现的，信道条件远远差于传统PC分布式系统所在的局域网络。所以，当平台中存在网络状态特别差的工作节点的时候，如果依旧给网络状态差的节点分配相关的存储或者计算任务的话，这些状态差的节点很难完成相关任务，-48-万方数据 第4章基于智能移动终端的分布式管理平台优化将会影响任务执行的总体进程。为了使得任务能被够高效的执行，需要将状态条件差的节点排除在外，不作为正常的工作节点，在原有的节点状态类型中添加一种网络条件差的状态Bad，如表4-3所示。表4-3Node工作节点状态类型状态类型名称类型介绍Ready工作节点处于正常可以工作的状态。Bad工作节点网络传输延时较大，无法正常接收或反馈信息。NotReady工作节点处于离线状态，无法接受任何指令信息。工作节点处于在线状态，但是节点的可用资源不足，无法完成Insufficient管理面发送的任务信息。表4-4列出了常见的几种移动终端接入互联网与服务器之间的大致时延范围，Wi-Fi的网络延时在0-50ms之间；4G网络的时延正常在0-100ms之间；3G网络的时延在100-200ms之间[52]；2G网络的延时在200-500ms之间；网络延时超过500ms的移动终端的网络已经处于一个非常糟糕的状态，如果给信道条件特别差的移动终端分配文件存储任务，该移动终端很可能无法完成文件接收任务，即便能够正常接收文件，耗时也会非常的巨大。表4-4常见接入方式时延接入方式网络时延Wi-Fi0~50ms4G0~100ms3G100~200ms2G200~500ms根据网络延时将移动终端的网络状况按照一定的标准量化为10个等级，如表4-5所示。将移动终端的网络信道状态以50毫秒为间隔分割成10个等级，等级0为最优状态，等级10为最差状态，网络等级为10的终端节点标记为不可用的Bad状态，不去调用这些节点上的资源。-49-万方数据 哈尔滨工业大学工程硕士学位论文表4-5网络状况划分等级网络时延信道优劣等级0~49ms050~99ms199~149ms2150~199ms3200~249ms4250~299ms5300~349ms6350~399ms7400~449ms8450~499ms9>=500ms10除了对终端的网络状况进行等级划分以外，每个终端同样需要一个指标来对移动终端节点的计算性能来进行衡量，该指标被设定为score，每个节点的score计算方式由式（4-9）所示。TotalRamCpuFrequency*CoreNumberkkkscore（4-9）knnTotalRami(CpuFrequencyCoreNumberi*i)ii11式中TotalRam——内存数量;CoreNumber——CPU数量；CpuFrequency——CPU主频；k——第k个节点；n——总的节点个数。分子表示该节点的信息，分母表示当前可用节点资源的总和。移动终端的计算性能主要由Cpu和内存来决定，移动终端上内存越大、Cpu核心数越多和Cpu主频率越高，移动终端的score就越大，代表着其计算性能也就越强。4.3.3信道自适应分配方案在以移动终端为存储节点的分布式存储系统当中，由于存储节点信道条件存在很大差异[30]，传统分布式系统的文件分配策略会大大降低文件传输的有效-50-万方数据 第4章基于智能移动终端的分布式管理平台优化性[53]。文献[50,54]提出了降低基于喷泉码存储时延的优化方案，本文在此基础上提出信道自适应方案，其基本思想是：在保证节点有足够存储空间的情况下，让信道传输条件差的节点分配尽量少的文件块，让信道传输条件好的节点分配尽量多的文件块，以达到降低文件传输时延，提升平台传输有效性的目的。为实现上述信道自适应方案，在参考LT码的度数随机抽取方案的基础上，在分配文件块的时候采用类似的随机抽取方法，信道条件好的被抽取的概率大，而信道条件差的被抽取的概率小[21]。整个信道自适应方案在LT码可靠性[4]存储方案基础上来实现。信道自适应方案原理图如图4-9所示。12345···k-1k原始文件块LT编码器节点概率分布节点概率N1q1N3N2q2编码文件块N3q3....Nrqr······N1N2N3Nr图4-9信道自适应分配方案结构图自适应分配方案基本执行步骤如下。步骤一：通过对原始的文件块进行LT编码，产生编码文件块。步骤二：根据节点抽取概率分布，随机的抽取出一个存储节点。步骤三：将编码生成的文件块分配给抽取出的节点。步骤四：重复执行一、二、三，不断通过LT编码产生编码文件块，直到产生编码个数达到指定的数量完成文件传输。图4-9中Ni表示r个存储节点，qi表示r个存储节点每一个节点各自被抽取的概率。其中，qi由式（4-10）给出。Biq（4-10）iC式中Bi——每个节点的传输带宽;-51-万方数据 哈尔滨工业大学工程硕士学位论文rC——i1Bi表示归一化总传输带宽。令每个节点上剩余的存储容量为si，x表示每个编码文件块的大小，则基本的约束条件由式（4-11）给出。Bi0ri1qi1(i1....r)（4-11）six令tm为单节点最大耗时，ta为总耗时，图4-10给出了在相同条件下，使用平均分配方案和信道自适应方案这两种方案下tm和ta的对比，仿真参数由表4-6给出。300tm,平均分配ta,平均分配tm,自适应分配250ta,自适应分配200150耗时(s)10050001002003004005006007008009001000源文件大小(bit)图4-10平均分配方案和自适应方案仿真结果图表4-6平均分配方案和信道自适应方案仿真参数及取值参数含义取值b原文件的大小0~1000bitr节点个数10x文件块大小1bitBi各个节点带宽{1,2,...,10}bit/s-52-万方数据 第4章基于智能移动终端的分布式管理平台优化图4-11给出了LT码存储方案在平均分配和自适应分配两种分配方案下的文件完整性和冗余备份方案的对比，仿真参数由表4-7给出。1冗余方案，平均分配0.9LT方案，自适应分配0.80.70.6文件完整率0.50.400.050.10.150.20.250.3节点故障率图4-11LT码方案平均分配和自适应分配对比仿真图表4-7平均分配方案和信道自适应方案仿真参数及取值参数含义取值m冗余备份方案原始数据50w冗余备份方案冗余度块个数2KLT码方案原始数据块个50cLT码方案经验值常数数0.01εLT码方案译码开销2f故障率0~0.3j节点个数50KZLT译码时需要的文件块59Bi各个节点带宽{1,2,...,50}bit/sγ容许译码失败率上限0.001从图4-10的仿真结果可以看出，使用了信道自适应分配方案后，在所设仿真条件下相比于传统平均分配方案，单节点最大耗时tm降低了80%，文件总传-53-万方数据 哈尔滨工业大学工程硕士学位论文输耗时ta降低了39%；而且，从图4-11的仿真结果可以看出，在LT码存储方案的基础上，信道自适应分配方案相对于平均分配方案在文件完整性上并未出现明显降低，完整率为99.8%，接近100%。由此可知，信道自适应文件块分配方案在保证系统文件可靠性的基础上，有效的降低了文件块的传输时延，提升了文件在平台中的传输效率，进而提升了整个系统平台存储的有效性。4.4平台用户体验优化由于所设计的面向智能移动终端的分布式管理平台，除了充当系统平台当中的工作节点以外，同样也是个人用户日常操作和使用。用户操作终端的优先级要高于分布式系统操作终端。所以，在系统平台调用终端来执行相关的操作的同时，要尽量减少对用户正常操作终端的影响。本章的主要内容就是介绍如何让设计的平台尽量避免影响到用户的正常操作。4.4.1终端忙碌状态策略为了避免对用户在正常操作终端造成影响，给系统平台中的终端添加了一个忙碌状态Busy，当系统平台将节点运行模式切换到Busy状态策略的时候，处于忙碌状态的智能终端将不会处理任何平台下发的任务，同时，平台也不会给处于忙碌状态的终端调度分配任务。添加完Busy状态后的Node节点工作状态由表4-8给出。终端Busy状态主要需要满足以下几个条件：（1）终端处于解锁状态，且用户在执行相关的操作。（2）终端处于息屏状态，但是系统后台有下载任务在执行。（3）终端的CPU占用率在50%以上。（4）内存使用率在70%以上。表4-8Node工作节点状态类型状态类型名称类型介绍Ready工作节点处于在线，且可用资源充足，处于正常工作状态。Bad工作节点网络状态较差，无法正常完成分配的任务。Busy终端的用户正在实际操作终端，当前节点不作为工作节点。NotReady工作节点处于离线状态，不能接收管理面发送的任务指令信息。Insufficient工作节点处于在线状态，但是节点的可用资源不足，无法使用。-54-万方数据 第4章基于智能移动终端的分布式管理平台优化当开启了终端的忙碌状态策略以后，处于Busy状态的终端即便是接入平台当中，也不会作为可以正常工作的工作节点来进行处理。只有当节点处于非Busy状态且网络状况良好的处于闲置状态的智能移动终端才能最终最为当前平台可以利用的正常工作节点，只有这样，才能尽量降低系统平台对用户正常操作终端的影响。4.4.2存储资源自动释放策略当所设计的分布式管理平台在执行与文件相关的任务的时候，势必会占用智能移动终端本地的存储空间，如文件检索任务。由于占用了移动终端本机的本地存储空间，势必会对用户的存储资源进行了占用，当用户本机的存储空间不足的时候，分布式管理平台占用的本地存储空间将会直接影响到用户正常的文件存储操作。为了在终端本机存储资源不足的情况下不影响用户正常的存储操作，制定了存储资源自动释放策略。存储资源自动释放策略的实际工作流图如图4-12所示。Master管理节点重新调度APIServerFileManagerScheduler文件快文件快心跳信息(资源预警)Node子节点NodeNodeResource资源不足Controller组件图4-12存储资源自动释放策略示意图自动释放策略的基本工作过程如下。步骤一：工作节点上的ResourceController组件监测到终端本地存储孔空间出现不足，发出节点存储资源预警信号。步骤二：ResourceController组件将资源预警信号发送到管理面APIServer，APIServer将预警信息转发给FileManager组件。步骤三：FileManager从预警节点上将节点上存储的文件块回收回来，将收回的文件块重新交给Scheduler调度器来进行重新调度，调度到资源充足的-55-万方数据 哈尔滨工业大学工程硕士学位论文节点上去，同时释放资源预警节点上占用的存储资源。步骤四：资源充足的节点获取资源预警节点上的文件块，完成占用资源的释放以及文件的转移。4.4.3任务池策略在整个系统平台设计当中，Node节点上分配多少任务量都是由管理面Master节点上的Scheduler调度器来分配的，Node节点被动的来接收管理面下发给的task任务。从用户的角度来讲，Node节点自己来决定在节点空闲的时候来执行多少的任务量会比原先的方案更加的合理。因此，提出了基于任务池这一策略，其基本原理图如图4-13所示。JobManager组件任务调度未Task任务池生成TaskTaskTaskTaskTaskTaskTaskTaskTaskTaskTaskTask务任取拉节点1节点2节点Nmdfslet组件mdfslet组件mdfslet组件TaskController组件TaskController组件TaskController组件图4-13任务池策略示意图相对于之前的方案来说，整个任务系统的执行的没有涉及到通过Scheduler调度器对生成的Task任务进行调度的过程，JobManager生成的子任务没有绑定具体的Node节点，Node节点自己主动向管理面来拉取Task任务。基于任务池的任务方案的任务执行的基本步骤如下。步骤一：用户向管理面提交计算任务。步骤二：JobManager将计算任务进行拆分，将拆分好的所有Task子任务放入任务池当中。-56-万方数据 第4章基于智能移动终端的分布式管理平台优化步骤三：Node节点通过mdfslet组件主动的从管理面任务池中拉取Task任务，并交由TaskController来执行。节点上执行的具体Task任务的数量由Node节点自己来决定，而不是由管理面Scheduler调度器来决定，让终端节点自主决定要执行的任务量。步骤四：将Task任务执行的结果反馈给管理面，完成整个任务的执行。任务池策略很好的解决了节点被动接收任务的问题，降低对用户操作影响的同时，有效的解决了由于用户操作节点造成节点上调度的任务无法有效执行这一问题，提高了任务执行的效率。4.5本章小结本章在前面章节完成系统平台基本功能的设计、实现和测试完成的基础上，有针对性的对所设计的系统平台的几个方面进行了相关的优化。主要优化的部分包括平台的可靠性、平台的有效性以及平台各用户体验这三个方面。通过本章节的系统平台优化，使得所设计完成的系统平台在很多方面的性能得以提升。-57-万方数据 结论结论一种以智能移动终端的分布式管理平台是当前移动互联网快速发展的时代下迫切需要的系统平台。本文在参考传统的分布式系统Hadoop以及Google的Kubernetes分布式容器编排调度系统的基础，设计并实现一套基于智能移动终端的分布式管理平台，本文取得的主要科研成果如下。（1）建立开发了一套基于互联网技术的以智能移动终端为基础的分布式管理平台，通过该管理系统平台，实现了对智能移动终端上存储资源和计算资源的调用，使得可以通过该系统平台实现对智能移动终端上闲置资源的一个整合和调用。（2）提出了基于“能者多劳”策略的自适应分配调度策略，使得资源充足计算能力强的移动终端节点承担相应更多的任务，从而加速整个系统平台任务执行的过程，提升系统平台整体运行的有效性，同时提出了数据压缩方案，提升系统平台数据传输的有效性。（3）提出了基于数字喷泉编码的分布式文件存储策略，通过该策略对分布式存储的原始文件块进行编码操作，通过存储编码块的方式替代存储文件块的方式，使得当部分节点故障造成码块丢失的情况下，只要获取一定数量的码块即可恢复初始文件，保证了在高节点故障率下文件存储的可靠性；（4）提出了节点分级和节点筛选方案，通过节点分级方案对节点的网络传输性能以及计算性能进行量化，方便调度系统来进行调度；通过节点筛选方案，过滤掉资源状态差和故障节点，保证不因为问题节点而影响系统平台稳定性。（5）提出了节点忙碌策略、资源自动释放策略以及资源池策略以提升所设计的系统平台的用户体验，使得在系统平台正常运行的同时尽可能的降低系统平台运行给用户实际操作移动终端的影响。测试表明，本文设计并搭建的以智能移动终端为基础的分布式管理平台能够实现通过应用接入到系统平台当中的移动终端上存储资源和计算资源进行整合并调用；同时，针对节点资源状况的不同做差异化处理以及数据压缩策略的引入，有效的提升平台运行的效率；基于数字喷泉码方案的存储方案有效的提升了文件在高节点故障率下存储的可靠性；针对用户体验的节点忙碌等策略有效的降低了平台对用户正常操作移动终端的影响。尽管所设计的平台基本实现了对移动终端上资源，但是，以智能移动终端为基础的分布式管理平台依然存在着很多的问题，有待进一步研究。-58-万方数据 哈尔滨工业大学工程硕士学位论文参考文献[1]李勇.基于移动互联网的国际象棋对弈系统的设计与实现[D].武汉:华中科技大学,2011:15-22.[2]余晓辉.打造中国移动互联网升级版[J].世界电信，2014(9)：16-23.[3]房宇星.基于移动互联网的高校就业助手设计与实现[D].北京:北京邮电大学,2014:32-40.[4]YuX,NingP,VoukMA.EnhancingSecurityofHadoopinaPublicCloud[C]//InternationalConferenceonInformation&CommunicationSystems,NewYork:IEEE,2015:1324-1350.[5]田祎.分布式计算机网络结构的可靠性与运行模式分析[J].电脑知识与技术，2014(12):8390-8391.[6]ShvachkoK,KuangH,RadiaS,etal.TheHadoopDistributedFileSystem[J].MassStorageSystemsandTechnologies(MSST),2010:1-10.[7]余骏.面向海量天文数据的分布式存储引擎的研究[D].天津:天津大学,2013:12-30.[8]ShiW,SanthoshS,LufeiH.Cegor:AnAdaptiveDistributedFileSystemforHeterogeneousNetworkEnvironments[C]//ParallelandDistributedSystemsInternationalConference,California:IEEEComputerSOC,2004:145-152.[9]韩帅.基于云计算的数据安全关键技术研究[D].成都:电子科技大学,2012:40-43.[10]黄素萍,葛萌.Hadoop平台在大数据处理中的应用研究[J].现代计算机(普及版),2013(10),12-15.[11]周霞，王华军.基于云计算的贝叶斯分类算法在过滤垃圾邮件中的研究[J].电脑与电信,2014(21):53-55.[12]唐颖,刘国庆.基于Hadoop的云架构区域PACS存储方案设计[J].中国医疗设备,2013(8):47-50.[13]KalaKA.AReviewonHadoop—HDFSInfrastructureExtensions[C]//IEEEConferenceonInformation&CommunicationTechnologies(ICT),NewYork:IEEE,2013:132-137.[14]戴君.基于Hadoop的作业调度算法的研究和改进[D].武汉:武汉理工大学,2013:33-35.[15]陆嘉恒.Hadoop实战第2版[M].北京：机械工业出版社出版社,2012:103-130.-59-万方数据 哈尔滨工业大学工程硕士学位论文[16]张轶.RDB平台和大数据平台混搭式的数据中心设计[J].计算机技术与发展,2015(5):172-178.[17]HoneymanP,HustonLB.CommunicationsandConsistencyinMobileFileSystems[J].IEEEPersonalCommunications,1996,2(6):44-48.[18]LuJ,DuB,ZhuY,etal.MADFS:TheMobileAgent-BasedDistributedNetworkFileSystem[C]//GlobalCongressonIntelligentSystems(GCIS),California:IEEEComputerSoC,2009(1):68-74.[19]QiaoY,LeiZ,YangJ,etal.FLAS:TrafficAnalysisofEmergingApplicationsonMobileInternetUsingCloudComputingTools[C]//InternationalSymposiumonWirelessPersonalMultimediaCommunications,NewYork:IEEE,2013:6.[20]MaY,YuanD,ZhangH.FountainCodesandApplicationstoReliableWirelessBroadcastSystem[C]//IEEEInformationTheoryWorkshop,NewYork:IEEE,2006:66-70.[21]BochP,AfarikJ.MaintainingCacheConsistencyforMobileClientsinDistributedFileSystem[C]//EngineeringofComputerBasedSystems,NewYork:IEEE,2013:55-62.[22]LiaoJ.MobiDFS:ALightweightMobileDistributedFileSystem[D].UniversityofTennessee,2015:1-8.[23]SegarraMT.OnBuildingaFileSystemforMobileEnvironmentsUsingGenericServices[C]//InternationalConferenceonParallelandDistributedComputingSystems,USA:ISCA,1999:150-158.[24]BorthakurD.HDFSArchitectureGuide[EB/OL].(2008-06-05)[2016-12-11].http://hadoop.apache.org/common/docs/current/hdfs_design.pdf.[25]HuchtonS,XieG,BeverlyR.BuildingandEvaluatingaK-ResilientMobileDistributedFileSystemResistanttoDeviceCompromise[C]//Milcom,NewYork:IEEE,2011,8069(5):1315-1320.[26]BarretoJ.Haddock-FSADistributedFileSystemforMobileAd-hocNetworks[EB/OL].(2004-05-11)[2016-11-01].http://gsd.inesc-id.pt/~jpbarreto/bib/JoaoBarreto_MsC_HaddockFS.pdf.[27]LuiJCS,SoOKY,TamTS.NFS/M:AnOpenPlatformMobileFileSystem[C]//TheInternationalConferenceonDistributedComputingSystems,California:IEEEComputerSoC,1998:488-950.[28]ExecutionT,SubmissionJ.MapReduceTutorial[EB/OL].（2008-04-12）[2016-12-12].https://www.mendeley.com/catalog/mapreduce-tutorial/.[29]何润润.网络环境下的分布式存储系统的设计与实现[D].武汉:华中科技大学,2011:27-31.[30]ChongKFE,KurniawanE,SunS,etal.FountainCodeswithVarying-60-万方数据 哈尔滨工业大学工程硕士学位论文ProbabilityDistributions[C]//InternationalSymposiumonTurboCodesandIterativeInformationProcessing,NewYork:IEEE,2010:176-180.[31]AntonyS,BaruaG.Lean-DFS:ADistributedFilesystemforResourceStarvedClients[C]//InternationalWorkshopDistributedComputing,Germany:Springer-VerlagBerlin,2004:150-155.[32]MackayDJC.Fountaincodes[J].IEEProceedings-Communications,2005,152(6):1062-1068.[33]ByersJW,LubyM,MitzenmacherM.ADigitalFountainApproachtoAsynchronousReliableMulticast[J].IEEEJournalonSelectedAreasinCommunications,2002,20(8):1528-1540.[34]UsmanM,DunlopJ.ATestbedforAssessmentofFountainCodesforWirelessChannels[C]//NextGenerationWirelessandMobileCommunicationsandServices,NewYork:IEEE,2005:1-6.[35]LubyM.LTCodes[C]//SymposiumonFoundationsofComputerScience,York:IEEE,2002:271-280.[36]ParkGS,SongH.AFountainCodes-basedHybridP2PandCloudStorageSystem[C]//InternationalConferenceonICTConvergence,NewYork:IEEE,2013:78-79.[37]LuH,FohCH,WenY,etal.Delay-OptimizedFileRetrievalunderLT-BasedCloudStorage[J].IEEETransactionsonCloudComputing,2015,11(99):1-6.[38]高飞,曾宪锋,卜祥元.基于跳频通信的短码长Raptor码改进方案[J].北京理工大学学报,2013,33(4):403-407.[39]朱宏杰.喷泉码编译码技术与应用研究[D].北京:清华大学,2009:22-26.[40]李海莲.喷泉码编译码研究[D].哈尔滨:哈尔滨工业大学,2009:23-25.[41]祝开艳.基于编码的协作通信技术研究[D].大连:大连理工大学,2014:18.[42]吴可镝.无线通信系统中无速率码的编译码技术与应用研究[D].浙江:浙江大学,2011:27-30.[43]姜泽雄.纠删码在网络存储系统中的实现与可靠性仿真[D].成都:电子科技大学,2010:33-35.[44]张杨帆.无线多播中的数字喷泉码技术研究[D].成都:华中科技大学,2008:21-25.[45]张亚昕,刘华.基于LT码数据分发协议性能分析[J].计算技术与自动化,2014,33(2):141-144.[46]张冀.Fountain码编译码算法的研究[D].洛阳:河南科技大学,2009:19-25.[47]詹奇聪.喷泉码与极化码的改进及应用[D].广州:华南理工大学,2014,33-35.-61-万方数据 哈尔滨工业大学工程硕士学位论文[48]何建.基于云计算的移动式数据终端设计研究[D].南京:南京理工大学,2011:22-27.[49]陈霄.分布式喷泉码在分布式存储系统中的应用模型与方法研究[D].成都:电子科技大学,2013:33-37.[50]LuH,FohCH,WenY,etal.OptimizingContentRetrievalDelayforLT-basedDistributedCloudStorageSystems[C]//GlobalCommunicationsConference,NewYork:IEEE,2012:1920-1925.[51]KocaM,AriI,KocakU,etal.ParallelandPipelinedProcessingofLarge-scaleMobileComminucationDataUsingHadoopOpen-sourceFramework[C]//SignalProcessingandCommunicationsApplicationsConference,NewYork:IEEE,2012:1-4.[52]汪晓松.基于重路由的匿名通信系统的设计与实现[D].上海:复旦大学,2012:19-22.[53]NightingaleEB,FlinnJ.Energy-efficiencyandStorageFlexibilityintheBlueFilesystem[C]//ConferenceonSymposiumonOpeartingSystemsDesign&Implementation,USA:UsenixAssoc,2004,29(3):363-378.[54]陶杭.基于Hadoop的SVM算法优化及在文本分类中的应用[D].北京:北京邮电大学,2015:11-15.-62-万方数据 攻读硕士学位期间发表的论文及其它成果攻读硕士学位期间发表的论文及其它成果申请及已获得的专利[1]朱旭.一种基于智能移动终端的分布式文件系统，公开号：CN205581864U，公开日：2016-09-14[2]朱旭，张朝阳，丁婵娟，赖德朴，孙玉飞.一种手机支架隐藏式自拍杆：公开号：CN205725957U，公开日：2016-11-23.[3]张钦宇，朱旭.一种基于LT喷泉码的面向移动终端的分布式文件存储系统：申请号：2016110402240,申请日期：2016-11-24.[4]张钦宇，朱旭.一种基于智能移动终端的分布式计算系统：申请号：2016212181695,申请日期：2016-11-17.[5]朱旭.一种智能移动终端自身资源及状态监控系统：申请号：2016212548276,申请日期：2016-11-23.[6]朱旭.一种终端设备的资源整合调度系统.申请号：201621254474.X,申请日期：2016-11-23.-63-万方数据 万方数据 致谢致谢在攻读硕士学位的两年半的时间中，我的导师张乃通教授给予了我细心的指导，让我在整个硕士阶段收获很多。张钦宇教授是一位严谨、和蔼、认真负责的导师。在哈尔滨工业大学深圳研究生院攻读硕士研究生期间，张钦宇教授在生活和学习上对我们的都非常的关心。在整个硕士课题包括选题、开题、中期、答辩等过程中，张钦宇教授给了我非常多的跟踪和指导。同时也非常感谢张钦宇教授给我们去企业实习的机会，让我们能够去企业解除面向市场的实际产品。在硕士学位攻读的时间过程当中，实验室的同学以及老师们也都给与了我很多的照顾，课题的正常完成他们给予了我很多的帮助。同时，也要感谢王野师兄在课题上给予我的帮助，以及给我去公司学习的机会，帮助我在课题和项目工作上都取得了不错的成绩。非常感谢导师张乃通教授、张钦宇教授以及王野师兄对我的细心要求和教导，他们对我的指导使我一生受益。谨向在我攻读硕士学位这两年半的时间内帮助过我的朋友、老师、同学、同事致以感谢。-65-万方数据
此文档下载收益归作者所有
