CN111552663A - 文件一致性验证方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请实施例属于计算机技术领域，涉及一种文件一致性验证方法，包括接收文件验证指令，根据文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；根据组件名获取所述组件对应的至少一个服务器的服务器名，基于服务器名发送文件下载指令至各服务器；在接收到各服务器发送的待验证文件时，对待验证文件进行区别命名，保存为目标待验证文件；根据迭代对比对各目标待验证文件的一致性进行验证。本申请还提供一种文件一致性验证装置、计算机设备及存储介质。本申请实现了对异常文件的快速查询，以及对linux系统下文件一致性的自动化验证，提高了系统文件一致性验证的效率。

Description

文件一致性验证方法、装置、计算机设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种文件一致性验证方法、装置、计算机设备及存储介质。

背景技术

现有技术中，需要更多的主机应用支撑每天的高并发业务量，如何检查大量主机应用上面的文件一致性成为了难题，主机应用的配置文件不一致，会出现上线后服务异常，因为涉及的主机太多，手工一台一台去检查显然不能满足业务要求，时效性也很差。

目前业务文件对比的工具也很多，但是都是基于windows系统的，而且需要手工选择文件，且大都只能基于两个文件的对比，而目前线上的业务系统都是linux系统，几乎业内没有针对验证这种分布式配置文件的工具，必须引入一种可以验证配置文件一致性的方案linux系统自身就有验证文件一致性的功能，但是也是针对两个文件之间的比较，目前业务系统的应用数量有的已经达到了上百个，也就是说需要同时对比上百个文件的一致性，这显然是linux系统本身无法完成的。

linux系统本身diff命令只能对比两个文件直接的差异，而且现有的技术中md5对比方式，每次在进行对比时，需要人工把所有需要进行对比的文件名进行后台输入，这种对比方法较为繁琐，耗费人力物力。

发明内容

本申请实施例的目的在于提出一种文件一致性验证方法、装置、计算机设备及存储介质，旨在解决当前Linux下无法对多个文件的一致性进行高效验证的技术问题。

为了解决上述技术问题，本申请实施例提供一种文件一致性验证方法，采用了如下所述的技术方案：

一种文件一致性验证方法，应用于linux系统，包括以下步骤：

接收文件验证指令，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；

根据所述组件名获取所述组件对应的至少一个服务器的服务器名，基于所述服务器名发送文件下载指令至各所述服务器，以使各所述服务器根据所述文件名下载所述待验证文件；

在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件；

根据迭代对比对各所述目标待验证文件的一致性进行验证，其中，在所述目标待验证文件的一致性验证通过时，确定所述待验证文件的一致性验证通过。

进一步的，所述根据迭代对比对各所述目标待验证文件的一致性进行验证的步骤包括：

对所述目标待验证文件进行统一格式转换，获取格式转换后的目标待验证文件的文件内容，其中，若来自不同所述服务器的所述文件内容相同，确定不同所述服务器分别对应的目标待验证文件一致。

进一步的，在所述接收文件验证指令之前，所述文件一致性验证方法还包括：

验证所述文件验证指令的格式是否符合预设要求；

在所述文件验证指令的格式符合所述预设要求时，接收所述文件验证指令。

进一步的，所述根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名的步骤包括：

对所述文件验证指令进行字符串拆分，确定所述文件验证指令的第三个字符串为组件名，所述文件验证指令的第四个字符串为待验证文件的文件名。

进一步的，所述根据所述组件名获取所述组件对应的至少一个服务器的服务器名的步骤包括：

获取Linux系统中组件的部署记录表；

基于所述部署记录表验证所述组件名，其中，在所述组件名验证通过时，根据所述部署记录表，获取所述组件对应的至少一个服务器的服务器名。

进一步的，所述在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件的步骤之前，所述文件一致性验证方法还包括：

根据远程下载工具，获取不同所述服务器的配置信息；

根据所述配置信息，从所述服务器上批量获取所述待验证文件。

进一步的，所述对所述待验证文件进行区别命名，保存为目标待验证文件的步骤包括：

获取不同的所述服务器的IP地址信息，将所述IP地址信息作为所述待验证文件的新文件名，保存所述新文件名的待验证文件为目标待验证文件。

一种文件一致性验证装置，包括：

解析模块，用于接收文件验证指令，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；

获取模块，用于根据所述组件名获取所述组件对应的至少一个服务器的服务器名，基于所述服务器名发送文件下载指令至各所述服务器，以使各所述服务器根据所述文件名下载所述待验证文件；

命名模块，用于在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件；

验证模块，用于根据迭代对比对各所述目标待验证文件的一致性进行验证，其中，在所述目标待验证文件的一致性验证通过时，确定所述待验证文件的一致性验证通过。

为了解决上述技术问题，本申请实施例还提供一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器及所述存储介质执行所述计算机可读指令时，实现如上所述的文件一致性验证方法的步骤。

为了解决上述技术问题，本申请实施例还提供一种计算机存储介质，所述计算机存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如上所述的文件一致性验证方法的步骤。

上述文件一致性验证方法、装置、计算机设备及存储介质，通过接收文件验证指令，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；由于在对文件进行一致性认证时，需要对从各个不同服务器获取到的文件进行一致性的认证，因此，在获取到文件名和组件名时，根据所述组件名获取所述组件对应的至少一个服务器的服务器名，基于所述服务器名发送文件下载指令至各所述服务器，以使各所述服务器根据所述文件名下载所述待验证文件；在服务器下载待验证文件完成时，服务器则发送待验证文件至验证的系统，验证系统在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件；不同的服务器发送的待验证文件可能不一样，因此则需要对从不同服务器接收到的待验证文件进行区别命名。而后根据迭代对比对各所述目标待验证文件的一致性进行验证，其中，在所述目标待验证文件的一致性验证通过时，确定所述待验证文件的一致性验证通过，解决了当前Linux下无法对多个文件的一致性进行高效验证的技术问题。

附图说明

为了更清楚地说明本申请中的方案，下面将对本申请实施例描述中所需要使用的附图作一个简单介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请可以应用于其中的示例性系统架构图；

图2为文件一致性验证方法的流程示意图；

图3为图2中步骤S500的细化流程示意图；

图4为图2中步骤S200之前的流程示意图；

图5为图2中步骤S300的细化流程示意图；

图6为图2中步骤S400之前的流程示意图；

图7是根据本申请的文件一致性验证装置的一个实施例的结构示意图；

图8是根据本申请的计算机设备的一个实施例的结构示意图。

附图标记：1000文件一致性验证装置；1100解析模块；1200获取模块；1300命名模块；1400验证模块。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

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

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

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture ExpertsGroup Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving PictureExperts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的文件一致性验证方法一般由服务端/终端执行，相应地，文件一致性验证装置一般设置于服务端/终端设备中。

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

继续参考图2，示出了根据本申请的文件一致性验证方法的一个实施例的流程图。所述文件一致性验证方法，应用于linux系统，包括以下步骤：

步骤S200，接收文件验证指令，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；

该文件验证指令为用户自定义的diff命令，包括至少两个参数，参数一为组件名，即系统名，参数二为待验证文件的文件名，用来确定待进行验证的系统和文件。具体的指令格式为“sh compare组件名文件名”，如组件名为lcloud_ark_rgp，文件名为bootstrap.properties，则该linux命令为sh compare lcloud_ark_rgpbootstrap.properties。在接收到该文件验证指令时，解析该文件验证指令即可得到该文件指令中所包括的组件名和待验证文件的文件名。

步骤S300，根据所述组件名获取所述组件对应的至少一个服务器的服务器名，基于所述服务器名发送文件下载指令至各所述服务器，以使各所述服务器根据所述文件名下载所述待验证文件；

在得到组件名时，根据该组件名可以获取到对应的服务器名，其中，同一组件名下可包括多个不同的服务器名。根据该服务器名，可以将文件下载指令发送至同一组件名下的不同服务器上。在不同的服务器接收到该文件下载指令时，则根据该文件下载指令携带的待验证文件的文件名下载对应的待验证文件。该待验证文件即为不同服务器根据文件下载指令下载文件名对应的验证文件。

步骤S400，在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件；

在不同的服务器对该待验证文件下载完成时，则将该待验证文件发送至当前验证系统。当前验证系统在接收到不同服务器发送的待验证文件时，则将该待验证文件进行区别命名。其中，该区别命名即为对该待验证文件的名称进行修改，修改名称后的待验证文件即为目标待验证文件。

步骤S500，根据迭代对比对各所述目标待验证文件的一致性进行验证，其中，在所述目标待验证文件的一致性验证通过时，确定所述待验证文件的一致性验证通过。

在获取到目标待验证文件时，则对该目标待验证文件的一致性进行验证，具体地，该目标待验证文件可通过迭代对比的方式进行验证；若来自不同服务器的目标待验证文件的文件内容完全一致，则确定该来自不同服务器的目标待验证文件一致；若来自不同服务器的目标待验证文件的文件内容不完全一致，则确定该来自不同服务器的目标待验证文件不一致。在该目标待验证文件验证一致时，则确定待验证文件一致。

其中，以IP命名文件进行对比为例，具体的迭代对比方式如下：

1)中央处理器判断进行迭代的文件数量N；

2)中央处理器中生成文件数量N-1组对比列；

3)文件192.225.1.86，文件192.210.1.86，文件192.225.1.33，文件192.100.1.110，文件192.201.1.130进行对比；

4)每组对比列进行对比：

如对比列1以文件192.225.1.86为基准文件进行4轮对比，如下：

文件192.225.1.86和文件192.210.1.86，

文件192.225.1.86和文件192.225.1.33，

文件192.225.1.86和文件192.100.1.110，

文件192.225.1.86和文件192.201.1.130；

对比列2会以文件192.210.1.86为基准文件进行3轮对比，如下：

文件192.210.1.86和文件192.225.1.33，

文件192.210.1.86和文件192.100.1.110，

文件192.210.1.86和文件192.201.1.130；

以此类推，会产生N-1组对比列，每组的基准对比文件为该对比列的第一个文件。

每轮两个文件会进行文件的逐行对比，将不一致的行的行号、内容进行输出；由此，在对目标待验证文件进行迭代对比时，以任意一个目标待验证文件为基准对比文件，均可以快速确定与该基准对比文件不同的目标待验证文件，以对不同的目标待验证文件对应的服务器中的文件进行校正或者执行其他操作。

在本实施例中，实现了对异常文件的快速查询，以及对linux系统下文件一致性的自动化验证，使得在linux系统下对文件进行一致性验证时，能够同时验证上百个数量级的文件，节省了消耗，提高了系统文件一致性验证的效率。

在本申请的一些实施例中，如图3所示，步骤S500，根据迭代对比对各所述目标待验证文件的一致性进行验证包括：

步骤S510，对所述目标待验证文件进行统一格式转换，获取格式转换后的目标待验证文件的文件内容，其中，若来自不同所述服务器的所述文件内容相同，确定不同所述服务器分别对应的目标待验证文件一致。

在对待验证文件区别命名完成时，即获取到来自不同服务器的目标待验证文件时，对该目标待验证文件进行统一格式转换，即将不同服务器的目标待验证文件转换为统一的格式，如统一格式转换为ASCII。在该目标待验证文件格式转换后，获取该目标待验证文件转换后的文件内容；对比来自不同服务器的目标待验证文件的文件内容，若来自不同服务器的文件内容一致，则确定该来自不同服务器的目标待验证文件相同；若来自不同服务器的文件内容不一致，则确定该来自不同服务器的目标待验证文件不同，记录该目标待验证文件的不同内容所在行，输出形式为diff对比格式0a1，1c3等，其中0a1为第一行内容不同，1c3为第三行内容不同。

例如，对比目标待验证文件192.225.1.86和目标待验证文件192.225.1.33，将192.225.1.86中的内容全部转化为ASCII格式的文件内容，将192.225.1.33中的内容全部转化为ASCII格式的文件内容，逐行对比该两个目标待验证文件的文件内容。

在本实施例中，实现了对来自不同服务器的目标待验证文件的一致性验证，提高了对异常文件的查询速度，进一步地实现了对文件一致性的高效自动验证。

在本申请的一些实施例中，如图4所示，步骤S200，在所述接收文件验证指令之前，所述文件一致性验证方法还包括：

步骤S600，验证所述文件验证指令的格式是否符合预设要求；

步骤S700，在所述文件验证指令的格式符合所述预设要求时，接收所述文件验证指令。

接收用户输入文件验证指令，确定该文件验证指令的格式是否符合预设要求，在该格式符合预设要求时，则接收该文件验证指令。例如，在该预设要求为sh compare A B格式时，则根据该sh compare A B格式对输入的文件验证指令进行格式判断；若输入的文件验证指令满足sh compare AB格式，则确定该文件验证指令满足预设要求；若输入的文件验证指令为非sh compare A B格式，则提醒用户按正确的格式要求输入。

在本实施例中，实现了对文件验证指令的格式的验证，避免了格式错误的文件验证指令的输入而导致的资源浪费。

在本申请的一些实施例中，步骤S200，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名包括：

对所述文件验证指令进行字符串拆分，确定所述文件验证指令的第三个字符串为组件名，所述文件验证指令的第四个字符串为待验证文件的文件名。

在接收到文件验证指令时，对该文件验证指令进行解析，得到组件名和待验证文件的文件名。其中，该文件验证指令的具体解析方式为，将接收到的文件验证指令按照预设规则进行拆分，如按照空格将该文件验证指令拆分为不同字符串长度的内容。以接收到文件验证指令为sh compare A B为例，将该文件验证指令sh compare A B按照空格进行拆分，拆分为4个短字符串[sh][compare][A][B]；解析出第三个字符串A为组件名，解析出第四个字符串B为待验证文件的文件名。

在本实施例中，实现了对文件验证指令的解析，使得通过解析能够快速得到对应的组件名和待验证文件的文件名。

在本申请的一些实施例中，如图5所示，步骤S300，根据所述组件名获取所述组件对应的至少一个服务器的服务器名包括：

步骤S310，获取Linux系统中组件的部署记录表；

步骤S320，基于所述部署记录表验证所述组件名，其中，在所述组件名验证通过时，根据所述部署记录表，获取所述组件对应的至少一个服务器的服务器名。

在解析到组件名时，根据部署记录表可以对该组件名进行验证。具体的验证方式为，若部署记录表中记录的组件名与该解析出的组件名相同，则确定该组件名存在，则对该组件名下的不同服务器名进行获取；若部署记录表中记录的组件名与该解析出的组件名都不相同，则发送组件名有误提示。

其中，该组件名对应的组件中包括了多个服务器，在对该组件名验证通过时，则通过该组件名获取该组件名下的不同服务器名，由此获取到同一组件名下的不同服务器。例如：待验证文件A包括组件名分别为A1，A2，A3，A4，A5的组件；A1组件下包括服务器名分别为1，2，3，4的服务器；A2组件下包括服务器名分别为5，6，7，8的服务器；A3组件下包括服务器名分别为3，4，7，8的服务器；A4组件下包括服务器名分别为5，6，7，8，9的服务器；A5组件下包括服务器名分别为1，2，7，8，9的服务器。

在本实施例中，实现了对组件名的验证，从而通过该组件名对服务器进行获取，并让不同的服务器对待验证文件进行下载，进一步地实现对不同服务器的文件一致性的高效验证。

在本申请的一些实施例中，如图6所示，步骤S400，在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件的步骤之前，所述文件一致性验证方法还包括：

步骤S800，根据远程下载工具，获取不同所述服务器的配置信息；

步骤S900，根据所述配置信息，从所述服务器上批量获取所述待验证文件。

在服务器下载到待验证文件的文件名对应的待验证文件时，验证系统则会通过远程下载工具从不同的服务器中获取该待验证文件。以该远程下载工具为ansible为例，在验证系统对该待验证文件C进行下载前，则会对该待验证文件C进行验证，若该待验证文件C存在，则进行下载；若该待验证文件C不存在，在验证机上生成该待验证文件C，其中内容为空。在验证系统通过远程下载工具对待验证文件进行下载时，该远程下载工具能够自动从远程服务器上获取服务器的硬件信息和IP地址信息；例如，ansible的setup模块能从远程服务器上自动获取服务器的硬件信息和服务器ipv4地址。因此，在通过远程下载工具对不同的服务器的待验证文件进行下载时，通过该远程下载工具的模块可以确定不同服务器的配置信息，该配置信息则包括该服务器的硬件信息和IP地址信息；根据该配置信息则可以获取到该服务器已经下载的待验证文件。

在本实施例中，实现了系统通过远程下载工具，对不同服务器下载的第一待验证文件的批量获取，使得系统能够同时批量远程获取到第一待验证文件，进一步地提高了系统对文件一致性的验证效率。

在本申请的一些实施例中，步骤S400，对所述待验证文件进行区别命名，保存为目标待验证文件包括：

获取不同的所述服务器的IP地址信息，将所述IP地址信息作为所述待验证文件的新文件名，保存所述新文件名的待验证文件为目标待验证文件。

目标待验证文件为与待验证文件区别命名的待验证文件，其内容与待验证文件相同；在接收到服务器发送的待验证文件时，则对该待验证文件进行区别命名。具体地，该区别命名的方式可以为，将不同服务器的IP地址信息作为该待验证文件的新文件名；亦可以为将不同服务器的IP地址信息进行加密，获取加密后的文字信息，将该文字信息作为该待验证文件的新文件名；其中，该加密方式可以为md5加密的方式。

例如，通过IP地址信息进行区别命名：A5组件下服务器1，2，7，8，9，已经下载过待验证文件B。此时，待验证文件的文件名称都为B，为了便于识别，对从不同服务器上下载的待验证文件B进行IP地址信息的区别命名，即：服务器1对应待验证文件B，命名为192.225.1.86的目标待验证文件；服务器2对应待验证文件B，命名为192.210.1.86的目标待验证文件；依次命名。

通过md5加密的方式进行区别命名：A5组件下服务器1，2，7，8，9，已经下载过待验证文件B。此时，待验证文件的文件名称都为B，为了便于识别，对从不同服务器上下载的待验证文件B进行md5加密的区别命名，即：待验证文件的文件名称B和IP地址信息进行字符串拼接，在经过md5加密算法进行加密。服务器1对应待验证文件B，字符串拼接后为B192.225.1.86，经md5加密为da3bf238b14a0663，该服务器对应的目标待验证文件即为文件名称为da3bf238b14a0663的待验证文件。

在本实施例中，实现了对不同服务器的待验证文件的区别命名，使得通过该名称能够明确及时地确定接收到的待验证文件的来源。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

进一步参考图7，作为对上述图2所示方法的实现，本申请提供了一种文件一致性验证装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图7所示，本实施例所述的文件一致性验证装置1000包括：

解析模块1100，用于接收文件验证指令，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；

其中，所述解析模块包括：

拆分单元，对所述文件验证指令进行字符串拆分，确定所述文件验证指令的第三个字符串为组件名，所述文件验证指令的第四个字符串为待验证文件的文件名。

所述解析模块之前，所述文件一致性验证装置还包括：

第一验证单元，用于验证所述文件验证指令的格式是否符合预设要求；

接收单元，用于在所述文件验证指令的格式符合所述预设要求时，接收所述文件验证指令。

接收用户输入文件验证指令，确定该文件验证指令的格式是否符合预设要求，在该格式符合预设要求时，则接收该文件验证指令。例如，在该预设要求为sh compare A B格式时，则根据该sh compare A B格式对输入的文件验证指令进行格式判断；若输入的文件验证指令满足sh compare A B格式，则确定该文件验证指令满足预设要求；若输入的文件验证指令为非sh compare A B格式，则提醒用户按正确的格式要求输入。

该文件验证指令为用户自定义的diff命令，包括至少两个参数，参数一为组件名，即系统名，参数二为待验证文件的文件名，用来确定待进行验证的系统和文件。具体的指令格式为“sh compare组件名文件名”，如组件名为lcloud_ark_rgp，文件名为bootstrap.properties，则该linux命令为sh compare lcloud_ark_rgpbootstrap.properties。在接收到该文件验证指令时，解析该文件验证指令即可得到该文件指令中所包括的组件名和待验证文件的文件名。

获取模块1200，用于根据所述组件名获取所述组件对应的至少一个服务器的服务器名，基于所述服务器名发送文件下载指令至各所述服务器，以使各所述服务器根据所述文件名下载所述待验证文件；

其中，所述获取模块包括：

第一获取单元，用于获取Linux系统中组件的部署记录表；

第二验证单元，用于基于所述部署记录表验证所述组件名，其中，在所述组件名验证通过时，根据所述部署记录表，获取所述组件对应的至少一个服务器的服务器名。

在得到组件名时，根据该组件名可以获取到对应的服务器名，其中，同一组件名下可包括多个不同的服务器名。根据该服务器名，可以将文件下载指令发送至同一组件名下的不同服务器上。在不同的服务器接收到该文件下载指令时，则根据该文件下载指令携带的待验证文件的文件名下载对应的待验证文件。该待验证文件即为不同服务器根据文件下载指令下载文件名对应的验证文件。

命名模块1300，用于在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件；

其中，所述命名模块包括：

保存单元，用于获取不同的所述服务器的IP地址信息，将所述IP地址信息作为所述待验证文件的新文件名，保存所述新文件名的待验证文件为目标待验证文件。

在不同的服务器对该待验证文件下载完成时，则将该待验证文件发送至当前验证系统。当前验证系统在接收到不同服务器发送的待验证文件时，则将该待验证文件进行区别命名。其中，该区别命名即为对该待验证文件的名称进行修改，修改名称后的待验证文件即为目标待验证文件。

所述命名模块之前，所述文件一致性验证装置还包括：

第二获取单元，用于根据远程下载工具，获取不同所述服务器的配置信息：

第三获取单元，用于根据所述配置信息，从所述服务器上批量获取所述待验证文件。

在服务器下载到待验证文件的文件名对应的待验证文件时，验证系统则会通过远程下载工具从不同的服务器中获取该待验证文件。以该远程下载工具为ansible为例，在验证系统对该待验证文件C进行下载前，则会对该待验证文件C进行验证，若该待验证文件C存在，则进行下载；若该待验证文件C不存在，在验证机上生成该待验证文件C，其中内容为空。在验证系统通过远程下载工具对待验证文件进行下载时，该远程下载工具能够自动从远程服务器上获取服务器的硬件信息和IP地址信息；例如，ansible的setup模块能从远程服务器上自动获取服务器的硬件信息和服务器ipv4地址。因此，在通过远程下载工具对不同的服务器的待验证文件进行下载时，通过该远程下载工具的模块可以确定不同服务器的配置信息，该配置信息则包括该服务器的硬件信息和IP地址信息；根据该配置信息则可以获取到该服务器已经下载的待验证文件。

验证模块1400，用于根据迭代对比对各所述目标待验证文件的一致性进行验证，其中，在所述目标待验证文件的一致性验证通过时，确定所述待验证文件的一致性验证通过。

其中，所述验证模块包括：

格式转化单元，用于对所述目标待验证文件进行统一格式转换，获取格式转换后的目标待验证文件的文件内容，其中，若来自不同所述服务器的所述文件内容相同，确定不同所述服务器分别对应的目标待验证文件一致。

在获取到目标待验证文件时，则对该目标待验证文件的一致性进行验证，具体地，该目标待验证文件可通过迭代对比的方式进行验证；若来自不同服务器的目标待验证文件的文件内容完全一致，则确定该来自不同服务器的目标待验证文件一致；若来自不同服务器的目标待验证文件的文件内容不完全一致，则确定该来自不同服务器的目标待验证文件不一致。在该目标待验证文件验证一致时，则确定待验证文件一致。

其中，以IP命名文件进行对比为例，具体的迭代对比方式如下：

1)中央处理器判断进行迭代的文件数量N；

2)中央处理器中生成文件数量N-1组对比列；

3)文件192.225.1.86，文件192.210.1.86，文件192.225.1.33，文件192.100.1.110，文件192.201.1.130进行对比；

4)每组对比列进行对比：

如对比列1以文件192.225.1.86为基准文件进行4轮对比，如下：

文件192.225.1.86和文件192.210.1.86，

文件192.225.1.86和文件192.225.1.33，

文件192.225.1.86和文件192.100.1.110，

文件192.225.1.86和文件192.201.1.130；

对比列2会以文件192.210.1.86为基准文件进行3轮对比，如下：

文件192.210.1.86和文件192.225.1.33，

文件192.210.1.86和文件192.100.1.110，

文件192.210.1.86和文件192.201.1.130；

以此类推，会产生N-1组对比列，每组的基准对比文件为该对比列的第一个文件。

每轮两个文件会进行文件的逐行对比，将不一致的行的行号、内容进行输出；由此，在对目标待验证文件进行迭代对比时，以任意一个目标待验证文件为基准对比文件，均可以快速确定与该基准对比文件不同的目标待验证文件，以对不同的目标待验证文件对应的服务器中的文件进行校正或者执行其他操作。

在对待验证文件区别命名完成时，即获取到来自不同服务器的目标待验证文件时，对该目标待验证文件进行统一格式转换，即将不同服务器的目标待验证文件转换为统一的格式，如统一格式转换为ASCII。在该目标待验证文件格式转换后，获取该目标待验证文件转换后的文件内容；对比来自不同服务器的目标待验证文件的文件内容，若来自不同服务器的文件内容一致，则确定该来自不同服务器的目标待验证文件相同；若来自不同服务器的文件内容不一致，则确定该来自不同服务器的目标待验证文件不同，记录该目标待验证文件的不同内容所在行，输出形式为diff对比格式0a1，1c3等，其中0a1为第一行内容不同，1c3为第三行内容不同。

例如，对比目标待验证文件192.225.1.86和目标待验证文件192.225.1.33，将192.225.1.86中的内容全部转化为ASCII格式的文件内容，将192.225.1.33中的内容全部转化为ASCII格式的文件内容，逐行对比该两个目标待验证文件的文件内容。

在本实施例中，实现了对异常文件的快速查询，以及对linux系统下文件一致性的自动化验证，使得在linux系统下对文件进行一致性验证时，能够同时验证上百个数量级的文件，节省了消耗，提高了系统文件一致性验证的效率。

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图8，图8为本实施例计算机设备基本结构框图。

所述计算机设备2000包括通过系统总线相互通信连接存储器2001、处理器2002、网络接口2003。需要指出的是，图中仅示出了具有组件2001-2003的计算机设备2000，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific lntegrated Circuit，ASIC)、可编程门阵列(Field-Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

所述存储器2001至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器2001可以是所述计算机设备2000的内部存储单元，例如该计算机设备2000的硬盘或内存。在另一些实施例中，所述存储器2001也可以是所述计算机设备2000的外部存储设备，例如该计算机设备2000上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。当然，所述存储器2001还可以既包括所述计算机设备2000的内部存储单元也包括其外部存储设备。本实施例中，所述存储器2001通常用于存储安装于所述计算机设备2000的操作系统和各类应用软件，例如文件一致性验证方法的程序代码等。此外，所述存储器2001还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器2002在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器2002通常用于控制所述计算机设备2000的总体操作。本实施例中，所述处理器2002用于运行所述存储器2001中存储的程序代码或者处理数据，例如运行所述文件一致性验证方法的程序代码。

所述网络接口2003可包括无线网络接口或有线网络接口，该网络接口2003通常用于在所述计算机设备2000与其他电子设备之间建立通信连接。

所述计算机设备实现了对异常文件的快速查询，以及对linux系统下文件一致性的自动化验证，使得在linux系统下对文件进行一致性验证时，能够同时验证上百个数量级的文件，节省了消耗，提高了系统文件一致性验证的效率。

本申请还提供了另一种实施方式，即提供一种计算机存储介质，所述存储介质可以为一种可读存储介质，所述计算机存储介质存储有文件一致性验证程序，所述文件一致性验证程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的文件一致性验证方法的步骤。

所述计算机存储介质实现了对异常文件的快速查询，以及对linux系统下文件一致性的自动化验证，使得在linux系统下对文件进行一致性验证时，能够同时验证上百个数量级的文件，节省了消耗，提高了系统文件一致性验证的效率。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims (10)

1.一种文件一致性验证方法，应用于Iinux系统，其特征在于，包括下述步骤：

接收文件验证指令，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；

根据所述组件名获取所述组件对应的至少一个服务器的服务器名，基于所述服务器名发送文件下载指令至各所述服务器，以使各所述服务器根据所述文件名下载所述待验证文件；

在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件；

根据迭代对比对各所述目标待验证文件的一致性进行验证，其中，在所述目标待验证文件的一致性验证通过时，确定所述待验证文件的一致性验证通过。

2.根据权利要求1所述的文件一致性验证方法，其特征在于，所述根据迭代对比对各所述目标待验证文件的一致性进行验证的步骤包括：

对所述目标待验证文件进行统一格式转换，获取格式转换后的目标待验证文件的文件内容，其中，若来自不同所述服务器的所述文件内容相同，确定不同所述服务器分别对应的目标待验证文件一致。

3.根据权利要求1或2所述的文件一致性验证方法，其特征在于，在所述接收文件验证指令之前，所述文件一致性验证方法还包括：

验证所述文件验证指令的格式是否符合预设要求；

在所述文件验证指令的格式符合所述预设要求时，接收所述文件验证指令。

4.根据权利要求1或2所述的文件一致性验证方法，其特征在于，所述根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名的步骤包括：

对所述文件验证指令进行字符串拆分，确定所述文件验证指令的第三个字符串为组件名，所述文件验证指令的第四个字符串为待验证文件的文件名。

5.根据权利要求1或2所述的文件一致性验证方法，其特征在于，所述根据所述组件名获取所述组件对应的至少一个服务器的服务器名的步骤包括：

获取Linux系统中组件的部署记录表；

基于所述部署记录表验证所述组件名，其中，在所述组件名验证通过时，根据所述部署记录表，获取所述组件对应的至少一个服务器的服务器名。

6.根据权利要求1或2所述的文件一致性验证方法，其特征在于，所述在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件的步骤之前，所述文件一致性验证方法还包括：

根据远程下载工具，获取不同所述服务器的配置信息；

根据所述配置信息，从所述服务器上批量获取所述待验证文件。

7.根据权利要求1或2所述的文件一致性验证方法，其特征在于，所述对所述待验证文件进行区别命名，保存为目标待验证文件的步骤包括：

获取不同的所述服务器的IP地址信息，将所述IP地址信息作为所述待验证文件的新文件名，保存所述新文件名的待验证文件为目标待验证文件。

8.一种文件一致性验证装置，其特征在于，包括：

解析模块，用于接收文件验证指令，根据所述文件验证指令解析得到需要进行文件验证的组件的组件名和待验证文件的文件名；

获取模块，用于根据所述组件名获取所述组件对应的至少一个服务器的服务器名，基于所述服务器名发送文件下载指令至各所述服务器，以使各所述服务器根据所述文件名下载所述待验证文件；

命名模块，用于在接收到各所述服务器发送的所述待验证文件时，对所述待验证文件进行区别命名，保存为目标待验证文件；

验证模块，用于根据迭代对比对各所述目标待验证文件的一致性进行验证，其中，在所述目标待验证文件的一致性验证通过时，确定所述待验证文件的一致性验证通过。

9.一种计算机设备，其特征在于，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述处理器及所述存储介质执行所述计算机可读指令时，实现如权利要求1至7中任一项所述的文件一致性验证方法的步骤。

10.一种计算机存储介质，其特征在于，所述计算机存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如权利要求1至7中任一项所述的文件一致性验证方法的步骤。

Images