文件传输方法、装置、电子设备以及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及云计算、大数据、信息流等领域，具体地，涉及一种文件传输方法、装置、电子设备以及存储介质。

背景技术

在云环境下，很多业务会运维管理一些超大规模的集群，比如常见的上千个节点的Hadoop(一种分布式系统基础架构)大数据集群。在该种环境下，经常会有需求将一个文件(部署包、配置文件或者是数据)从一台机器或者是外部环境下载到集群内的多台机器上。

发明内容

本公开提供了一种文件传输方法、装置、电子设备以及存储介质。

根据本公开的一方面，提供了一种文件传输方法，包括：响应于确定集群的目标节点已获得待传输文件，获取针对目标节点配置的目标文件分发任务的信息，集群还包括目标节点的下游节点，目标文件分发任务的信息包括下游节点的下游节点标识；以及响应于接收到用于执行目标文件分发任务的第一执行指令，根据下游节点标识，将待传输文件发送至下游节点。

根据本公开的另一方面，提供了一种文件传输装置，包括：任务信息获取模块，用于响应于确定集群的目标节点已获得待传输文件，获取针对目标节点配置的目标文件分发任务的信息，集群还包括目标节点的下游节点，目标文件分发任务的信息包括下游节点的下游节点标识；以及文件发送模块，用于响应于接收到用于执行目标文件分发任务的第一执行指令，根据下游节点标识，将待传输文件发送至下游节点。

根据本公开的另一方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开的文件传输方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行本公开的文件传输方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序存储于可读存储介质和电子设备其中至少之一上，所述计算机程序在被处理器执行时实现本公开的文件传输方法。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1示意性示出了根据本公开实施例的可以应用文件传输方法及装置的示例性系统架构；

图2示意性示出了根据本公开实施例的文件传输方法的流程图；

图3示意性示出了根据本公开实施例的集群中节点的示例性结构图；

图4示意性示出了根据本公开实施例的文件分发任务的处理逻辑的示意图；

图5示意性使出了根据本公开实施例的确定当前任务的任务执行状态的整体流程图；

图6示意性示出了根据本公开实施例的单个文件分发任务或文件分发任务组中任务的任务状态转换图；

图7示意性示出了根据本公开实施例的文件传输装置的框图；以及

图8示出了可以用来实施本公开的实施例的示例电子设备的示意性框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。

在本公开的技术方案中，在获取或采集用户个人信息之前，均获取了用户的授权或同意。

在需要将一个文件从一台机器或外部环境下载到集群内的多台机器上时，一般通过单独搭建独立的源服务器或者服务集群实现。具体地，在集群内选取一个或者多个节点作为源，需要下载文件的多台机器同时从这些源并行下载文件，并且需要有一个固定的中心节点来监控每一个节点的下载状态。

发明人在实现本公开构思的过程中发现，上述方法需要单独维护独立的源服务器，成本较大，且源服务器的带宽容易成为下载瓶颈，导致整个下载任务效率变低。此外，还需要维护固定的中心节点，由中心节点来完成文件传输过程中的各项操作，中心节点很容易成为该种方案的稳定性瓶颈。

图1示意性示出了根据本公开实施例的可以应用文件传输方法及装置的示例性系统架构。

需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。例如，在另一实施例中，可以应用文件传输方法及装置的示例性系统架构可以包括终端设备，但终端设备可以无需与服务器进行交互，即可实现本公开实施例提供的文件传输方法及装置。

如图1所示，根据该实施例的系统架构100可以包括第一终端设备101、第二终端设备102、第三终端设备103，网络104和服务器105。网络104用以在第一终端设备101、第二终端设备102、第三终端设备103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线和/或无线通信链路等等。

用户可以使用第一终端设备101、第二终端设备102、第三终端设备103通过网络104与服务器105交互，以接收或发送消息等。第一终端设备101、第二终端设备102、第三终端设备103上可以安装有各种通讯客户端应用，例如知识阅读类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端和/或社交平台软件等(仅为示例)。

第一终端设备101、第二终端设备102、第三终端设备103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用第一终端设备101、第二终端设备102、第三终端设备103所浏览的内容提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务(″Virtual Private Server″，或简称″VPS″)中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

需要说明的是，本公开实施例所提供的文件传输方法一般可以由第一终端设备101、第二终端设备102或第三终端设备103执行。相应地，本公开实施例所提供的文件传输装置也可以设置于第一终端设备101、第二终端设备102或第三终端设备103中。

或者，本公开实施例所提供的文件传输方法一般也可以由服务器105执行。相应地，本公开实施例所提供的文件传输装置一般可以设置于服务器105中。本公开实施例所提供的文件传输方法也可以由不同于服务器105且能够与第一终端设备101、第二终端设备102、第三终端设备103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的文件传输装置也可以设置于不同于服务器105且能够与第一终端设备101、第二终端设备102、第三终端设备103和/或服务器105通信的服务器或服务器集群中。

例如，在用户在线阅读电子书时，第一终端设备101、第二终端设备102、第三终端设备103可以获取用户视线指向的电子书中的目标内容，然后将获取的目标内容发送给服务器105，由服务器105对目标内容进行分析，确定目标内容的特征信息；根据目标内容的特征信息预测用户感兴趣的内容；以及摘抄用户感兴趣的内容。或者由能够与第一终端设备101、第二终端设备102、第三终端设备103和/或服务器105通信的服务器或服务器集群对目标内容进行分析，并最终实现摘抄用户感兴趣的内容。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图2示意性示出了根据本公开实施例的文件传输方法的流程图。

如图2所示，该方法包括操作S210～S220。

在操作S210，响应于确定集群的目标节点已获得待传输文件，获取针对目标节点配置的目标文件分发任务的信息，集群还包括目标节点的下游节点，目标文件分发任务的信息包括下游节点的下游节点标识。

在操作S220，响应于接收到用于执行目标文件分发任务的第一执行指令，根据下游节点标识，将待传输文件发送至下游节点。

根据本公开的实施例，文件传输可以表征将传输文件从一个节点上下载，并发送至另一个节点的过程。集群中可以包括多个节点。在集群中的任意一个节点接收到待传输文件的情况下，可以将该节点确定为目标节点。目标文件分发任务可以表征将待传输文件从目标节点发送至目标节点的下游节点的任务。

根据本公开的实施例，在待传输文件尚未被发送至集群中的任意一个节点的情况下，可以首先在集群内选取一批初始种子节点。然后，从待传输文件的文件源并行下载待传输文件，并发送至初始种子节点。接收到待传输文件的初始种子节点可以被确定为目标节点。

根据本公开的实施例，在集群中存在一部分已获得待传输文件的目标节点的情况下，每个目标节点可以转换成种子节点的身份对目标节点的下游节点继续提供待传输文件的下载。接收到待传输文件的下游节点可以继续被确定为目标节点。在该种情况下，可以从任意一个目标节点开始，通过执行目标文件分发任务，在集群内做点对点的文件传输，直到集群内所有的节点都获得了待传输文件后任务结束。

通过本公开的上述实施例，实现了一种分布式去中心的扩散式点对点文件传输方法，由于在集群中实行点对点传输，能最大化利用集群内带宽资源，实现一个文件在多个机器上的下载，有利于快速完成文件下载任务。

下面结合具体实施例，对图2所示的方法做进一步说明。

根据本公开的实施例，在执行上述操作S210之前，需要首先确定目标节点配置的目标文件分发任务。该方法可以包括：响应于接收到表征向集群分发待传输文件的文件传输指令，根据文件传输指令所表征的文件传输信息，生成目标文件分发任务。将目标文件分发任务的信息发送至与集群的各个节点相连接的第二外部存储单元，以通过第二外部存储单元将目标文件分发任务的信息发送至集群的节点。

根据本公开的实施例，将集群中的机器节点命名为Peer(节点)，机器和机器之间可以互为对等的Peer关系，且不存在中心化节点。每一个Peer上可以正常部署JobScheduler(作业调度器)和TaskExecutor(任务执行器)等部件，JobScheduler和TaskExecutor被设计为无状态部件，且不同Peer的JobScheduler和TaskExecutor等部件之间不会相互感知。第二外部存储单元可以用于实现不会相互感知的Peer之间的信息同步。

图3示意性示出了根据本公开实施例的集群中节点的示例性结构图。

如图3所示，集群300包括第一Peer 310、第二Peer 320、第三Peer 330、第四Peer340。JobScheduler 301可以表征针对任意一个Peer部署的JobScheduler(在各个Peer的具体结构中不再示出)。对应于第一Peer 310、第二Peer 320、第三Peer 330、第四Peer 340，还分别部署有第一TaskExecutor 311、第二TaskExecutor 321、第三TaskExecutor 331、第四TaskExecutor 341。外部存储303可以表征上述第二外部存储单元。

例如，JobScheduler 301可以表征第一Peer 310中的JobScheduler。在集群300中的各个Peer均未获得待传输文件，且JobScheduler 301接收到表征向集群分发待传输文件这一文件传输工作302的文件传输指令的情况下，JobSchedule301可以响应于接收到该文件传输指令，根据文件传输信息，将该文件传输工作302拆解为多个文件分发任务，如图3中的多个文件分发任务304，并可以通过外部存储303将该多个文件分发任务304同步至第一Peer 310、第二Peer 320、第三Peer 330、第四Peer 340等各个Peer上。

根据本公开的实施例，生成的目标文件分发任务可以为多个，可以将该多个目标文件分发任务的信息全部发送至集群的各个节点。例如，第一TaskExecutor 311、第二TaskExecutor 321、第三TaskExecutor 331、第四TaskExecutor 341均可以获取到上述多个文件分发任务。

根据本公开的实施例，TaskExecutor可以响应于接收到用于执行文件分发任务的执行指令，执行相应的文件分发任务。例如，响应于接收到用于执行第二Peer 320中的文件分发任务的执行指令，利用第二TaskExecutor 321，执行第二Peer 320中的该文件分发任务。

通过本公开的上述实施例，通过配置第二外部存储单元，可以有利于使得集群中各个节点相互独立，有利于实现集群的去中心化，且能够实现灵活的横向扩展。

根据本公开的实施例，集群可以包括第一节点和第二节点。文件传输信息可以包括所述第一节点的第一节点标识和所述第二节点的第二节点标识。上述根据文件传输指令所表征的文件传输信息，生成目标文件分发任务可以包括：根据第一节点标识和第二节点标识，生成以第一节点为源节点、以第二节点为目的节点的目标文件分发任务。

根据本公开的实施例，在集群中存在多个节点的情况下，可以随机确定一个节点作为第一节点，随机确定另一个节点作为第二节点。在生成目标文件分发任务的过程中，以第一节点和第二节点中的哪个节点为源节点、哪个节点为目的节点也可以随机确定，在此不进行限定。

例如，参见图3，文件传输信息中可以包括第一Peer 310的第一节点标识Peer_id

需要说明的是，在基于上述方式确定目标文件分发任务的情况下，由于没有定义待传输文件被发送到各个节点中的具体存储地址，可以在各个节点中预先定义预存储地址，实现在节点获得待传输文件的情况下，将待传输文件存储至预存储地址。

根据本公开的实施例，文件传输信息还可以包括待传输文件的目标存储地址。上述根据文件传输指令所表征的文件传输信息，生成目标文件分发任务还可以包括：根据第一节点标识、第二节点标识和目标存储地址，生成以第一节点为源节点、以第二节点为目的节点、以第二节点中的目标存储地址为待传输文件的文件存储地址的目标文件分发任务。

根据本公开的实施例，由于得到的目标文件分发任务包括待传输文件的目标存储地址，可以在将待传输文件从源节点传输至目的节点的过程，直接将待传输文件存储至目的节点的目标存储地址。

根据本公开的实施例，上述将目标文件分发任务发送至所述集群的节点可以包括：根据目标文件分发任务的源节点的源节点标识，将目标文件分发任务发送至与源节点标识相对应的节点。

根据本公开的实施例，在确定多个目标文件分发任务之后，可以首先根据目标文件分发任务的源节点标识，从多个目标文件分发任务中过滤出以当前节点为源传输到其他节点的任务。然后，将该类任务发送至当前节点。

例如，参见图3及前述实施例，对于以Peer_id

通过本公开的上述实施例，可以减少集群中节点的数据量，减轻节点的负荷。

根据本公开的实施例，JobScheduler作为文件传输工作的派发部件，需要根据文件分发任务的状态感知文件传输工作的完成情况。因此，TaskExecutor可以定时将文件分发任务的状态都通过外部存储同步给JobScheduler。

基于此，上述文件传输方法还可以包括：响应于确定当前时刻到达预定义时刻，确定目标文件分发任务的目标任务执行状态信息。将目标任务执行状态信息发送至与集群的各个节点相连接的第一外部存储单元，以通过第一外部存储单元将目标任务执行状态信息发送至集群的各个节点。

根据本公开的实施例，可以通过预先执行定时操作，来确定当前时刻是否到达预定义时刻。第一外部存储单元可以与第二外部存储单元具有相同或相似的技术特征，在此不再赘述。

根据本公开的实施例，目标任务执行状态信息可以包括如下中的任意之一：init(初始化)、waiting(等待)、running(正在执行)、fail(执行失败且未完成)、done(执行成功)、faildone(执行失败且已完成)。Init可以表示任务初始化，还未被TaskExecutor认领。waiting可以表示TaskExecutor已认领该任务但是在等待上游任务执行。Running可以表示TaskExecutor正在执行该任务，将文件传输到其他节点。Done可以表示文件传输完成，任务执行成功。Fail可以表示文件传输失败，任务执行失败，但是因为有重试机制，所以任务并没有结束。Faildone可以表示任务失败并且达到最大重试次数，任务以失败状态执行结束。

需要说明的是，文件分发任务可以有固定的上游任务。当且仅当上游的任务成功执行完，且文件被顺利下载到该节点上之后，节点才能执行以自身为源的文件分发任务，将文件继续分发到其他的节点上。

通过本公开的上述实施例，可以定时更新各个节点中的目标任务执行状态信息，有利于集群搞笑、稳定的运行。此外，所有的状态同步均通过外部存储实现，可以实现灵活的横向扩展性。

根据本公开的实施例，TaskExecutor在执行一个文件分发任务时可以包括两个阶段。第一阶段为同步上游任务状态。TaskExecutor需要等到当前文件分发任务的上游任务执行完成，方能进入第二阶段，执行当前任务。

图4示意性示出了根据本公开实施例的文件分发任务的处理逻辑的示意图。

如图4所示，例如，第一文件分发任务401可以表征第二文件分发任务402和第三文件分发任务403的上游节点的任务。第二文件分发任务402可以表征第四文件分发任务404和第五文件分发任务405的上游节点的任务。第三文件分发任务403可以表征第六文件分发任务406和第七文件分发任务407的上游节点的任务。对于该些文件分发任务，只有当各上游节点的任务执行成功之后，才可以执行各上游节点下的子节点的文件分发任务。

根据本公开的实施例，集群还可以包括目标节点的上游节点。上述确定目标文件分发任务的目标任务执行状态信息可以包括：获取针对上游节点配置的上游文件分发任务的上游任务执行状态信息。响应于确定上游任务执行状态信息指示了未执行完成，在预设时间间隔之后再次读取上游任务执行状态信息。响应于确定上游任务执行状态信息指示了执行成功，将目标任务执行状态信息更新为正在执行。

根据本公开的实施例，init、waiting、running、fail均可以指示未执行完成。done可以指示执行成功。

例如，参见图4，在确定第一文件分发任务401的状态为init、waiting、running、fail中的任意之一的情况下，用于控制第二文件分发任务402的TaskExecutor以及用于控制第三文件分发任务403的TaskExecutor其中至少之一可以通过sleep(休眠)预设时间间隔的时间后再次去检查第一文件分发任务401的状态，直到第一文件分发任务401的执行结束。

根据本公开的实施例，done、faildone均可以指示执行结束。

例如，参见图4，在第一文件分发任务401的状态为done的情况下，第二文件分发任务402和第三文件分发任务403均可以进入running状态，可将第二文件分发任务402的状态和第三文件分发任务403的状态均更新为running，并启动文件传输，执行第二文件分发任务402和第三文件分发任务403。

根据本公开的实施例，上述确定目标文件分发任务的目标任务执行状态信息还可以包括：响应于确定上游任务执行状态信息指示了执行失败，将目标任务执行状态信息更新为执行失败。

例如，参见图4，在第二文件分发任务402的状态为faildone的情况下，表示第二文件分发任务402执行失败了，那么位于第二文件分发任务402下游的第四文件分发任务404和第五文件分发任务405也无法继续执行，可以将第四文件分发任务404的状态和第五文件分发任务405的状态均更新为faildone。在该种情况下，第二文件分发任务402、第四文件分发任务404的状态、第五文件分发任务405均以失败状态执行结束。

根据本公开的实施例，上述确定目标文件分发任务的目标任务执行状态信息还可以包括：响应于确定目标文件分发任务的重试次数等于预设次数，将目标任务执行状态信息更新为执行失败。

例如，参见图4，在第三文件分发任务403执行失败，且重试次数已经达到预设次数的情况下，可以将第三文件分发任务403的状态均更新为faildone。

根据本公开的实施例，上述重试次数可以通过如下方法确定：响应于确定目标文件分发任务执行失败，且确定重试次数小于预设次数，生成重新执行目标文件分发任务的第二执行指令，并将重试次数加1，重试次数的初始值为0。

根据本公开的实施力，每一个文件分发任务可以具有一个与之相对应的重试次数。在每一个文件分发任务被启动的情况下，可以将与该文件分发任务相对应的重试次数的值初始化为0。

例如，参见图4，在第三文件分发任务403的状态变更为running的情况下，可以将与第三文件分发任务403相对应的重试次数的值初始化为0。在第三文件分发任务403执行失败的情况下，可以对与第三文件分发任务403相对应的重试次数的值加1，并生成第二执行指令，重新执行第三文件分发任务403。

根据本公开的实施例，上述重试次数还可以通过如下方法确定：根据目标文件分发任务的启动时刻和当前时刻，确定目标文件分发任务的单次执行时长。响应于确定单次执行时长达到预设时长，且确定重试次数小于预设次数，生成重新执行目标文件分发任务的第三执行指令，并将重试次数加1。

根据本公开的实施例，某个任务可能会在节点上因为某些异常原因导致执行超时。针对该种情况，该节点的TaskExecutor在把任务从waiting转换成running时，可以将任务的启动时间写入任务执行状态里。当任务执行时间超过了设定的超时阈值参数时，TaskExecutor可以重新启动对该任务的执行，并且将重试次数增加1。

通过公开的上述实施例，提供了一种超时重试机制，可以有效处理文件分发任务执行超时的问题，缓解了任务超时导致文件传输工作长时间无法完成的问题。

图5示意性使出了根据本公开实施例的确定当前任务的任务执行状态的整体流程图。

如图5所示，该方法包括操作S501～S511。

在操作S501，获取上游任务upstreamTask。

在操作S502，判断upstreamTask.Status(上游任务的状态)＝＝‘init’‖‘waiting’||“running’‖‘fail’是否成立？若是，则执行操作S503；若否，则执行操作S504。

在操作S503，sleep一段时间。

在操作S504，判断upstreamTask.Status＝＝‘faildone’是否成立？若是，则执行操作S505；若否，则执行操作S506。

在操作S505，更新当前任务状态为‘faildone’。

在操作S506，判断upstreamTask.Status＝＝‘done’是否成立？若是，则执行操作S507；若否，则执行操作S505。

在操作S507，执行文件传输。

在操作S508，判断是否执行成功？若是，则执行操作S509；若否，则执行操作S510。

在操作S509，更新当前任务状态为‘done’。

在操作S510，判断是否达到最大重试次数？若是，则执行操作S505；若否，则执行操作S511。

在操作S511，更新当前任务状态为‘fail’。

通过本公开的上述实施例，可以实现各文件分发任务的有序、正确的执行，实现较高的执行效率及较好的文件传输效果。

根据本公开的实施例，在实际场景下可能存在同时有多个文件传输工作在运行的情况，在该种情况下，可能存在多个任务同时写同一个文件路径的情况。对应于该种情况，还需要考虑该种场景下的任务互斥问题。

根据本公开的实施例，目标文件分发任务可以包括在多个时刻生成的多个文件分发任务。上述确定目标文件分发任务的目标任务执行状态信息可以包括：根据多个文件分发任务各自的任务执行路径信息，将任务执行路径相同的文件分发任务分配至同一个文件分发任务组。根据针对同一个文件分发任务组定义的预设规则，确定同一个文件分发任务组中文件分发任务的任务执行状态，预设规则为根据互斥机制定义的规则。

根据本公开的实施例，任务执行路径可以根据文件分发任务的信息中的源节点、目的节点、目标存储路径确定。在多个文件分发任务的信息中的源节点、目的节点、目标存储路径均相同的情况下，可以确定该多个文件分发任务的任务执行路径相同，并可将该多个文件分发任务分配至同一个文件分发任务组。

根据本公开的实施例，基于互斥机制确定的预设规则可以包括如下中的任意至少之一：同一个组内最多只能有一个running状态的任务，简称规则一。如果一个组内存在一个running状态的任务，那么在这组里该running状态任务的生成时刻之前生成的waiting状态任务都被更新为ignored(忽略)状态，表示跳过执行，简称规则二。如果一个任务的上游任务状态为ignored，那么该任务的真正状态应该是触发该任务变更为ignored的同组内running任务的最终执行状态，简称规则三。

需要说明的是，上述预设规则仅是示例性实施例，但不限于此，还可以包括本领域能够基于互斥机制确定的其他预设规则，在此不进行限定。

根据本公开的实施例，在同一个Peer上执行的多个文件分发任务在写同一个目标路径的情况下，通过将该多个文件分发任务分配至同一个文件分发任务组，并基于互斥机制针对同一个文件分发任务组定义预设规则，在基于预设规则确定同一个文件分发任务组中文件分发任务的任务执行状态的过程中，TaskExecutor可以通过互斥机制确定同一个文件分发任务组中每个文件分发任务的任务执行状态，并可保障最终执行结果的正确性。

需要说明的是，上述确定文件分发任务的状态的方式仅用于确定组内文件分发任务的状态。对于文件分发任务组之外的任意单个文件分发任务的状态，可以基于前述确定单个文件分发任务的任务执行状态的方式确定，在此不再赘述。

通过本公开的上述实施例，可以通过互斥机制保障最终执行结果的正确性。

根据本公开的实施例，对应于上述规则一，预设规则可以包括：同一个文件分发任务组中最多一个文件分发任务的任务执行状态信息指示了正在执行。

通过本公开的上述实施例，当在同一个Peer上执行的多个文件分发任务在写同一个目标路径时，基于该规则，可以避免同时写的问题。

根据本公开的实施例，同一个文件分发任务组可以包括在第一时刻生成的第一文件分发任务以及在第二时刻生成的第二文件分发任务。对应于上述规则二，根据针对同一个文件分发任务组定义的预设规则，确定同一个文件分发任务组中文件分发任务的任务执行状态可以包括：响应于确定第一文件分发任务的第一任务执行状态信息指示了正在执行且第一时刻晚于第二时刻，将第二文件分发任务的第二任务执行状态信息更新为表征跳过执行的忽略状态。

根据本公开的实施例，在第一文件分发任务和第二文件分发任务的状态均为waiting的情况下，可以首先根据第一时刻和第二时刻，将最新(及第一时刻)生成的第一文件分发任务的状态更新为running。然后，可以将将第二文件分发任务的状态更新为ignored。

通过本公开的上述实施例，可以避免重复执行，并可有效减少文件传输错误的情况发生。此外，

根据本公开的实施例，对应于上述规则三，上述根据针对同一个文件分发任务组定义的预设规则，确定同一个文件分发任务组中文件分发任务的任务执行状态还可以包括：响应于确定第一任务执行状态信息指示了执行成功，将第二任务执行状态信息更新为执行成功。响应于确定第一任务执行状态信息指示了执行失败，将第二任务执行状态信息更新为执行失败。

图6示意性示出了根据本公开实施例的单个文件分发任务或文件分发任务组中任务的任务状态转换图。

如图6所示，init可以表征每个文件分发任务生成后的初始状态。基于TaskExecutor获取任务的操作，可以由TaskExecutor领取到文件分发任务，此时文件分发任务的状态可以更新为waiting。

在以waiting状态的文件分发任务创建有一个文件分发任务组group，且TaskExecutor判断group内有更新的task的情况下，可以将该waiting状态的文件分发任务的状态更新为ignored。

基于TaskExecutor调度执行的操作，可以启动文件分发任务，此时该waiting状态的文件分发任务的状态可以被更新为running。

在running状态的文件分发任务执行成功的情况下，该running状态的文件分发任务的状态可以被更新为done。

在running状态的文件分发任务执行失败或者超时的情况下，该running状态的文件分发任务的状态可以被更新为fail。

在TaskExecutor判断failed状态的文件分发任务的重试次数已用完的情况下，该failed状态的文件分发任务的状态可以被更新为faildone。

在TaskExecutor判断fail状态的文件分发任务的重试次数未用完的情况下，该failed状态的文件分发任务的状态可以被更新为waiting。

在TaskExecutor判断group内存在更新的task(任务)的情况下，该fail状态的文件分发任务的状态可以被更新为ignored。

通过本公开的上述实施例，通过引入新的文件分发任务状态ignored和文件分发任务组的概念，结合预设规则的处理，可以解决文件分发任务互斥的问题，ignored机制的引入可以有效提升热点路径的文件分发性能，特别是在节点宕机恢复时的场景，可有效提升该场景下的文件分发性能。

根据本公开的实施例，本公开的上述文件传输方法可应用于业务运维大规模集群场景，包括在集群上批量安装软件、更新服务、分发配置等。可以有效地提升此类场景下的执行效率，最大化利用集群资源减少执行时间。

图7示意性示出了根据本公开实施例的文件传输装置的框图。

如图7所示，文件传输装置700包括任务信息获取模块710和文件发送模块720。

任务信息获取模块710，用于响应于确定集群的目标节点已获得待传输文件，获取针对目标节点配置的目标文件分发任务的信息，集群还包括目标节点的下游节点，目标文件分发任务的信息包括下游节点的下游节点标识。

文件发送模块720，用于响应于接收到用于执行目标文件分发任务的第一执行指令，根据下游节点标识，将待传输文件发送至下游节点。

根据本公开的实施例，文件传输装置还包括状态确定模块和状态信息发送模块。

状态确定模块，用于响应于确定当前时刻到达预定义时刻，确定目标文件分发任务的目标任务执行状态信息。

状态信息发送模块，用于将目标任务执行状态信息发送至与集群的各个节点相连接的第一外部存储单元，以通过第一外部存储单元将目标任务执行状态信息发送至集群的各个节点。

根据本公开的实施例，目标文件分发任务包括在多个时刻生成的多个文件分发任务。状态确定模块包括任务组分配子模块和状态确定子模块。

任务组分配子模块，用于根据多个文件分发任务各自的任务执行路径信息，将任务执行路径相同的文件分发任务分配至同一个文件分发任务组。

状态确定子模块，用于根据针对同一个文件分发任务组定义的预设规则，确定同一个文件分发任务组中文件分发任务的任务执行状态，预设规则为根据互斥机制定义的规则。

根据本公开的实施例，预设规则包括：同一个文件分发任务组中最多一个文件分发任务的任务执行状态信息指示了正在执行。

根据本公开的实施例，同一个文件分发任务组包括在第一时刻生成的第一文件分发任务以及在第二时刻生成的第二文件分发任务。状态确定子模块包括第一状态更新单元。

第一状态更新单元，用于响应于确定第一文件分发任务的第一任务执行状态信息指示了正在执行且第一时刻晚于第二时刻，将第二文件分发任务的第二任务执行状态信息更新为表征跳过执行的忽略状态。

根据本公开的实施例，状态确定子模块还包括第二状态更新单元和第三状态更新单元。

第二状态更新单元，用于响应于确定第一任务执行状态信息指示了执行成功，将第二任务执行状态信息更新为执行成功；以及

第三状态更新单元，用于响应于确定第一任务执行状态信息指示了执行失败，将第二任务执行状态信息更新为执行失败。

根据本公开的实施例，集群还包括目标节点的上游节点。状态确定模块包括上游状态获取子模块、上游状态读取子模块和第一状态更新子模块。

上游状态获取子模块，用于获取针对上游节点配置的上游文件分发任务的上游任务执行状态信息。

上游状态读取子模块，用于响应于确定上游任务执行状态信息指示了未执行完成，在预设时间间隔之后再次读取上游任务执行状态信息。

第一状态更新子模块，用于响应于确定上游任务执行状态信息指示了执行成功，将目标任务执行状态信息更新为正在执行。

根据本公开的实施例，状态确定模块还包括第二状态更新子模块。

第二状态更新子模块，用于响应于确定上游任务执行状态信息指示了执行失败，将目标任务执行状态信息更新为执行失败。

根据本公开的实施例，状态确定模块包括第三状态更新子模块。

第三状态更新子模块，用于响应于确定目标文件分发任务的重试次数等于预设次数，将目标任务执行状态信息更新为执行失败。

根据本公开的实施例，文件传输装还包括第一重试子模块。

第一重试子模块，用于响应于确定目标文件分发任务执行失败，且确定重试次数小于预设次数，生成重新执行目标文件分发任务的第二执行指令，并将重试次数加1，重试次数的初始值为0。

根据本公开的实施例，文件传输装置还包括任务时长确定子模块和第二重试子模块。

任务时长确定子模块，用于根据目标文件分发任务的启动时刻和当前时刻，确定目标文件分发任务的单次执行时长。

第二重试子模块，用于响应于确定单次执行时长达到预设时长，且确定重试次数小于预设次数，生成重新执行目标文件分发任务的第三执行指令，并将重试次数加1。

根据本公开的实施例，文件传输装置还包括任务生成模块和任务信息发送模块。

任务生成模块，用于响应于接收到表征向集群分发待传输文件的文件传输指令，根据文件传输指令所表征的文件传输信息，生成目标文件分发任务。

任务信息发送模块，用于将目标文件分发任务的信息发送至与集群的各个节点相连接的第二外部存储单元，以通过第二外部存储单元将目标文件分发任务的信息发送至集群的节点。

根据本公开的实施例，集群包括第一节点和第二节点，文件传输信息包括第一节点的第一节点标识和第二节点的第二节点标识。任务生成模块包括第一任务生成子模块。

第一任务生成子模块，用于根据第一节点标识和第二节点标识，生成以第一节点为源节点、以第二节点为目的节点的目标文件分发任务。

根据本公开的实施例，文件传输信息还包括待传输文件的目标存储地址。任务生成模块还包括第二任务生成子模块。

第二任务生成子模块，用于根据第一节点标识、第二节点标识和目标存储地址，生成以第一节点为源节点、以第二节点为目的节点、以第二节点中的目标存储地址为待传输文件的文件存储地址的目标文件分发任务。

根据本公开的实施例，任务信息发送模块包括任务信息发送子模块。

任务信息发送子模块，用于根据目标文件分发任务的源节点的源节点标识，将目标文件分发任务发送至与源节点标识相对应的节点。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

根据本公开的实施例，一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行本公开的文件传输方法。

根据本公开的实施例，一种存储有计算机指令的非瞬时计算机可读存储介质，其中，计算机指令用于使计算机执行本公开的文件传输方法。

根据本公开的实施例，一种计算机程序产品，包括计算机程序，计算机程序存储于可读存储介质和电子设备其中至少之一上，计算机程序在被处理器执行时实现本公开的文件传输方法。

图8示出了可以用来实施本公开的实施例的示例电子设备800的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图8所示，设备800包括计算单元801，其可以根据存储在只读存储器(ROM)802中的计算机程序或者从存储单元808加载到随机访问存储器(RAM)803中的计算机程序，来执行各种适当的动作和处理。在RAM 803中，还可存储设备800操作所需的各种程序和数据。计算单元801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

设备800中的多个部件连接至输入/输出(I/O)接口805，包括：输入单元806，例如键盘、鼠标等；输出单元807，例如各种类型的显示器、扬声器等；存储单元808，例如磁盘、光盘等；以及通信单元809，例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理，例如文件传输方法。例如，在一些实施例中，文件传输方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元808。在一些实施例中，计算机程序的部分或者全部可以经由ROM 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序加载到RAM 803并由计算单元801执行时，可以执行上文描述的文件传输方法的一个或多个步骤。备选地，在其他实施例中，计算单元801可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行文件传输方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以是分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。