CN112532754B - 校网文件快速服务方法和系统 - Google Patents

Abstract

本申请涉及校网文件快速服务方法和系统，属于大数据技术领域，该方法包括：接收多个客户端发送的文件资源的服务请求；通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点；通过目标节点处理服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制文件资源的数据，并利用后继的节点分担负载压力。通过本申请实施例，文件服务功能的扩展性强、灵活性高，且文件服务快速，能够高效的应对高并发。

Description

校网文件快速服务方法和系统

技术领域

本申请涉及大数据技术领域，特别是涉及校网文件快速服务方法和系统。

背景技术

目前，校网文件服务采用集中的存储设备存放所有数据，设备本身成为系统性能的瓶颈，也是可靠性和可用性的焦点，不能满足大规模存储应用的需要。而且，随着学校和学生的增加，现有的校网文件服务设备往往不能较好的应对高并发。

因此，如何将校网文件服务应用于大规模存储场景中，同时保证服务的高效性，成为本领域技术人员亟待解决的技术问题。

发明内容

本申请实施例提供了一种校网文件快速服务方法和系统，以至少解决相关技术中如何将校网文件服务应用于大规模存储场景中，同时保证服务的高效性的问题。

第一方面，本申请实施例提供了一种校网文件快速服务方法，包括：接收多个客户端发送的文件资源的服务请求；通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点；通过所述目标节点处理所述服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制所述文件资源的数据，并利用所述后继的节点分担负载压力。

在其中一些实施例中，所述Chord算法包括sha-1哈希算法。

在其中一些实施例中，在各所述节点设有LVS（Linux Virtual Server）负载均衡的情况下，所述的通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点包括：所述LVS负载均衡根据Chord算法转换所述节点的IP；若所述节点中存有所述文件资源，则该节点为目标节点。

在其中一些实施例中，在所述的接收多个客户端发送的文件资源的服务请求之前，所述方法包括：所述LVS负载均衡根据预设的轮询机制进行主备切换。

在其中一些实施例中，所述的利用所述后继的节点分担负载压力包括：通过所述负载监控模块判断后继的节点的负载压力是否低于预设阈值，若是，则预先通知该后继的节点复制所述文件资源的数据；所述后继的节点向存储有所述文件资源的节点发起共享下载；所述服务请求被转发到所述后继的节点并从共享下载或者本地中获取数据。

在其中一些实施例中，所述的利用所述后继的节点分担负载压力包括：当所述服务请求处于高峰期，将请求入口依序转到各所述后继的节点上，直到出现所述后继的节点的负载压力低于预设阈值为止。

在其中一些实施例中，在多个所述节点同时为客户端提供文件资源下载服务的情况下，由Leader节点控制外网下载请求和数据同步，其中，所述Leader节点由各所述节点按照Raft算法选举出。

在其中一些实施例中，所述的由Leader节点控制外网下载请求和数据同步包括：多个节点向所述Leader节点竞争外网下载权，竞争成功的节点从外网下载文件资源；竞争失败的节点和未参与竞争的节点从竞争成功的节点获取数据。

在其中一些实施例中，在所述的接收多个客户端发送的文件资源的服务请求之前，所述方法包括：对每个所述节点配置多个班级ID和学校ID，所述学校ID为一级条件，所述班级ID为二级条件；当所述一级条件和所述二级条件成立时，或者，当所述一级条件成立且所述二级条件不成立时，允许访问所述节点。

第二方面，本申请实施例提供了一种校网文件快速服务系统，包括：接收模块、查找模块和处理模块，接收模块用于接收多个客户端发送的文件资源的服务请求；查找模块用于通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点；处理模块用于通过所述目标节点处理所述服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制所述文件资源的数据，并利用所述后继的节点分担负载压力。

基于以上内容，本申请实施例的校网文件快速服务方法包括：接收多个客户端发送的文件资源的服务请求；通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点；通过目标节点处理服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制文件资源的数据，并利用后继的节点分担负载压力。通过本申请实施例，文件服务功能的扩展性强、灵活性高，且文件服务快速，能够高效的应对高并发。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的校网文件快速服务方法的流程图；

图2是根据本申请实施例的Chord环形结构示意图；

图3是根据本申请实施例的客户端与节点间的关系示意图；

图4是根据本申请实施例的校网文件快速服务系统的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块（单元）的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

针对目前的校网文件服务，如达到一定规模的用户数，网络设施也会随之扩展，而目前校网文件服务系统受限于单机的情况下无法达到理想效果，即本身存储容量、网络带宽、硬件性能扩展不便，发生故障也将无法使用。因此，校网文件服务系统需要具备易扩展和高可用的能力来解决这些问题，更是为将来提升到区域级服务做准备。

本申请实施例涉及将校网文件服务系统升级为分布式存储的实现设计，下文将本申请实施例的校网文件服务系统简称为RFS(Regions File System)。该RFS中，将分散的存储设备构建成一个虚拟的庞大存储池来供上层应用使用。具体的，将数据分散存储在多台独立的设备上，并且可横向扩展，利用多台存储设备分担存储负荷，并利用DHT（Distributed Hash Table）算法来定位存储的信息，不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

作为一个示例，客户端（例如平板）通过微服务获取RFS中各节点的IP地址列表，然后向节点发送文件资源的服务请求，若请求失败，则尝试向下一个节点发出请求，以此类推。由于RFS包含多个节点，其采用分布式文件存储方式，可以通过DHT算法查找到文件资源所在的节点，该过程中可以通过LVS负载均衡（不经过代理层）直接向存储层发送请求，然后存储层直接反馈用户数据，其中，每个节点都主动维护自己在微服务上的IP。

作为一种实施方式，本申请实施例提供一种校网文件快速服务方法，图1是根据本申请实施例的校网文件快速服务方法的流程图，如图1所示，该方法包括：

步骤S100：接收多个客户端发送的文件资源的服务请求；

步骤S200：通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点；

步骤S300：通过目标节点处理服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制文件资源的数据，并利用后继的节点分担负载压力。

为了更清楚的说明本申请的内容，下文对上述校网文件快速服务方法进行详细的阐述。

本申请中，考虑到随着学校的增加，RFS中的节点会越来越多，这些RFS可以是一个地区的局域网，也可以是互通的大型网络，而文件资源存储在各个网络节点之中，因此，本申请实施例采用Chord算法，该Chord算法是上述DHT的一种实现方式，是一种能在大型网络高速定位资源的算法，而且能保证收敛性，对于节点的查找可以达到O(logn)效果，即当数据增大n倍时，耗时增大logn倍，这里的log是以2为底的，比如，当数据增大256倍时，耗时只增大8倍。另外，通过DHT算法将文件资源存储到与客户端最近的节点以进行put、get。

关于上述的Chord算法，其通过将节点的IP和文件资源的标志（例如ID）映射到相同的空间从而保证一致性哈希，本申请实施例中采用sha-1哈希算法，能够产生一个160位的ID，也就意味着资源的存放空间能达到2^160，而按传统的方法存储资源，其数量远远达不到这种天文数字。图2是根据本申请实施例的Chord环形结构示意图，该Chord环形结构为上述预设的环形结构，如图2所示，从节点0到31首尾相连形成一个环，例如按顺时针，针对任意节点，该节点前面的成为前继(predecessor)，该节点后面的成为后继（successor)；同理，第一个predecessor称之为直接前继，第一个successor称之为直接后继。在进行资源定位时，实际上就是查找目标节点，该目标节点中存储有客户端请求的文件资源，例如，在各节点设有LVS负载均衡，LVS所转换的目标节点IP由Chord算法得来，即用户访问资源的路由实际上是由RFS控制，若节点中存有客户端请求的文件资源，则定位该节点为目标节点。由于每个节点会维护一个finger表，该表的长度为2^m-1(m为位数，也就是160)，节点判断自身的finger表中是否存在客户端请求的关键词（即ID，文件资源的标志），若不存在，则会从最远的一个后继节点中重复该操作直到存在为止，即Chord的核心算法具有收敛性，能够达到对数效果。

图3是根据本申请实施例的客户端与节点间的关系示意图，如图3所示，本申请实施例提供有范围的文件服务，在做关联部署时，各节点可以是现有的文件服务盒子（Box，以下简称“盒子”），从而可以绑定盒子和班级的一对多关系，尽量在每增加一个盒子的情况下发挥其硬件存储、IO和网络的最大化功能，无需购买太多昂贵的服务器，能够降低经济成本。基于此，可以指定某批班级下的用户访问某个盒子，通过分散用户来达到多节点服务的目的。例如，对每个盒子配置多个班级ID和学校ID，该学校ID为一级条件，该班级ID为二级条件，当一级条件和二级条件成立时，或者，当一级条件成立且二级条件不成立时，允许访问节点，避免班级ID配置更新不及时导致获取不到盒子。基于上述部署方式，部署的方式简单，效率高，能够满足现有需求，扩展时，文件服务无需改动，在微服务上进行配置即可。

盒子或者校级服务器一般限于1~2张网卡，当服务的速度达不到学校网络最大带宽级别的时候，需要增加服务器来提升，校网文件服务也需要支持同一个学校，所以需要部署多个服务器。假设一个盒子关联的某批班级中有50个人来下载PPT(10MB)，总流量500MB，盒子的网卡是千兆，也就是125MB/s，有线下载完成时间约4~5s，无线更差，因AP服务数而影响。而通过本申请实施例，能够让多节点来分担存储、IO的负荷，例如一台盒子的存储空间是100G，输入和输出为1/1000Mbps。随着用户的增加，例如1000人、2000人、5000人，甚至更多。由于现有的单机设计局限了后面的扩展，若通过升级硬件来提高服务能力，那么越到后面成本越来越高。而本申请实施例的方案不依赖和要求服务器的性能，尽量做到任何设备都可以充当节点。由于文件服务不依赖任何第三方程序，所以现有的盒子就可以使用，而且本申请实施例的技术方案可以为以后的区域级部署做准备。

进一步的，当服务请求处于高峰期，将请求入口依序转到各后继的节点上，直到出现后继的节点的负载压力低于预设阈值为止。例如，通过负载监控模块来判定是否通知后继的节点事先做好文件资源的数据复制，而后面的请求将由后继节点来处理，也就是利用后继的节点来分担负载压力。

当请求被转入后继的节点后，从共享下载或本地中获取数据，能够达到“用时复制”的效果，从而合理的提高了节点的利用率。具体的，对节点监控负载情况，例如，在更新应用时，若同一个文件资源被大量访问，根据Chord算法，相同资源只会定位到同一节点，而本申请实施例提出一种负载策略来定位到其他节点分摊压力。在预先通知后继的节点复制文件资源的数据之后，后继的节点向存储有资源的结点发起共享下载（Shared Download），那么客户端的请求将会被转发到的后继的节点中，并从共享下载或本地中获取数据。

作为一个示例，通过负载监控模块判断后继的节点的负载压力是否低于预设阈值，若是，则预先通知该后继的节点复制文件资源的数据。然后，后继的节点向存储有文件资源的节点发起共享下载，服务请求就会被转发到后继的节点中并从共享下载或者本地中获取数据。根据Chord环形结构，若负载压力大的节点数有很多，将请求入口依序转到各后继的节点上，那么最终会回到当前节点，从而进行了一个循环。若所有人同时访问同一个文件资源，就会体现出更佳的技术效果，例如每一节点都在工作，避免了只有一个点或少量的几个节点在工作而其他节点并不参与的现象，提高了节点的利用率，能够高效的提供文件服务，从而达到加快文件服务的技术效果。

因此，上述分布式技术方案具有以下效果：扩展性、灵活性高，节点之间互不依赖且互不干扰，将来可作为教育网中心部署、区域级分散部署，如学校网络能够互通的前提，集群的范围伸长到各个校园，跨校园的操作更加充分的利用资源。另外，高可用，去中心化，在服务故障的情况下要求任意节点能充当对外请求层。节约成本，无需购买高配置的服务器，盒子即可使用。本申请实施例的RFS系统采用分布式技术，以能够高效处理海量数据，经济低成本，服务高可用为目标，使同一区域网络下所有的服务器共同协作以承载集中在某一时刻大规模的流量。能够充分利用邻校资源，能够在有限的外网带宽下支持大量的文件访问，并且能够清除单点问题，确保业务的持续性。

作为另一个示例，本申请实施例中可设计RFS的节点集群，利用微服务的加权轮询功能分散客户端请求到各个节点上，以达到IO均衡受力的效果。

举例而言，在多个节点同时为客户端提供文件资源下载服务的情况下，由Leader节点控制外网下载请求以及数据同步，其中，该Leader节点由各节点按照Raft算法选举出。由于各节点中数据的强一致性，所以不会有同一条数据出现多个版本的情况，也就是不需要考虑版本冲突的问题。具体的，首先节点之间会有一个选举的过程，一旦Leader产生后，所有的外网下载请求都由Leader节点控制，例如同一时间有多个节点都向Leader节点来竞争外网下载权，竞争成功的节点从外网下载文件资源，而竞争失败的节点全部从竞争成功的节点获取同步数据，同时Leader节点还会邀请其他未参与竞争的节点向竞争到外网下载权的节点同步数据。日志则是用于宕机的节点在恢复后和Leader节点的日志索引比对以同步自身日志，从而保证集群内数据的一致性。本方案中，集群节点中每一个节点都是一个整体，其内存、硬盘、CPU、IO都能随着扩展而提高服务能力。

可选的，上传文件时，由正在受理的服务端将资源同步至整个集群，然后再响应客户端。针对时间段中的下载过程，假设RFS1为Leader节点，T1时间段，客户端C1和客户端C2同时向节点RFS1和节点RFS2请求下载文件，Leader节点根据客户端请求的先后顺序判定节点RFS2获得外网下载权，并且邀请节点RFS3从节点RFS2中同步数据，此时节点RFS2从外网下载，而节点RFS1从节点RFS2中下载；T2时间段，客户端C3发起从节点RFS3下载文件的请求，此时邀请节点RFS3同步的请求还未到达，所以节点RFS3会向Leader节点中竞争外网下载权，但是发现已经有人在外网下载了，那么节点RFS3从节点RFS2中下载；T3时间段，客户端C4向节点RFS1请求下载文件，此时节点RFS1已经从节点RFS2下载完文件资源并保存到本地了，所以客户端C4的下载会由节点RFS1独立完成。

基于以上内容，本申请实施例对以下需求予以实现：

（1）网络带宽扩展：校网文件服务的节点直接与核心交换机连接，核心交换机每个网口可以支持千兆，凡是经过核心交换机的设备都能与RFS通信，后面只需要一套均衡的路由分发到每台服务器上；

（2）存储容量的扩展：本申请中对文件资源的存储采用了分布式存储方式，不需要作集群内的全复制，可根据用户需要横向无限扩展存储节点，可以形成一个统一的共享存储池，所以每增加一个校网文件服务总存储容量会扩展70~100%；

（3）IO性能扩展：相比传统存储而言，提供高出数倍的聚合IOPS和吞吐量，另外可以随着存储节点的扩容而线性的增长，基于Chord协议，IO的压力会分配到整个集群上，每个节点都能发挥自己应用的IO能力；

（4）主备自动切换：去中心化，所有节点都装有LVS以能够充当中心，由于节点都会上报到微服务，LVS负载均衡根据微服务中预设的轮询机制进行主备切换，当其中一个节点挂掉之后会尝试下一个；

（5）客户端的支持：在多校网文件服务部署的情况下暴露一个RFS，客户端无需任何改动依然使用普通http方式下载；

（6）成本节约：对文件资源put、get所产生的流量在物理层面被分配到整个集群中，而不用购买专业的存储设备；

（7）部署简化：针对不可避免的必要配置，技术人员事先配置好后再拿到学校，尽量不让安装人员接触复杂环节，达到即插即用的目的。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例还提供一种校网文件快速服务系统，图4是根据本申请实施例的校网文件快速服务系统的结构示意图，如图4所示，该系统包括接收模块1、查找模块2和处理模块3，接收模块1用于接收多个客户端发送的文件资源的服务请求；查找模块2用于通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点；处理模块3用于通过目标节点处理服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制文件资源的数据，并利用后继的节点分担负载压力。

需要说明的是，该系统用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如本申请所使用的术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (8)

1.一种校网文件快速服务方法，其特征在于，包括：

接收多个客户端发送的文件资源的服务请求；

通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点，其中，每个所述文件服务节点配置有多个班级ID和学校ID，所述学校ID为一级条件，所述班级ID为二级条件，当所述一级条件和所述二级条件成立时，或者当所述一级条件成立且所述二级条件不成立时，允许访问节点；

通过所述目标节点处理所述服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制所述文件资源的数据，并利用所述后继的节点分担负载压力，

所述的利用所述后继的节点分担负载压力包括：

当所述服务请求处于高峰期，将请求入口依序转到各所述后继的节点上，直到出现所述后继的节点的负载压力低于预设阈值为止。

2.根据权利要求1所述的方法，其特征在于，所述Chord算法包括sha-1哈希算法。

3.根据权利要求1所述的方法，其特征在于，在各节点设有LVS负载均衡的情况下，所述的通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点包括：

所述LVS负载均衡根据Chord算法转换节点的IP；

若节点中存有所述文件资源，则该节点为目标节点。

4.根据权利要求3所述的方法，其特征在于，在所述的接收多个客户端发送的文件资源的服务请求之前，所述方法包括：

所述LVS负载均衡根据预设的轮询机制进行主备切换。

5.根据权利要求3所述的方法，其特征在于，所述的利用所述后继的节点分担负载压力还包括：

通过负载监控模块判断后继的节点的负载压力是否低于预设阈值，若是，则预先通知该后继的节点复制所述文件资源的数据；

所述后继的节点向存储有所述文件资源的节点发起共享下载；

所述服务请求被转发到所述后继的节点并从共享下载或者本地中获取数据。

6.根据权利要求1所述的方法，其特征在于，在多个节点同时为客户端提供文件资源下载服务的情况下，由Leader节点控制外网下载请求和数据同步，其中，所述Leader节点由各节点按照Raft算法选举出。

7.根据权利要求6所述的方法，其特征在于，所述的由Leader节点控制外网下载请求和数据同步包括：

多个节点向所述Leader节点竞争外网下载权，竞争成功的节点从外网下载文件资源；

竞争失败的节点和未参与竞争的节点从竞争成功的节点获取数据。

8.一种校网文件快速服务系统，其特征在于，包括：

接收模块，用于接收多个客户端发送的文件资源的服务请求；

查找模块，用于通过Chord算法从预设的环形结构上的多个文件服务节点中查找目标节点，其中，每个所述文件服务节点配置有多个班级ID和学校ID，所述学校ID为一级条件，所述班级ID为二级条件，当所述一级条件和所述二级条件成立时，或者当所述一级条件成立且所述二级条件不成立时，允许访问节点；

处理模块，用于通过所述目标节点处理所述服务请求，若节点负载压力超过预设阈值，则预先通知后继的节点复制所述文件资源的数据，并利用所述后继的节点分担负载压力，

所述的利用所述后继的节点分担负载压力包括：

当所述服务请求处于高峰期，将请求入口依序转到各所述后继的节点上，直到出现所述后继的节点的负载压力低于预设阈值为止。

Images