CN114528343A - 商品数据管理方法、装置及服务器 - Google Patents

Abstract

本申请提供了商品数据管理方法、装置及服务器，适用于数据管理技术领域，该方法包括：获取商品数据，并将商品数据拆分为至少一个第一子文件，其中每个第一子文件中包含至少一个商品的属性数据；对各个第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库。本申请实施例大大降低了商品数据管理操作的技术门槛，可用性更高。同时对商品数据自动化的校验和数据存储，也极大地提升了对商品数据的管理效率。

Description

商品数据管理方法、装置及服务器

技术领域

本申请属于数据管理技术领域，尤其涉及商品数据管理方法、装置及服务器。

背景技术

电商已经成为了大众购物的一种主流手段。通过内容提供商(Content Provider，CP。CP可以是商家，也可以是商家以外的其他人员。)向商品管理系统提供商品数据，用户利用商品管理系统搜索商品的模式。可以实现对商品的快速曝光，进而为商家带来巨大的流量。

为了使得用户可以搜索商品，现有的商品管理系统需要CP提供结构化的商品数据。再由商品管理系统对这些结构化的商品数据进行存储，并提供商品搜索服务。但这种方式需要CP具备一定的数据操作能力，从而使得此过程的操作门槛较高。同时对于大多数CP而言，商品的数量往往较多。为了实现对这些商品结构化的商品数据提供，需要CP耗费大量的人力物力进行操作，因此使得商品数据提供的工作量往往较大。综上，现有技术对商品数据的管理效率较低，CP操作的门槛较高，不利于对商品数据的有效管理。

发明内容

有鉴于此，本申请实施例提供了商品数据管理方法、装置及服务器，可以解决现有技术中对商品数据管理效率较低的问题。

本申请实施例的第一方面提供了一种商品数据管理方法，应用于服务器，包括：

获取商品数据，并将商品数据拆分为至少一个第一子文件，其中每个第一子文件中包含至少一个商品的属性数据。

对各个第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库。

本申请实施例的数据管理过程中，CP只需按照格式要求提供商品数据，即可实现对商品数据的离线导入数据库。由于实际应用中CP原本就需要整理商品数据(无论是出于库存整理还是上架电商平台等目的，实际应用中CP一般都是需要整理商品数据的)，因此对CP而言，只需要将商品数据按照格式要求整理即可，无需付出过多额外的工作。商品管理系统在接收到商品数据之后，会对商品数据进行数据拆分，得到多个子文件(即第一子文件)。并会对各个子文件分别进行属性数据校验，以及校验通过的属性数据的上传。其中，服务器对各个子文件的校验，可以是串行处理或并行处理。当并行处理时，服务器可对多个子文件同时进行校验操作，从而提高校验的效率。

相对现有技术而言，本申请实施例大大降低了CP操作的技术门槛，可用性更高。同时对商品数据自动化的校验和数据存储，也极大地提升了对商品数据的管理效率。

在第一方面的第一种可能的实现方式中，对各个第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库，包括：

从至少一个第一子文件中选取出一个子文件作为第二子文件。

对第二子文件进行属性数据校验，并将第二子文件中校验通过的属性数据上传至数据库。

在完成对第二子文件的校验之后，返回执行从至少一个第一子文件中选取出一个子文件作为第二子文件的操作，直至所有第一子文件均被校验完成。

本申请实施例中，服务器会循环从这些第一子文件中选取各个子文件(即第二子文件)并进行处理，实现对各个第一子任务进行数据校验，并同步将子文件内的商品数据存储至数据库。使得入库的效率更高，实现了对商品数据的高效管理。

在第一方面第一种可能实现方式的基础上，作为第一方面的第二种可能的实现方式，在对第二子文件进行属性数据校验，并将第二子文件中校验通过的属性数据上传至数据库之前，还包括：

在数据库中创建与至少一个第一子文件一一对应的第一子任务。

对第二子文件进行属性数据校验，并将第二子文件中校验通过的属性数据上传至数据库，包括：

从数据库存储的第一子任务中确定出一个第二子任务，并从至少一个第一子文件中获取与第二子任务关联的第二子文件。

返回执行从至少一个第一子文件中选取出一个子文件作为第二子文件的操作，直至对所有第一子文件均校验完成，包括：返回执行从数据库存储的第一子任务中确定出一个第二子任务的操作，直至所有第一子任务均被执行完成。

在本申请实施例中，通过在数据库中创建与子文件一一对应的子任务(即第一子任务)，并以确定所需执行的子任务(即第二子任务)的形式实现对各个子文件的选取。从而使得本申请实施例中，数据库可以有效记录各个子文件的校验情况，同时服务器也可以方便确定出每次所需校验的子文件。

在第一方面第二种可能实现方式的基础上，作为第一方面的第三种可能的实现方式，从数据库存储的第一子任务中确定出一个第二子任务，包括：

获取第一子任务中待执行的子任务，待执行的子任务包括未执行的第一子任务，以及执行中且执行时长超出时长阈值的第一子任务。

从待执行的子任务中确定出第二子任务。

在本申请实施例中，会以子任务的执行状态为依据，来区分子任务是否为待执行子任务。考虑到实际应用中，一方面，未执行的子任务需要服务器进行处理。另一方面，实际应用中可能会存在服务器异常无法正常处理子任务的情况，例如服务器由于宕机等原因导致无法正常处理子任务。此时子任务虽然处于执行中，但已经无法执行完成。即使继续等待服务器，也无法完成对子任务的处理，无法实现对子文件的校验。因此需要由其他服务器重新处理这些子任务。基于上述两方面的考量。本申请实施例将未执行的子任务，以及执行中但执行时长超时的子任务，均视为待执行子任务。在此基础上，服务器会获取所有实时所有待执行子任务，并从中确定出所需执行的第二子任务。

在第一方面第三种可能实现方式的基础上，作为第一方面的第四种可能的实现方式，从待执行的子任务中确定出第二子任务，包括：

依次向缓存组件请求对各个待执行的子任务的分布式锁。

若请求到对单个待执行的子任务的分布式锁，将该待执行的子任务作为第二子任务。

作为本申请的一个可选实施例，为了提高对子任务的处理效率，可以采用多个服务器同时对各个子任务进行处理。此时作为第一方面各个方案的执行主体的服务器，也是对子任务进行处理的一个服务器。实际应用中发现，可能会出现多个服务器同时选取同一子任务进行处理的情况。此时会导致对商品数据的处理效率降低。为了防止单个子任务同时被多个服务器重复处理，在本申请实施例中，服务器在接收到待执行子任务之后，首先会从中选取出一个子任务，并尝试向缓存组件申请对该子任务的分布式锁。由于单个子任务的分布式锁仅能分配给单个服务器。因此若该子任务未被其他服务器处理，理论上此时可以获取到对该子任务的分布式锁。反之若该子任务已经被其他服务器处理，基于执行前需要申请分布式锁的原则。此时缓存组件内会记录该子任务已被其他服务器申请分布式锁。因此此时会无法成功获取子任务的分布式锁。基于这一原理，在获取到分布式锁完成上锁的操作后，服务器会判定该子任务为此次所需执行的子任务。并会下载对应的子文件。反之，若获取分布式锁失败，则会重新执行子任务选取的操作，以重新选取适宜的子任务。

在第一方面第四种可能实现方式的基础上，作为第一方面的第五种可能的实现方式，在对第二子文件进行属性数据校验的过程中，还包括：

判断对第二子文件的校验时长是否达到时长阈值。

若对第二子文件的校验时长达到时长阈值，则释放对第二子文件的分布式锁。

为了防止服务器出现故障，导致子任务被自身长时间占据，使得对子任务执行效率降低。服务器会自行统计对子任务的校验时长，并判断是否达到时长阈值。若达到，则说明自身对子任务校验超时，可能是自身出现故障。因此此时会释放对子文件的分布式锁，从而使得其他服务器可以执行该子任务。实现了对子任务的自动节点接管。进而使得对子任务执行的可靠性大大增强。

在第一方面第一种至第五种可能实现方式的基础上，作为第一方面的第六种可能的实现方式，若商品数据中存在校验失败的属性数据，则获取校验失败的属性数据的异常信息，并将异常信息存储至数据库。

本申请实施例会对解析出的属性数据进行合法性校验。即判断各个属性数据是否存在数据缺失或者数据错误等问题。当存在这些问题时，说明对这些属性数据校验失败。此时本申请实施例会将数据解析异常对应的异常信息上传至数据库。由数据对异常信息进行记录。在此基础上，可以将这些异常信息反馈至CP，或者由CP自行查询。从而使得CP可以快速或者哪些数据存在问题，并可以进行针对性的检查和重新入库。进而提高了对商品数据入库的效率。

在第一方面第一种至第六种可能实现方式的基础上，作为第一方面的第七种可能的实现方式，商品数据为数据表格式的数据。

在本申请实施例中，设定商品数据的格式为数据表格式。由于数据表格式是一种常用的数据记录格式，而是许多CP日常整理商品数据时使用的格式。因此对于CP而言，若要求商品数据以数据表格式提供，CP仅需对原本的商品数据进行简单的整理，即可得到商品管理系统所需的商品数据。从而使得对CP的技术门槛以及工作量要求大幅度降低，进而提高了对商品数据管理的效率。

在第一方面第一种至第七种可能实现方式的基础上，作为第一方面的第八种可能的实现方式，将第二子文件中的属性数据上传至数据库，包括：

在对第二子文件进行属性数据校验的过程中，将第二子文件中校验通过的属性数据上传至数据库。或者

在对第二子文件进行属性数据校验完成后，将第二子文件中校验通过的属性数据上传至数据库。

在本申请实施例中，提供了两种商品属性数据校验入库的方案：

方案1：对单个子文件边校验边进行商品属性数据入库，且每次均是以单个商品的属性数据为对象进行校验和入库。(对应于图2A所示实施例)

方案2：对单个子文件属性数据全部校验完成之后才进行商品属性数据的入库。(对应于图3A所示实施例)

两个方案有益效果差异如下：

方案1的操作精细度为单个商品级别，而方案2的操作精细度是单个子文件级别。

方案1对单个子文件的校验过程中，服务器需要多次与数据库进行数据交互。需要耗费较多的网络资源，且对服务器与数据库之间的网络连接质量要求较高。

方案1而言在对子文件校验的过程中，数据库内也会同步存储对子文件内各个商品的属性数据或者异常信息。若服务器异常，此时数据库亦可以记录服务器异常之前，对当前子文件内所有校验过的商品属性数据。在此基础上。其他服务器在对该子文件重新进行校验时，可以选择从头开始校验，亦可以选择继续对该子文件内尚未入库的商品属性数据进行校验。因此方案1容错机制更为完善，容错率高。

方案2，服务器若出现异常情况导致无法对当前子文件继续进行校验，会使得数据库无法获取到当前子文件内的属性数据。因此其他服务器需要重新对该子文件进行完整的校验。综上，对于服务器异常的情况，相对方案2，方案1理论上可以减少对子文件重复校验的概率，进而减少对子文件校验的工作量，实现对服务器异常情况的有效应对。

在第一方面第一种至第八种可能实现方式的基础上，作为第一方面的第九种可能的实现方式，商品数据内的属性数据中，包含商品图片下载地址，方法还包括：

根据校验通过的属性数据中包含的商品图片下载地址，下载商品图片。

对商品图片进行图像特征分析，得到图像特征数据。

将图像特征数据存储至特征库。

本申请实施例会对入库商品进行图像特征分析并存储至特征库，以供后续用户商品搜索时使用。因此本申请实施例可以为后续商品搜索提供数据支持。

作为本申请的一个实施例，对商品图片进行图像特征分析，得到图像特征数据，包括：

接收用户终端上传的第一商品图片。

对第一商品图片进行图像特征分析，得到第一图像特征数据。

对商品图像进行图像特征分析得到图像特征数据。

考虑到实际应用中CP在拍摄商品图片时，很大概率会拍摄到一些商品以外的物体。此时商品图片中可能会包含多个物体。因此若直接对商品图片进行特征分析，得到的是同时包含其他物体的图像特征数据，不利于后续的图像匹配。因此本申请实施例会在图像特征分析之前，先对商品图片进行商品检测。再根据检测结果来进行商品图像截取和分析，从而使得本申请实施例提取出的商品特征数据与商品本身更为符合，数据更为准确可靠。进而提高后续商品搜索时的准确性和可靠性。

本申请实施例的第二方面提供了一种商品搜索方法，应用于服务器，方法包括：

获取第一商品图片的第一图像特征数据，第一商品图片为用户终端上传的图片。

从特征库存储的图像特征数据中，确定出与第一图像特征数据特征匹配度最高的至少一个第二图像特征数据。

将与至少一个第二图像特征数据一一对应的第二商品图片，以及与第二商品图片关联的属性数据发送至用户终端，其中，发送的第二商品图片及关联的属性数据，是基于第一商品图片内包含的商标信息进行排序后的第二商品图片及属性数据。

在本申请实施例中，通过对用户上传的商品图片进行特征匹配的方式，可以实现对已入库商品的准确快速搜索。同时对检索出的商品数据，按照商品图片中的商标信息进行重排序再反馈给用户，从而使得与用户待检索的商品相似度较高的商品，可以在用户终端中进行属性数据和商品图片的优先展示。提高检索结果的准确性和关联性。

在第二方面第一种可能实现方式的基础上，作为第二方面的第二种可能的实现方式，在将与至少一个第二图像特征数据一一对应的第二商品图片，以及与第二商品图片关联的属性数据发送至用户终端之前，还包括：

获取第一商品图片内包含的第一商标信息。

获取各个目标商品的目标商标信息，目标商品是第二图像特征数据所关联的商品，第二商品图片及关联的属性数据，是目标商品的商品图片和属性数据。

按照目标商标信息与第一商标信息的信息匹配度从高到低的顺序，对目标商品的第二商品图片和属性数据进行排序。

本申请实施例在匹配出相关度较高的多个目标商品之后，会将用户上传的商品图片中的商标信息，与各个目标商品的商标信息进行匹配。再按照匹配度的高低依次进行排序。从而实现对目标商品基于商标信息的重排序。

在第二方面第二种可能实现方式的基础上，作为第二方面的第三种可能的实现方式，目标商标信息，包括：第二商标信息和/或第三商标信息。

第二商标信息是目标商品关联的第二商品图片内包含的商标信息。

第三商标信息是目标商品关联的属性数据内包含的商标信息。

在本申请实施例中，目标商品的商标信息可以是其商品图片内包含的商标信息，或者可以是其属性数据中记录的商标信息。亦可以是同时包含两者。因此本申请实施例可以适应各种不同的实际情况来获取目标商品的商标信息，以保障商标信息匹配的可靠性。另外，当同时包含两者时，可以提高对目标商品商标信息获取的几率。

在第二方面第一种至第三种可能实现方式的基础上，作为第二方面的第四种可能的实现方式，对第一商品图片进行图像特征分析，得到第一图像特征数据，包括：

利用预先训练完成的图像特征分析模型对第一商品图片进行图像特征分析，得到第一图像特征数据。图像特征分析模型是从基于多个商品样本的商品图片样本和属性数据样本训练得到的神经网络模型中，提取出的模型。

在本申请实施例中，利用基于商品图片和属性数据两个维度的数据进行训练后得到的图像特征分析模型来进行图像特征分析，可以提高特征分析的准确性。提高后续对特征匹配的可靠性。

作为对图像特征分析模型进行训练的一种实施例，包括：

预先设置一个初始模型。

获取多个样本商品的商品图片和对应的商品信息，将这些商品图片和商品信息作为样本数据，并为每张商品图片和每个商品信息添加对应样本商品的分类标签。

利用初始模型对作为样本数据的商品信息进行特征提取，并根据提取出的文本特征和对应的分类标签，计算对商品信息的第一损失函数。

利用初始模型提取作为样本数据的商品图片的图像特征，并根据图像特征和对应的分类标签，计算对商品图片的第二损失函数。

基于第一损失函数和第二损失函数计算第三损失函数，并根据计算出的第三损失函数值迭代更新初始模型，直至满足预设收敛条件，得到训练完成的模型。

将训练完成的模型中，用于商品图片特征提取的各个网络提取出来，并得到由这些提取出的网络构成的图像特征分析模型。

在本申请实施例中，采用分类模型的训练方式，分别对样本商品的商品图片和商品信息进行处理。在得到两个维度的损失函数之后，再进行多模融合的模型训练。即将两个维度的损失函数值通过一个新的损失函数进行融合，并基于融合得到的损失函数值来进行模型的迭代更新。最后将训练完成的模型中，用于商品图片特征提取的各个网络提取出来(即舍弃商品信息特征提取部分的网络)，组成一个新的用于图像特征分析的模型。实践证明，基于这一方法训练出图像特征分析模型，可以实现对商品图片特征更准确可靠的提取，得到的图像特征数据对商品图片具有较好的表征作用。基于这个图像特征分析模型提取出的图像特征数据，在进行商品图片匹配时，准确率较高。

本申请实施例的第三方面提供了一种商品数据管理系统，包括：第一服务器、第二服务器和数据库。

第一服务器用于获取商品数据，并将商品数据拆分为至少一个第一子文件，其中每个第一子文件中包含至少一个商品的属性数据。

第二服务器用于对各个第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库。

本申请实施例的数据管理过程中，CP只需按照格式要求提供商品数据，即可实现对商品数据的离线导入数据库。由于实际应用中CP原本就需要整理商品数据(无论是出于库存整理还是上架电商平台等目的，实际应用中CP一般都是需要整理商品数据的)，因此对CP而言，只需要将商品数据按照格式要求整理即可，无需付出过多额外的工作。商品管理系统在接收到商品数据之后，会对商品数据进行数据拆分，得到多个子文件(即第一子文件)。并会对各个子文件分别进行属性数据校验，以及校验通过的属性数据的上传。其中，第二服务器对各个子文件的校验，可以是串行处理或并行处理。当并行处理时，服务器可对多个子文件同时进行校验操作，从而提高校验的效率。

相对现有技术而言，本申请实施例大大降低了CP操作的技术门槛，可用性更高。同时对商品数据自动化的校验和数据存储，也极大地提升了对商品数据的管理效率。对应于图2A所示实施例，在本申请实施例中，第一服务器是指S102-S1032中的执行主体服务器。第二服务器是S104-S109中的执行主体服务器。

在第三方面的第一种可能的实现方式中，对各个第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库，具体包括：

第二服务器从至少一个第一子文件中选取出一个子文件作为第二子文件。

第二服务器对第二子文件进行属性数据校验，并将第二子文件中校验通过的属性数据上传至数据库。

第二服务器在完成对第二子文件的校验之后，返回执行获取至少一个第一子文件中的一个子文件的操作，直至所有第一子文件均被校验完成。

在本申请实施例中，第二服务器会循环从这些子文件中选取各个子文件(即第二子文件)并进行处理，实现对各个子任务进行数据校验，并同步将子文件内的商品数据存储至数据库。实现了对商品数据自动化的校验和数据存储，也极大地提升了对商品数据的管理效率。

另外，第二服务器可以是特指一台服务器，也可以是一个包含多台服务器的服务器集群中的任意一台服务器。当第二服务器是服务器集群中的任意一台服务器时。本申请实施例可以实现多台服务器同步进行子文件的处理校验。相对单台服务器而言，本申请实施例可以极大地提高对子文件的校验速度和可靠性。因此可以提高对商品数据入库的效率。

在第三方面第一种可能实现方式的基础上，在第三方面的第二种可能的实现方式中，在从至少一个第一子文件中选取出一个子文件作为第二子文件之前，还包括：

第一服务器还用于在数据库中创建与第一子文件一一对应的第一子任务。

第二服务器从至少一个第一子文件中选取出一个子文件作为第二子文件，包括：

第二服务器从数据库存储的第一子任务中确定出一个第二子任务，并获取至少一个第一子文件中与第二子任务关联的一个子文件。

第二服务器返回执行获取至少一个第一子文件中的一个子文件的操作，直至所有第一子文件均被校验完成，包括：

第二服务器返回执行从数据库存储的第一子任务中确定出一个第二子任务的操作，直至所有第一子任务均被执行完成。

在本申请实施例中，通过第一服务器在数据库中创建与子文件一一对应的子任务(即第一子任务)，并以确定所需执行的子任务(即第二子任务)的形式实现对各个子文件的选取。从而使得本申请实施例中，数据库可以有效记录各个子文件的校验情况，同时第二服务器也可以方便确定出每次所需校验的子文件。当第二服务器是服务器集群中的任意一台服务器时，通过在数据库创建子任务的形式，可以极大地方便服务器集群中各个服务器对子文件的获取和校验。进而提高对子文件的处理效率。

在第三方面第二种可能实现方式的基础上，作为第三方面的第三种可能的实现方式，从数据库存储的第一子任务中确定出一个第二子任务的操作，包括：

第二服务器向数据库发送任务查询请求。

数据库响应于接收到的任务查询请求，从第一子任务中筛选出待执行的子任务，并将待执行的子任务发送至第二服务器，待执行的子任务包括未执行的第一子任务，以及执行中且执行时长超出时长阈值的第一子任务。

第二服务器从接收到的待执行的子任务中，确定出第二子任务。

在本申请实施例中，会以子任务的执行状态为依据，来区分子任务是否为待执行子任务。考虑到实际应用中，一方面，未执行的子任务需要服务器进行处理。另一方面，实际应用中可能会存在服务器异常无法正常处理子任务的情况，例如服务器由于宕机等原因导致无法正常处理子任务。此时子任务虽然处于执行中，但已经无法执行完成。即使继续等待服务器，也无法完成对子任务的处理，无法实现对子文件的校验。因此需要由其他服务器重新处理这些子任务。基于上述两方面的考量。本申请实施例将未执行的子任务，以及执行中但执行时长超时的子任务，均视为待执行子任务。在此基础上，服务器会获取所有实时所有待执行子任务，并从中确定出所需执行的第二子任务。

在第三方面第三种可能实现方式的基础上，作为第三方面的第四种可能的实现方式，第二服务器从接收到的待执行的子任务中，确定出第二子任务的操作，包括：

第二服务器依次向缓存组件请求对各个待执行的子任务的分布式锁。

第二服务器在请求到对单个待执行的子任务的分布式锁时，将该待执行的子任务作为第二子任务。

作为本申请的一个可选实施例，为了提高对子任务的处理效率，可以采用多个服务器同时对各个子任务进行处理。此时作为第一方面各个方案的执行主体的服务器，也是对子任务进行处理的一个服务器。实际应用中发现，可能会出现多个服务器同时选取同一子任务进行处理的情况。此时会导致对商品数据的处理效率降低。为了防止单个子任务同时被多个服务器重复处理，在本申请实施例中，服务器在接收到待执行子任务之后，首先会从中选取出一个子任务，并尝试向缓存组件申请对该子任务的分布式锁。由于单个子任务的分布式锁仅能分配给单个服务器。因此若该子任务未被其他服务器处理，理论上此时可以获取到对该子任务的分布式锁。反之若该子任务已经被其他服务器处理，基于执行前需要申请分布式锁的原则。此时缓存组件内会记录该子任务已被其他服务器申请分布式锁。因此此时会无法成功获取子任务的分布式锁。基于这一原理，在获取到分布式锁完成上锁的操作后，服务器会判定该子任务为此次所需执行的子任务。并会下载对应的子文件。反之，若获取分布式锁失败，则会重新执行子任务选取的操作，以重新选取适宜的子任务。

在第三方面第四种可能实现方式的基础上，作为第三方面的第五种可能的实现方式，在对第二子文件进行属性数据校验的过程中，第二服务器还用于：

判断对第二子文件的校验时长是否达到时长阈值。

若对第二子文件的校验时长达到时长阈值，则释放对第二子文件的分布式锁。

为了防止服务器出现故障，导致子任务被自身长时间占据，使得对子任务执行效率降低。服务器会自行统计对子任务的校验时长，并判断是否达到时长阈值。若达到，则说明自身对子任务校验超时，可能是自身出现故障。因此此时会释放对子文件的分布式锁，从而使得其他服务器可以执行该子任务。实现了对子任务的自动节点接管。进而使得对子任务执行的可靠性大大增强。

在第三方面第四种可能实现方式的基础上，作为第三方面的第六种可能的实现方式，商品数据管理系统还包括：缓存组件。

缓存组件用于在将对第二子文件的分布式锁分配给第二服务器后，开始计时。

缓存组件还用于在计时时长达到时长阈值时，释放对第二子文件的分布式锁。

为了防止服务器出现故障，导致子任务被服务器长时间占据，使得对子任务执行效率降低。

缓存组件在分配分布式锁的同时，还会对该分布式锁进行计时，并判断是否达到时长阈值。若达到，则说明服务器对子任务校验超时，可能是服务器出现故障。因此此时会释放对子文件的分布式锁，从而使得其他服务器可以执行该子任务。实现了对子任务的自动节点接管。进而使得对子任务执行的可靠性大大增强。

在第三方面第一种至第六种可能实现方式的基础上，作为第三方面的第七种可能的实现方式，若商品数据中存在校验失败的属性数据，则第二服务器获取校验失败的属性数据的异常信息，并将异常信息存储至数据库。

本申请实施例会对解析出的属性数据进行合法性校验。即判断各个属性数据是否存在数据缺失或者数据错误等问题。当存在这些问题时，说明对这些属性数据校验失败。此时本申请实施例会将数据解析异常对应的异常信息上传至数据库。由数据对异常信息进行记录。在此基础上，可以将这些异常信息反馈至CP，或者由CP自行查询。从而使得CP可以快速或者哪些数据存在问题，并可以进行针对性的检查和重新入库。进而提高了对商品数据入库的效率。

在第三方面第一种至第七种可能实现方式的基础上，作为第三方面的第八种可能的实现方式，商品数据为数据表格式的数据。

在本申请实施例中，设定商品数据的格式为数据表格式。由于数据表格式是一种常用的数据记录格式，而是许多CP日常整理商品数据时使用的格式。因此对于CP而言，若要求商品数据以数据表格式提供，CP仅需对原本的商品数据进行简单的整理，即可得到商品管理系统所需的商品数据。从而使得对CP的技术门槛以及工作量要求大幅度降低，进而提高了对商品数据管理的效率。

在第三方面第一种至第八种可能实现方式的基础上，作为第三方面的第九种可能的实现方式，对第二子文件进行属性数据校验，并将第二子文件中校验通过的属性数据上传至数据库，包括：

在对第二子文件进行属性数据校验的过程中，第二服务器将第二子文件中校验通过的属性数据上传至数据库。或者

在对第二子文件进行属性数据校验完成后，第二服务器将第二子文件中校验通过的属性数据上传至数据库。

本申请实施例的有益效果可参考第一方面的第八种可能的实现方式中的有益效果说明，此处不予赘述。

在第三方面第一种至第八种可能实现方式的基础上，作为第三方面的第九种可能的实现方式，商品数据内的属性数据中，包含商品图片下载地址，方法还包括：

第二服务器根据校验通过的属性数据中包含的商品图片下载地址，下载商品图片。

第二服务器对商品图片进行图像特征分析，得到图像特征数据。

第二服务器将图像特征数据存储至特征库。

本申请实施例会对入库商品进行图像特征分析并存储至特征库，以供后续用户商品搜索时使用。因此本申请实施例可以为后续商品搜索提供数据支持。

本申请实施例的第四方面提供了一种商品数据管理装置，包括：

商品数据获取模块，用于获取商品数据，并将商品数据拆分为至少一个第一子文件，其中每个第一子文件中包含至少一个商品的属性数据。

入库模块，用于对各个第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库。

在第四方面的第一种可能的实现方式中，入库模块，包括：

文件选取模块，用于从至少一个第一子文件中选取出一个子文件作为第二子文件。

数据校验模块，用于对第二子文件进行属性数据校验，并将第二子文件中校验通过的属性数据上传至数据库。

在完成对第二子文件的校验之后，返回执行从至少一个第一子文件中选取出一个子文件作为第二子文件的操作，直至所有第一子文件均被校验完成。

循环模块，用于获取一个第二子文件，第二子文件是从至少一个第一子文件中选取出的一个子文件。

本申请实施例的第五方面提供了一种商品搜索装置，包括：

图片接收模块，用于接收用户终端上传的第一商品图片。

图像分析模块，用于对第一商品图片进行图像特征分析，得到第一图像特征数据。

特征匹配模块，用于从特征库存储的图像特征数据中，确定出与第一图像特征数据特征匹配度最高的至少一个第二图像特征数据。

商品搜索模块，用于将与至少一个第二图像特征数据一一对应的第二商品图片，以及与第二商品图片关联的属性数据发送至用户终端，其中，发送的第二商品图片及关联的属性数据，是基于第一商品图片内包含的商标信息进行排序后的第二商品图片及属性数据。

本申请实施例的第六方面提供了一种服务器，所述服务器包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使得服务器实现如上述第一方面中任一项所述商品数据管理方法的步骤。或者使得服务器实现如上述第二方面中任一项所述商品搜索方法的步骤。

本申请实施例的第七方面提供了一种计算机可读存储介质，包括：存储有计算机程序，所述计算机程序被处理器执行时，使得服务器实现如上述第一方面中任一项所述商品数据管理方法的步骤。或者使得服务器实现如上述第二方面中任一项所述商品搜索方法的步骤。

本申请实施例的第八方面提供了一种计算机程序产品，当计算机程序产品在服务器上运行时，使得服务器执行上述第一方面中任一项所述商品数据管理方法。或者使得服务器实现如上述第二方面中任一项所述商品搜索方法的步骤。

本申请实施例的第九方面提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述第一方面任一项所述的商品数据管理方法。或者使得服务器实现如上述第二方面中任一项所述商品搜索方法的步骤。

其中，芯片系统可以是单个芯片或者，多个芯片组成的芯片模组。

可以理解的是，上述第四方面至第九方面的有益效果可以参见上述第一方面或第二方面中的相关描述，在此不再赘述。

附图说明

图1A是本申请实施例提供的一种商品搜索界面示意图；

图1B是本申请实施例提供的一种商品数据上传界面示意图；

图2A是本申请实施例提供的一种商品管理系统的系统交互图；

图2B是本申请实施例提供的应用场景示意图；

图2C是本申请实施例提供的商品数据管理方法中申请子任务分布式锁流程示意图；

图2D是本申请实施例提供的商品数据管理方法中，对子文件校验的流程示意图；

图2E是本申请实施例提供的应用场景示意图；

图3A是本申请实施例提供的一种商品管理系统的系统交互图；

图3B是本申请实施例提供的一种商品管理系统的商品管理服务架构图；

图3C是本申请实施例提供的一种商品管理系统的商品管理服务场景交互图；

图4A是本申请实施例提供的商品数据管理方法中，进行商品检测的流程示意图；

图4B是本申请实施例提供的商品数据管理方法中，进行图片搜索的流程示意图；

图4C是本申请实施例提供的商品搜索的逻辑架构示意图；

图4D是本申请实施例提供的商品搜索的逻辑架构示意图；

图5A是本申请实施例提供的一种商品管理系统中，进行文本搜索时的系统交互图；

图5B是本申请实施例提供的应用场景示意图；

图5C是本申请实施例提供的应用场景示意图；

图5D是本申请实施例提供的应用场景示意图；

图5E是本申请实施例提供的应用场景示意图；

图6是本申请实施例提供的一种商品管理系统中，进行图片搜索时的系统交互图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

为了便于理解，此处先对本申请实施例进行简要说明：

实际应用中，存在一些需要提高商品曝光度的场景。例如以下几种场景：

场景1：对商家而言，其会在一些电商平台之中上架商品，以实现对商品的曝光和销售。但实际应用中电商平台的数量较多，且每个电商平台中往往会包含大量的商品。从而使得商家的商品曝光度往往较低，被用户获知或购买概率较低。

场景2：对电商平台和销售网站而言，单个电商平台中，可能会包含大量的商家及商家上架的商品。电商平台可以通过各种推荐或排序算法，实现对用户的商品推送或展示。但对于上架商品的总数量而言，这些被推送或者展示的商品数量往往占比极低。例如单个主流的电商平台内可能有数亿件上架的商品，但向用户推送或展示的商品数量可能仅有数千件。此时绝大部分的商品是难以被用户获知或购买的。因此电商平台对商品的曝光度较低，不利于电商平台的发展。

针对这些需要提高商品曝光度的场景，一种可选的解决方式是为用户提供商品搜索服务。即用户可以根据自己实际需求，搜索电商平台和销售网站的商品。例如可以参考图1A，是一种商品搜索的界面示意图。用户可以根据需求在图1A所示界面中输入商品名称并进行商品搜索。但商品搜索的前提是需要内容提供商(Content Provider，CP)向商品管理系统提供商品数据，并将商品数据存入数据库(又称为入库)，使得商品管理系统可以基于这些商品数据来为用户提供商品搜索服务。例如可以参考图1B，是一种商品数据上传界面示意图。CP可以根据自身需要及商品管理系统要求来整理商品数据，再将商品数据上传至商品管理系统的数据库。

本申请实施例实现了对商品数据自动化校验和入库的效果。相对现有技术中需要CP自行整理结构化商品数据，并上传至商品管理系统的存储桶而言。本申请实施例大大的降低了CP商品数据操作的技术门槛，实现了对商品数据的高效管理。从而避免了复杂繁琐的商品数据操作使得商品数据管理效率较低的问题。

同时对本申请实施例中可能涉及到的一些名词和概念进行说明如下：

商品数据：是由一个或多个商品的属性数据组成的数据，例如可以由商品名称、价格和链接等组成商品数据。其中，商品数据内具体包含的商品数量可由CP根据实际情况确定。另外在本申请实施例中，可由技术人员在设置商品数据的格式时，一并设置对商品的属性数据提供要求。要求中可以包含必须提供的属性数据和可选提供的属性数据。在此基础上，CP再根据实际需求来进行属性数据的提供。因此商品数据内实际包含的属性数据种类及数量，需根据实际应用中技术人员设置的属性数据提供要求以及CP提供数据的情况确定，此处不做过多限定。另外，本申请实施例亦不对属性数据提供要求的内容进行过多限定，可由技术人员根据实际需求自行设定。在本申请实施例中，当CP终端以文件的形式上传这些属性数据时，商品数据也可以叫做商品文件。应当说明地，在本申请实施例中，商品数据可以是结构化数据，也可以是非结构化的数据。由于本申请实施例中商品数据会被拆分为多个子文件进行校验，并将校验通过的属性数据存储至数据库。因此无论商品数据是结构化或非结构化数据，在本申请实施例中，均可以实现对商品数据的高效校验和入库，从而提高商品数据管理效率。相应的，当商品数据为结构化数据时，对子文件内属性数据存入数据库的过程，仍为对商品数据结构化存储的过程。

以一实例进行说明，假设属性数据提供要求中包含：商品的序号(Identitydocument，ID)、类目、名称、价格、图片地址、网页链接以及应用程序(Application，App)链接。其中商品编码、类目、名称和价格均是必须提供的属性数据，而图片地址、网页链接和App链接则是可选提供的属性数据。并要求以数据表的格式提供商品数据。其中图片地址是指商品图片的下载地址。在此基础上，CP可以根据上述要求准备商品的属性数据，并根据实际可获取到的商品属性数据情况来整理对应的数据表。例如CP提供的商品数据可以如下表1(此时商品的数量为4)：

表1

商品信息：商品数据是CP提供的原始数据。为了实现对商品数据的管理，本申请实施例会将商品数据存储至数据库之中(即入库)。为了区分存储前后的商品数据，本申请实施例将数据库内存储的商品数据称为商品信息。应当说明地，当商品数据中包含图片等无法结构化存储至数据库的数据时，则将这部分数据作为商品信息之外的数据，存储在数据库之外的其他地方。例如可以存储在网络存储平台。此时所需管理的商品数据由商品信息和无法结构化的数据两部分组成。应当说明地，在本申请实施例中，商品信息均为文本类型的信息。

数据库(DataBase，DB)及入库：数据库是按照数据结构来组织、存储和管理数据的数据仓库。在本申请实施例中，数据库用于存储商品信息。

应当说明地，结构化数据也称作行数据，是由二维表结构来逻辑表达和实现的数据(即结构化数据是以二维表形式来存储的数据)，严格地遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。在本申请实施例中，商品信息为结构化的商品数据，即属于结构化数据。由于数据库是以一定的数据结构来进行数据存储，因此将商品数据入库的过程，即为将商品数据按照数据库结构化要求入库。由此可知，入库过程已经包含了对商品数据结构化操作。

数据库具体所处的终端设备情况此处不予限定，例如可以是处于单台服务器，或者处于服务器集群。另外数据库的类型此处亦不做过多限定，可由技术人员根据实际需求选取或设置。例如可以是Mysql、Oracle或者SqlServer。相应的，数据库中存储商品信息的二维表的结构样式，可根据具体数据库的类型来确定，此处不予限定。

格式(商品数据的格式)：为了便于对商品数据进行结构化存储(即存储至数据库)，本申请实施例会预先由技术人员设置商品数据的格式。在此基础上，CP需要按照该格式来整理商品的属性数据，从而得到满足要求的商品数据。例如若格式为数据表，此时CP需要将商品的属性数据记录至数据表之中，从而得到数据表格式的商品数据。本申请实施例不对具体的格式做过多的要求，可由技术人员自行设置。

作为本申请的一个可选实施例，技术人员可以设置商品数据的格式为数据表，并同时设置相应的属性数据提供要求(如哪些属性数据需要提供，哪些可以选择提供或者不提供)。此时CP需要按照属性数据提供要求来整理商品的属性数据，并将整理好的属性数据记录至数据表之中。

在一些可选实施例中，技术人员可以以数据表模板的方式，来实现对商品数据的格式和属性数据提供要求的设置。即技术人员预先在数据表模板中设置好所需提供的属性。作为数据表模板的一个可选实施例，可以参考下表2：

表2

属性1

属性2

属性3

属性4

属性5

属性6

属性7

在本实施例中，由技术人员预先在数据表模板第一行内填写CP所需提供的各个属性(即属性1至属性7)。其中，具体选取的属性此处不做过多限定，可由技术人员自行设定。例如可以是表1中的ID、类目、名称、价格、图片地址、网页链接以及App链接，亦可以是其他属性。在此基础上，CP需要根据数据表模板中预设好的属性，在数据表模板中填写或导入商品的各项属性数据，以完成对数据表模板的输入。

另外应当说明地，商品数据的格式是由技术人员预先设定的数据格式，其与商品数据入库的关系说明如下：

在本申请实施例中，先由技术人员设定好商品数据的格式，再由CP按照该格式来整理商品的属性数据，并得到满足该格式的商品数据。在此基础上，由CP将整理得到的商品数据上传至商品管理系统，并由商品管理系统对商品数据进行入库。由此可知，CP上传的商品数据(亦商品管理系统处理的原始商品数据)即为满足格式要求的数据。

CP终端：是指CP进行商品数据上传时使用的终端设备。本申请实施例不对CP终端的设备类型进行过多限定，可根据实际应用场景情况确定。例如，可以是台式电脑、笔记本电脑、平板电脑或者手机等。应当理解地，CP进行商品数据准备和商品数据上传的终端设备，可以不是同一设备。例如可以先使用笔记本电脑准备商品数据，再利用手机进行上传。因此理论上CP终端需具备数据上传能力，但不一定需要具备对商品数据内容的增加、删除、修改、校验以及对商品数据格式调整等数据编辑能力。

用户终端：是指用户进行商品搜索时使用的终端设备。实际应用中，用户可以通过在用户终端中输入文字或者输入图片，并上传到商品管理系统的方式，实现对商品的搜索。其中，用户可以是消费者也可以是其他人员，如可以是CP，具体需根据应用场景确定。本申请实施例不对用户终端的设备类型进行过多限定，可根据实际应用场景情况确定。例如，可以是台式电脑、笔记本电脑、平板电脑、手机或者可穿戴设备等。

网络存储平台(Network Storage Platform，NSP)：用于对CP终端上传的商品数据的存储，以及对商品图片的存储。理论上具有数据存储能力以及数据传输能力的设备均可作为本申请实施例的NSP，实际应用中，NSP的具体设备类型和数量等，可由技术人员根据实际需求选取或设定。例如，可以是单台具有文档和图片存储功能的服务器，或者是具有文档和图片存储功能的服务器集群。

特征库：为了实现对商品的图片搜索，本申请实施例可以对商品图片进行图像特征分析，并得到图像特征数据。这些图像特征数据用于图片搜索时的图像匹配。在本申请实施例中，特征库是指用于存储图像特征数据的数据仓库。另外根据实际需求，特征库中也可以存储一些图像特征数据以外的其他数据。具体可由技术人员根据需求设定。其中，本申请实施例不对特征库所处的终端设备情况进行过多限定。可由技术人员根据实际需求选取或设定。例如可以是处于单台服务器，或者处于服务器集群。在本申请实施例中，特征库又可称为商品底库。

缓存组件：提供分布式锁的管理服务。在本申请实施例中，为了防止单个任务同时被多个服务器执行，可以设置上锁机制。在服务器需要执行某个任务之前，先向缓存组件申请对该任务的分布式锁。在成功获得对该任务分布式锁时，即完成了对该任务的上锁。此时服务器可以执行该任务。相应的，此时其他服务器无法再从缓存组件申请到该任务的分布式锁，亦无法执行该任务。在本申请实施例中，不对缓存组件分布式锁的实现方法进行过多限定。可由技术人员根据实际需求设定。例如可以基于分布式缓存(DCS Redis)实现分布式锁，或者基于zookeeper实现分布式锁。同时，本申请实施例不对特征库所处的终端设备情况进行过多限定。可由技术人员根据实际需求选取或设定。例如可以是作为一个组件存在于服务器中。在本申请实施例中，当基于分布式缓存实现分布式锁时，缓存组件亦可称为DCS分布式锁。

为了说明本申请所述的技术方案，下面以技术人员设置商品数据的格式是数据表为例。对商品的数据管理和用户进行商品搜索两个部分，通过具体实施例来进行说明。

部分一：商品管理系统对商品数据的管理操作。

在本申请实施例中，商品管理系统包括：至少一个服务器、数据库和NSP。在一些可选实施例中，商品管理系统还可以包括缓存组件和特征库。图2A示出了商品管理系统在对商品数据进行数据管理时的系统交互图，详述如下：

S101，CP终端上传商品数据至NSP。

对于CP而言，首先需要按照技术人员设定的格式来准备商品数据。以设定的格式是数据表模板为例进行举例说明。假设技术人员提供的数据表模板为下表3：

表3

同时设置：ID、类目、名称、价格和图片地址为必须提供的属性数据，币种标识和图片ID为可选属性数据。网页连接、App链接和快应用链接，则至少填写一项。

其中，ID是指商品序号。类目即商品的类别，根据需求不同，可以进行不同的分类。例如可以分为：服装、数码家电、鞋子、箱包、家居、玩具、美妆、配饰、食品和其它类。币种标识即为价格所属币种的标识，如人民币可以为￥，美元可以是$，英镑可以是￡。图片地址，是指商品图片的下载地址。考虑到实际应用中CP可能会有较多的商品图片提供，此时若一一进行上传，操作会比较繁琐。因此在本申请实施例中，提供了图片地址属性。CP可以将商品图片存储在一些服务器之中，并在数据表模板中填写响应的图片地址，即可完成对商品图片的提供。图片ID是指商品图片的序号。网页链接(weburl)，是指商品销售网页的链接，通过打开该链接，可以打开浏览器并进入对应的商品销售网页。网页链接可以是普通的网页链接，也可以是Html5网页链接。App链接，是指商品在App中的销售页面的链接。通过打开该链接，可以开启对应的App并跳转到App中的商品销售页面。快应用链接是指商品在快应用中的销售页面的链接。通过打开该链接，可以开启对应的快应用并跳转到快应用中的商品销售页面。其中，网页连接、App链接和快应用链接中，均可以填写一条或多条链接，实现对不同电商平台的跳转。例如提供3条不同的网页链接，分别对应着3个不同的电商平台下的商品销售网页。此时可以实现对不同电商平台的跳转。

CP在表3的基础上，可以根据实际情况来进行商品属性数据的填写或导入(实际应用中，CP一般在进行商品库存管理时就会整理商品数据。因此此处可以是根据CP原本的商品数据进行数据表模板的数据导入。此时对CP的工作量增加极少)，以实现商品数据的准备。其中，商品的实际数量可以是几个，也可以是数千或数万个，具体需由CP根据实际情况确定。理论上每个商品都需要进行上述各项属性数据的填写，此时表格内每一行即代表着一个商品的数据。因此表3的行数也需根据商品的实际数量确定。例如参考表1，此时商品数量即为4。

作为本申请的一个可选实施例，在表3的基础上，技术人员可以根据实际需求添加或删除属性。例如可以删除快应用链接，或者增加序号、颜色、尺码等属性，或者将价格属性细分为价格最小值和价格最大值两个属性等。此处不做过多限定。

作为本申请的一个实施例，为了丰富对商品详情的说明，在表3的基础上，也可以添加商品描述属性。此时CP可以表3中自行填写一些对商品的描述文字，以方便用户深入了解商品情况。例如可以填写“此商品为绿色有机食品”。

在完成商品数据的准备之后，CP可以通过CP终端，将商品数据上传至NSP。例如当商品数据为记录有表3(填写或导入属性数据之后的表3)的表格文件时。CP可以通过手机或电脑等设备，来将表格文件上传至NSP。

作为一个本申请实施例，为了便于CP操作，可以预先设置好用于商品数据上传的门户(Portal)网站。CP在实际操作中，可以通过CP终端访问该门户网站，并从门户网站界面内上传商品数据的方式。完成对商品数据的上传操作。

其中，作为本申请的一个可选实施例，考虑到一些情况下CP终端可能无法与NSP直接进行数据传输。此时可以在CP终端和NSP之间设置一个中间设备，例如可以是一台服务器。实际操作时，服务器为CP终端供可调用的应用程序接口(Application ProgrammingInterface，API)。CP终端通过调用该API将商品数据发送至该中间设备，由中间设备上传至NSP，以完成对商品数据的上传。

S102，服务器从NSP中下载商品数据并进行拆分，得到一个或多个子文件。其中，每个子文件中包含至少一个商品的属性数据。

考虑到实际应用中商品数据内记录的商品数量往往较多。此时若直接对商品数据进行校验以及入库等操作，效率较低且容易出错。对于CP而言则需要等待较长的时间才能得知入库结果。因此为了提升对商品数据的管理效率，在本申请实施例中会对商品数据进行拆分，将商品数据拆分为多个子文件。其中，拆分得到的子文件，其格式与拆分前的商品数据可以相同或不同。例如当商品数据格式为数据表时，子文件可以是数据表，亦可以是其他格式的文件。详述如下：

在商品数据上传至NSP之后，服务器会从NSP中下载商品数据，并将商品数据拆分为一个或多个子文件。其中，商品数据的拆分规则此处不做过多限定，可由技术人员根据实际需求确定。其中考虑到子文件中包含的数据量越小，理论上对单个子文件的处理速度、可靠性和时效性越高，但此时子文件的数量较多，又会造成整体处理的效率有所下降。因此技术人员可根据实际对商品数据管理的效率和可靠性等需求，来设定拆分规则。例如可以设置为：每个子文件中包含的商品数量为m，其中m为正整数，如可以为1000。此时每个子文件中均包含m个商品的属性数据(对于最后一个子文件，商品数量可以不足m)。又例如，亦可以设置为每个子文件中包含的商品数量为[1，n]中的一个任一整数值。该值可以是随机选取的，也可以是按照一定规则选取的。其中n为大于1的整数，如可以是1000。

通过对商品数据进行子文件拆分，具有以下有益效果：

1、子文件内包含的商品属性数据较少，相对包含较多商品属性数据的商品数据而言，服务器处理子文件的出错概率较低，可靠性更强。

2、由于单个商品数据内包含的商品属性数据较多，若交由单个服务器直接进行处理，耗时较长，效率较低。通过将商品数据拆分为子文件，再将子文件交由一个或多个服务器进行并行处理。可以极大地缩短处理时长，提高对商品数据的处理效率。对于CP而言，可以在较短的时间内获知商品数据的入库情况。因此亦可以提高CP对商品管理系统的使用体验。

应当理解地，当划分规则中单个子文件内包含的商品数量大于或等于商品数据中包含的商品总数量时，会出现划分的结果仅有一个子文件的情况(此时理论上可以不存在拆分的动作)。因此S102中得到的子文件数为一个或多个。例如假设划分规则设置为：每个子文件中包含的商品数量为1000。但商品数据中包含商品数量不足1000，如900。此时所有商品的属性数据均会划分至同一子文件中。

作为本申请的一个可选实施例，考虑到实际应用中单个商品数据内包含的商品数量可能极多。例如可能同时包含成千上万个商品的属性数据。为了实现对不同商品之间的区分，实现对单个商品的唯一确定。在数据拆分的时候，可以对子文件内各个商品添加唯一标识。该唯一标识可以作为商品的一个新的属性数据，添加至商品数据之中。在一些可选实施例中，虽然CP可能会在商品数据中提供商品的ID等标识。但对于商品管理系统而言，CP的行为不可控。实践证明，CP提供的标识亦可能会出现重复、缺失、不规范等情况，因此标识不一定具有唯一性，且可信度相对较低。而本申请实施例中，由服务器自行为各个商品添加唯一标识，可以确保该唯一标识的可信度，进而确保对各个商品之间的准确区分。

另外在一些可选实施例中，若要求CP以数据表模板的方式提供商品数据。此时单个商品的属性数据均处于同一行，即每一行即为一个商品的所有属性数据。因此可以将生成的唯一标识，作为商品的行号属性数据添加至数据表模板中。此时商品在商品数据中的行号，即为该商品的唯一标识。本申请实施例不对唯一标识的类型和生成方法做过多限定，可由技术人员自行设定。例如可以以商品数据上传时间加商品序号等方式组成唯一标识。亦可以是随机生成不重复的字符串，并作为单个商品的唯一标识。另外，可以对唯一标识的长度进行设定，例如可以设定为16位固定长度。在生成唯一标识时，若不足该长度，则进行空格补齐，或者进行补0。

S103，服务器将所有子文件存储至NSP，并获取各个子文件的在NSP中的下载地址。再基于下载地址，在数据库中创建与子文件一一对应的子任务，同时创建一个包含这些子任务的父任务。

其中，S103可以细分为S1031和S1032：

S1031，服务器将所有子文件存储至NSP，并获取各个子文件的在NSP中的下载地址。

S1032，服务器基于下载地址，在数据库中创建与子文件一一对应的子任务，同时创建一个包含这些子任务的父任务。

在完成对商品数据的拆分，得到一个或多个子文件之后。进行拆分操作的服务器，会将得到的所有子文件统一上传至NSP。并会在存储的同时，获取各个子文件在NSP中的下载地址。其中，NSP与执行S103的服务器为相互独立的设备。

在获取到各个子文件的下载地址之后，服务器会在数据库中创建与各个子文件一一对应的子任务，并会将各个子文件的下载地址存储至对应的子任务之中。在本申请实施例中，子任务可供服务器执行。其中执行子任务实质是：服务器通过子任务内的下载地址下载子任务对应的子文件，并对下载的子文件内的属性数据进行校验和入库。通过执行各个子任务，服务器可以实现对各个子文件的有效处理，实现最终对商品数据的入库。

实际应用中，每个子任务均需被执行才能实现对商品数据的完整入库。因此服务器在执行子任务的过程中，需要确认单个商品数据下的子任务是否均被执行完成(确认的方式可由技术人员自行设定，此处不做限定)。而实际应用中，商品管理系统可能需要同时处理多个商品数据。因此对于数据库而言，其可能同时存储有多个商品数据对应的子任务，此时子任务的数量较多，管理难度较大。为了便于管理各个商品数据下的子任务，服务器在创建子任务的同时，还会创建一个包含这些子任务的父任务。因此每个商品数据均对应有一个父任务，且单个父任务下包含对应商品数据下的所有子任务。在确认某个商品数据下的子任务是否均被执行完成时，查询该商品数据对应父任务内各个子任务的执行状态即可。因此可以提高对子任务管理的效率。

另外，本申请实施例还会记录各个子任务的执行状态。本申请实施例中，子任务的执行状态包含三种：未执行、执行中以及执行完成。当有子任务被服务器执行时，数据库会同步更新子任务的执行状态。

其中，未执行是指该子任务当前未被任何服务器执行。执行中是指，该子任务当前正在被至少一个服务器执行，且还没有服务器执行完成该子任务。执行完成，是指该子任务已经被至少一个服务器执行完成。由于在本申请实施例中，执行子任务的实质是对子任务对应的子文件内的属性数据进行校验和入库。因此未执行实质是指该子任务对应的子文件内的属性数据尚未被校验和入库。执行中是指该子任务中对应的子文件内的属性数据正在被校验和入库。而执行完成则是指该子任务对应的子文件内的属性数据，已经完成校验和入库。对于刚创建的子任务，数据库内均会将执行状态标记为未执行。

以一实例举例说明。假设对商品数据A进行拆分后得到了子文件a和子文件b。此时服务器会将两个子文件均存储至NSP，并获取对应的两个子文件下载地址。假设子文件a在NSP中的下载地址为：https://xxxhuawei.com/filea/huawei.html，子文件b在NSP中的下载地址为：https://xxxhuawei.com/fileb/huawei.html。此时服务器会在数据库中创建子任务a和子任务b，以及同时包含两个子任务的父任务A(父任务内可以没有实质的任务内容，仅记录有包含的子任务)。同时会将下载地址：https://xxxhuawei.com/filea/huawei.html存储至子任务a中，将下载地址：https://xxxhuawei.com/fileb/huawei.html存储至子任务b中。

作为本申请的一个可选实施例，为了方便对各个子任务的区分，在创建子任务的同时，可以为每个子任务添加一个标识或ID。数据库和服务器在进行交互的时候，可以通过告知对方子任务标识或ID的方式，实现对子任务的唯一确定。

作为本申请的一个可选实施例，服务器将子文件存储至NSP的操作之后，服务器可以将NSP中CP终端上传的商品数据删除，以节约NSP存储空间。

作为本申请的一个可选实施例，考虑到实际应用中可能会有多个CP分别上传各自的商品数据。此时为了提高对商品数据的处理效果，可以同时使用多台服务器来完成。同时引入分布式锁，以避免造成服务器资源浪费。

针对同时使用多台服务器进行商品数据拆分和任务创建的场景，为了防止单个商品数据被重复处理。本申请实施例会引入分布式锁的上锁机制。即S102中，服务器首先会针对单个商品数据的分布式锁。并仅会在获取到分布式锁(即完成上锁)之后，才会执行商品数据下载和拆分等操作。此时S102可以被替换为：S1021，服务器向缓存组建获取针对商品数据的分布式锁。若获取到分布式锁，则从NSP中下载商品数据并进行拆分，得到一个或多个子文件。其中，每个子文件中包含至少一个商品的属性数据。

作为本申请的一个可选实施例，参考图2B。在本申请实施例中，采用了多个服务器负责对商品数据进行拆分，以实现任务分解。同时为了防止单个商品数据被多个服务器重复处理，还引入了分布式锁。详述如下：

各个服务器查询对记录有待处理商品数据的任务列表。

若发现有需要处理的商品数据，则各个服务器分别申请针对商品数据的分布式锁。即进行抢锁。

抢锁成功的服务器会作为S102-S103的执行主体，从NSP中下载商品数据。

下载完商品数据之后，再进行子文件拆分，得到多个子文件。

将得到的所有子文件存入NSP中，同时基于子文件的下载地址，在数据库中创建与各个子文件对应的子任务。

另外，在进行子文件拆分的时候，还可以为子文件中各个商品添加行号作为唯一标识。

S104，服务器向数据库发送任务查询请求。

在S102-S103完成对子任务的创建之后，本申请实施例开始对子任务进行处理，以校验子任务对应的各个子文件。为了实现对子任务的处理，首先会由服务器向数据库发送任务查询请求，该任务查询请求用以请求数据库告知服务器当前父任务下待执行的子任务。其中，任务查询请求的数据内容和格式等，此处不做过多限定，可由技术人员根据需求设定。

S105，数据库在接收到任务查询请求后，从父任务包含的所有子任务中，筛选出待执行的子任务，并将筛查出的子任务以子任务列表的形式返回给服务器。

在本申请实施例中，会以子任务的执行状态为依据，来区分子任务是否为待执行子任务。具体而言，由技术人员预先设置好待执行子任务所对应的执行状态。在此基础上，数据库在接收到任务查询请求之后，会识别父任务下各个子任务的执行状态，并从中筛选出执行状态满足要求的待执行子任务。例如可以将所有执行状态为未执行的子任务，均作为待执行子任务。此时数据库会将父任务下所有执行状态为未执行的子任务，均作为待执行子任务。

另外，根据实际需求，技术人员亦可在执行状态的基础上，增加一些其他的筛选条件，以实现对待执行子任务的精准区分和筛选。例如，在执行状态的基础上，还可以增加任务执行时长的限制。此时，数据库会同时获取子任务的执行状态和执行时长，并筛选出执行状态和执行时长均满足预设要求的子任务，作为待执行子任务。

作为本申请的一个可选实施例，根据执行状态和执行时长的差异，待执行子任务有以下几种可选的范围：

1、包含所有未执行的子任务。

2、包含所有未执行的子任务和所有执行中的子任务。

3、包括所有未执行的子任务和部分执行中的子任务。

实际应用中，技术人员可以根据需求来选取上述3种范围中的任意一种作为待执行子任务范围。亦可以根据需求自行设置待执行子任务的范围。此处不做过多限定。

作为本申请的一个可选实施例。考虑到实际应用中，一方面，未执行的子任务需要服务器进行处理。另一方面，实际应用中可能会存在服务器异常无法正常处理子任务的情况，例如服务器由于宕机等原因导致无法正常处理子任务。此时子任务虽然处于执行中，但已经无法执行完成。即使继续等待服务器，也无法完成对子任务的处理，无法实现对子文件的校验。因此需要由其他服务器重新处理这些子任务。基于上述两方面的考量。本申请实施例将未执行的子任务，以及执行中但执行时长超时的子任务，均视为待执行子任务。此时S105中对待执行子任务的筛选操作，可以替换为：

数据库在接收到任务查询请求后，从父任务包含的所有子任务中，筛选出未执行的子任务，以及执行中且执行时长超出时长阈值的子任务。

其中，为了衡量子任务是否超时，本申请实施例会预先设置一个时长阈值。并会将执行时长超出时长阈值的子任务判定为执行时长超时。

在S105筛选出待执行子任务之后，本申请实施例会将这些子任务以放在同一列表(即子任务列表)中，并将子任务列表反馈至发送任务查询请求的服务器。其中，子任务列表中，各个子任务内均记录有对应的子文件下载地址，以便于服务器下载子文件进行处理。其中，若仅筛选出一个满足要求的待执行子任务，此时可以不整理子任务列表，而是直接将筛选出的子任务返回至服务器。亦可以返回仅包含一个子任务的子任务列表。具体可由技术人员自行设置。

作为本申请的一个可选实施例，为了方便服务器根据子任务列表确定所需执行的子任务。本申请实施例中，数据库会记录各个子任务的创建时间。在筛选出子任务之后，会按照创建时间和执行状态来对子任务进行优先级排序，并按照排序结果来生成子任务列表。再将排序完成后的子任务列表反馈给服务器。

其中，具体的子任务优先级排序规则此处不做过多限定，可由技术人员根据实际需求设定。例如可以设定为未执行的子任务优先级高于执行中的子任务。其中，未执行的子任务按照创建时间从先到后优先级依次降低，执行中的子任务亦按照创建时间从先到后优先级依次降低。

另外应当说明地，作为本申请的一个可选实施例，对于S105中数据库所需执行的各个操作的逻辑，可以内置于数据库之中，亦可以以程序的形式内置于数据库所处的终端设备。具体可由技术人员根据实际需求设定。当内置于数据库之中时，S105的操作可由数据库自身完成。而当以程序的形式内置于数据库所处终端设备时，则由该终端设备完成S105的操作。

S106，服务器在接收到子任务列表之后，从子任务列表中确定出一个子任务，并按照确定出的子任务中的下载地址，从NSP中下载该子任务对应的子文件。

服务器在接收到子任务列表之后，会从中选取出一个子任务作为此次执行的子任务。同时在完成子任务选取之后，服务器还会根据该子任务内的下载地址，从NSP内下载对应的子文件，以进行后续的数据校验。其中，本申请实施例不对子任务的选取方法进行过多的限定，可由技术人员根据实际进行设定。例如在一些可选实施例中，可以选取子任务列表中的第一个子任务，或者也可以随机选取一个子任务。在一些实施例中，若数据库在发送子任务列表之前，已对子任务列表内的各个子任务进行了优先级排序。则此时服务器可以选取其中优先级最高的子任务进行处理。例如当是按照优先级从高到底的顺序排序时，此时可以选择第一个子任务进行处理。

作为本申请的一个实施例，在确定出此次执行的子任务之后，服务器还会告知数据库该子任务当前处于执行中(可以通过向数据库发送携带有子任务ID以及执行状态的指令的方式实现)。以帮助数据库更新该子任务的执行状态，以及为计算执行时长提供数据。相应的，数据库在获知该子任务被服务器选择执行的消息后。会将该子任务的执行状态设置为：执行中，并将获知此消息的时间设置为该子任务最后更新时间(last_update_time)。而子任务的执行时长则等于当前时间与最后更新时间的差值，即now()-last_update_time。其中对于原本就为执行中的子任务，此时仅需更新子任务开始执行的时间即可，无需再更改执行状态。

作为本申请的一个可选实施例，为了提高对子任务的处理效率，可以采用多个服务器同时对父任务内的各个子任务进行处理。但实际应用中发现，可能会出现多个服务器同时选取同一子任务进行处理的情况。此时会导致对商品数据的处理效率降低。为了防止单个子任务同时被多个服务器重复处理。本申请实施例会引入分布式锁来进行操作。具体而言，参考图2C，此时S106可以被替换为：

S1061，服务器在接收到子任务列表之后，从子任务列表中不重复的选取一个子任务，并在选取出子任务之后，向缓存组件申请对该子任务的分布式锁。

S1062，若成功获取到对该子任务的分布式锁，则服务器停止对子任务的选取操作，并按照该子任务中的下载地址，从NSP中下载该子任务的子文件。

S1063，若未成功获取到对该子任务的分布式锁，则服务器返回执行从子任务列表中不重复的选取一个子任务，并在选取出子任务之后，向缓存组件申请对该子任务的分布式锁的操作。

本申请实施例中，服务器在接收到子任务列表之后，首先会从中选取出一个子任务，并尝试向缓存组件申请对该子任务的分布式锁。其中，服务器可以通过将子任务的标识或ID发送给缓存组件的方式，告知缓存组件此次申请的是哪个子任务的分布式锁。

由于单个子任务的分布式锁仅能分配给单个服务器。因此若该子任务未被其他服务器处理，理论上此时可以获取到对该子任务的分布式锁。反之若该子任务已经被其他服务器处理，基于执行前需要申请分布式锁的原则。此时缓存组件内会记录该子任务已被其他服务器申请分布式锁。因此此时会无法成功获取子任务的分布式锁。基于这一原理，在获取到分布式锁完成上锁的操作后，服务器会判定该子任务为此次所需执行的子任务。并会下载对应的子文件。反之，若获取分布式锁失败，则会重新执行S1061中子任务选取的操作，以重新选取适宜的子任务。

本申请实施例不对子任务的选取方法做过多的限定，理论上只需不重复选取即可。例如在一些可选实施例中，可以是随机选取或者顺序选取。作为本申请的一个可选实施例。若数据库在发送子任务列表之前，已对子任务列表内的各个子任务进行了优先级排序。则此时服务器可以按照优先级从高到低的顺序，依次进行子任务选取。例如当是按照优先级从高到底的顺序排序时，此时选取方法可以设置为：从任务列表内未选取过的子任务中，选取出排序最前的一个子任务。本申请实施例可以防止单个子任务长时间未被处理的情况出现，可以提高对子任务处理的效率。

另外，为了实现对子任务执行状态的及时更新。本申请实施例中，S1062服务器在获取到分布式锁之后，还会告知给数据库当前子任务处于执行中。以帮助数据库更新该子任务的执行状态，以及执行时长。

S107，服务器对子文件内的各个商品进行属性数据校验。并将校验通过的商品的属性数据存储至数据库。

若存在校验未通过的商品，则记录这些商品的属性数据的异常信息，并将异常信息存储至数据库。

在获取到子文件之后，服务器开始对子文件内各个商品的属性数据进行校验。即检查商品的属性数据是否符合预设要求。其中，考虑到不同实际应用场景下对商品属性数据的要求可能会存在一定差异。例如一些可能场景下，为了适应主流终端设备的显示效果，对商品的图片要求较为严格。此时可能会较为严格的要求图片的格式和大小。而在另一些可能场景下，为了为用户提供较为全面的商品数据，可能会对商品属性数据的种类数量要求较高。因此，本申请实施例不对具体的数据校验要求做过多的限定。实际应用中，可由技术人员针对实际应用场景的需求来预设对商品属性数据的要求。再由服务器根据该预设要求，来对子文件内各个商品的属性数据进行校验。

另外，对于子文件中包含多个商品的情况，可以选择每次仅对一个商品的属性数据校验的方式，实现对各个商品属性数据的校验。亦可以选择对多个商品进行并发处理，即每次同时对多个商品进行属性数据校验，以提高校验效率。具体可由技术人员根据自行设定，此处不做过多限定。而对于单个商品的各个属性数据的校验规则，此处亦不做过多限定，可由技术人员自行设定。例如在一些可选实施例中，可以设置为依次判断商品的各个属性数据是否满足要求。而在另一些可选实施例中，亦可设置为同时判断多个属性数据是否满足要求。此时可以提高校验效率。

在设置好对商品属性数据要求和校验规则的基础上，本申请实施例会以单个商品为操作对象进行属性数据的校验。因此理论上子文件中每个商品均会有对应的一个校验结果。在本申请实施例中，单个商品的校验结果可分为两类：

1、商品的所有属性数据均校验通过(简称校验通过)。

2、商品的属性数据中存在异常，使得校验未通过(简称校验未通过)。

对于校验通过的商品，本申请实施例中服务器会将商品的属性数据存储至数据库。由于数据库是以结构化的方式存储数据的，因此将属性数据存储至数据库的过程，即为对属性数据的结构化存储过程。其中，若属性数据中包含商品图片，或者包含商品图片的下载地址。则本申请实施例会将对应的商品图片存储至NSP之中。

对于校验未通过的商品，服务器则会记录商品对应的异常信息，例如该商品具体是什么属性数据异常。并将异常信息反馈给数据库。以实现对商品属性数据异常的记录，方便CP根据异常信息重新针对性地上传商品属性数据，提高商品数据管理效率。

以一实例进行子文件数据校验的举例说明。假设商品数据的格式为数据表，数据表内的每一行，用于记录一个商品的所有属性数据。且要求必须提供的属性数据包括：商品的ID、名称、类目、图片地址和网页链接。同时，假设S102服务器在拆分商品数据时，拆分出的子文件也是数据表格式。且会在子文件内为每个商品生成一个唯一标识，并将该标识作为商品的行号添加至商品的行中。在此基础上，参考图2D，对子文件的数据校验操作，可以包括：S1071-S10710。

S1071，服务器读取子文件内的一行数据，并将读取出的一行数据拆分为第一行号和第一数据。

在本申请实施例中，每次仅会对单个商品的属性数据进行校验。因此服务器每次会读取出单行数据。作为本申请的一个可选实施例，为了防止多次校验同一商品的属性数据，可以设置为每次均为不重复的读取操作。此时服务器读取子文件内的一行数据的操作可以被替换为：

服务器不重复地读取子文件内的一行数据。

在读取出单个商品的属性数据之后，本申请实施例首先会提取出其中的行号(即第一行号)，得到该商品的行号，以及剩余的属性数据。

由于本申请实施例中要求必须提供的属性数据包括：商品的ID、名称、类目、图片地址和网页链接。因此若CP按照该要求提供商品数据的话，理论上此时剩余的属性数据即为该商品的ID、名称、类目、图片地址和网页链接。

S1072，服务器判断第一行号是否被处理过。若被处理过，返回执行S1071，以继续处理下一行数据。若未被处理过则执行S1073。

考虑到实际应用中，可能会存在一些意外情况，使得单行数据可能会被单个服务器多次处理。例如单行数据被重复划分至多个子文件中，且这些包含相同行数据的子文件被同一服务器处理的场景。又例如S1071中服务器重复读取了同一行数据的场景(此时没有设置不重复读取)。此时会导致单个商品的属性数据重复校验，使得商品数据校验效率降低。为了应对这些意外情况，考虑到行号是商品的唯一标识。因此服务器在解析出商品的行号之后，首先会判定自身是否处理过该行号。

若处理过，说明该商品的属性数据之前已经被校验过了。此时无需再校验。因此会重新选取一行数据，并开始对新选取的行数进行校验。

若未处理过，则说明需要进行商品属性数据的校验。因此此时会继续执行后续步骤。

S1073，服务器对第一数据进行属性数据解析。若解析失败，则判定当前行数据异常，将对应的异常信息上传数据库，并返回执行S1071。若解析成功，则得到第一数据内包含的所有属性数据，并执行S1074。

在行号校验通过后，本申请实施例会开始对第一数据进行属性解析，以判断第一数据的文本格式等是否合法。若可以正常解析并得到商品的ID、名称、类目、图片地址和网页链接。则说明第一数据的文本格式等合法。反之若解析失败，则说明第一数据的文本格式等不合法，无法正常解析还原。对于无法解析的情况，本申请实施例会将数据解析异常对应的异常信息上传至数据库。由数据对异常信息进行记录，以向CP反馈异常情况，帮助CP快速定位存在异常的商品，并重新提供相应商品的属性数据。

其中，本申请实施例不对异常信息的数据类型进行过多限定，可由技术人员根据实际需求设定。例如可以以文本形式描述具体的异常情况，如“数据解析异常”，并将文本作为异常信息。又例如，可以预先针对各种可能的异常情况设置对应的异常码，并将对应的异常码作为异常信息。例如可以设置解析失败对应的异常码为2203，此时异常信息可以是2203。亦可以是异常码加文本的形式作为异常信息。以下各个步骤中的异常信息数据类型亦是如此，本申请实施例不予赘述。

S1074，对解析得到的各个属性数据进行合法性校验。若存在合法性校验失败的属性数据，则判定当前行数据异常，将对应的异常信息上传数据库，并返回执行S1071。若对各个属性数据的合法性校验均通过，则执行S1075。

在解析成功之后，本申请实施例会对解析出的ID、名称、类目、图片地址和网页链接分别进行合法性校验。即判断各个属性数据是否存在数据缺失或者数据错误等问题。例如对于类目，假设预先将划分为了：服装、数码家电、鞋子、箱包、家居、玩具、美妆、配饰、食品和其它类。此时本申请实施例会校验填写的类目数据是否属于这几个分类。若属于，则可以判断对类目合法性校验通过。若不属于，则判定为校验失败。例如假设填写的是“裤子”，此时不属于上述分类，则判定为校验失败。或者填写的是“数码”，此时填写不完整，即存在数据缺失。亦属于校验失败。当校验失败时，本申请实施例会将数据解析异常对应的异常信息上传至数据库。由数据对异常信息进行记录。

其中，考虑到属性数据有多种，本申请实施例不对这些属性数据合法性校验的规则进行过多限定。可由技术人员自行设定。例如可以设置为依次对各个属性数据校验，或者同时对多个属性数据校验。并设置在有属性数据合法性校验失败时，停止校验并判定当前行数据异常。

作为本申请的一个可选实施例，合法性校验失败对应的异常信息，可以是文本“商品参数校验失败”。或者是异常码2204。亦可以是同时包含两者。

S1075，根据属性数据中的ID，判断行数据对应的商品是否已存在。若商品已存在，则判定当前行数据异常，将对应的异常信息上传数据库，并返回执行S1071。若商品未存在，则执行S1076。

考虑到实际应用中，若商品较多。CP在整理商品数据时可能会将同一商品的属性数据，多次记录至商品数据。此时可能会导致服务器对同一商品的重复校验，使得校验的效率降低。因此本申请实施例在对属性数据校验完成之后，服务器会根据商品的ID，判断是否判定自身是否处理过该ID的商品。

若处理过，说明该商品的属性数据被重复上传，且商品的属性数据之前已经被校验过了。此时无需再进行后续的校验。因此会重新选取一行数据，并开始对新选取的行数进行校验。且会将行数据异常对应的异常信息上传至数据库。由数据对异常信息进行记录。

若未处理过，则说明需要继续进行该商品的属性数据校验。因此此时会继续执行后续步骤。

作为本申请的一个可选实施例，商品已存在对应的异常信息，可以是文本“商品已存在”。或者是异常码2202。亦可以是同时包含两者。

S1076，根据图片地址下载商品图片。若下载失败，则判定当前行数据异常，将对应的异常信息上传数据库，并返回执行S1071。若下载成功则执行S1077。

在确认商品未被处理过之后，本申请实施例会尝试根据图片地址下载商品图片。

若下载失败，说明图片地址存在问题。如可能是图片地址错误，或者图片源被删除了。此时本申请实施例会将图片地址对应的异常信息上传至数据库。由数据对异常信息进行记录。

若下载成功，说明下载地址无误，此时会继续进行后续校验。

作为本申请的一个可选实施例，下载失败对应的异常信息，可以是文本“图片下载失败”。或者是异常码2303。亦可以是同时包含两者。

S1077，判断下载的商品图片体积是否超出预设体积阈值。若超出体积阈值，则当前行数据异常，将对应的异常信息上传数据库，并返回执行S1071。若未超出体积阈值，则执行S1078。

为了防止商品图片过大，导致对NSP存储空间占用过多，以及不方便用户下载查看等问题出现。本申请实施例会预先设置一个体积阈值，并要求CP提供的商品图片体积不得超出体积阈值。其中，体积阈值的具体值可由技术人员根据实际需求设定。例如可以设置为2兆。因此在下载商品图片之后，本申请实施例会判定商品图片的体积是否超出体积阈值。

若超出，则说明图片体积不符合要求。此时服务器会判定图片体积异常，并会将图片体积对应的异常信息上传至数据库。由数据对异常信息进行记录。

若未超出，则说明图片体积符合要求。此时会继续进行后续校验。

作为本申请的一个可选实施例，图片体积超出体积阈值对应的异常信息，可以是文本“图片过大”。或者是异常码2305。亦可以是同时包含两者。

S1078，识别商品图片的格式是否属于第一格式。若不属于第一格式，则判定当前行数据异常，记录异常信息，并返回执行S1071。若属于第一格式，则执行S1079。

考虑到实际应用中，图片具有较多种类的格式。但单台服务器和终端设备支持的图片格式往往较为有限。因此为了防止图片格式不支持，导致服务器无法处理商品图片，或者用户无法正常查看商品的图片的情况出现。本申请实施例会继续校验商品图片的格式是否合法。其中，本申请实施例会预先设置一种或多种格式作为合法格式(即第一格式)。此时即为识别商品图片的格式是否属于合法格式。若属于则判定为校验通过。若不属于，则判定为校验失败，图片商品图片格式异常。并会将图片格式对应的异常信息上传至数据库。由数据对异常信息进行记录。

例如，假设设置合法格式包括：jpg、png、bmp和gif。此时若商品图片格式属于这几种内的任意一种，则认为格式合法。反正若不是其中的格式，则认为商品图片格式异常，校验失败。

作为本申请的一个可选实施例，图片格式不属于合法格式对应的异常信息，可以是文本“不支持的图片格式”。或者是异常码2304。亦可以是同时包含两者。

S1079，将商品图片上传NSP。若上传失败，则判定图片上传异常，记录异常信息，并返回执行S1071。若上传成功，则执行S10710。

在完成对商品图片体积和格式等校验之后，本申请实施例会将商品图片上传至NSP进行存储。

当上传失败时，说明服务器和NSP之间的数据传输出现了问题。例如可能是NSP损坏，或者两者之间的网络不稳定。此时本申请实施例会将图片上传失败对应的异常信息上传至数据库。由数据对异常信息进行记录。

若上传成功，则继续进行后续操作。

作为本申请的一个实施例，为了提高上传成功的概率。若上传失败，可以多次尝试上传。若多次上传均失败，再判定图片上传异常。

作为本申请的一个可选实施例，图片上传失败对应的异常信息，可以是文本“系统异常”。或者是异常码1001。亦可以是同时包含两者。

S10710，将第一数据上传数据库。若上传失败，则判定数据入库异常，记录异常信息，并返回执行S1071。若上传成功，则判定当前行数据校验通过，并返回执行S1071。

在完成商品图片上传之后，本申请实施例会将商品的属性数据上传数据库。

当上传失败时，说明服务器和数据库之间的数据传输出现了问题。例如可能是两者之间的网络不稳定。此时本申请实施例会将属性数据上传失败对应的异常信息上传至数据库。由数据对异常信息进行记录。同时会从子文件中重新选取一个商品作为对象进行属性数据的校验。其中，由于异常信息的数据量较小，相对属性数据而言，上传数据库成功的概率较大。

若上传成功，则完成对当前校验商品的属性数据入库操作。此时会从子文件中重新选取一个商品作为对象进行属性数据的校验。

作为本申请的一个可选实施例，属性数据上传失败对应的异常信息，可以是文本“系统异常”。或者是异常码1001。亦可以是同时包含两者。

经由S1071-S10710的操作，可以实现对子文件内各个行数据的逐一处理。进而实现对子文件内各个商品属性数据的校验。相应的，若在S1073-S10710任意步骤中被判定为异常(包括行数据异常、图片上传异常和数据入库异常)，则本申请实施例均会判定当前校验的商品的属性数据中存在异常。即当前校验的商品校验未通过。若S1073-S10710均校验成功，则会判定当前校验的商品校验通过。

作为本申请的一个实施例，为了在完成对子文件内各个商品的属性数据校验之后，可以及时停止对当前子文件的校验。使得服务器可以继续执行其他任务。在S1071之后，还包括：

S10711，若子文件内所有的行数据均已被读取过，则判定对子文件校验完成。

在本申请实施例中，通过对行号、属性数据格式、属性数据合法性、ID、商品图片下载、商品图片体积、商品图片上传和属性数据入库依次进行校验。进而实现了对商品属性数据完整可靠的校验。同时还实现了对属性数据的入库，以及对异常信息的准确记录。

作为本申请的一个可选实施例，在向数据库存储属性数据或者异常信息时，可以同时向数据库发送处理商品的唯一标识，例如行号。此时，若在对子文件校验的过程中，由于意外因素导致子文件无法校验子任务执行超时。其他服务器在执行该子任务时，就可以根据行号从上一次校验的商品处继续进行校验。进而提高校验的效率，减少对商品属性数据重复校验的工作。

作为本申请的一个可选实施例，若结合图2C所示实施例，采用对子任务申请分布式锁的方式防止单个子任务被多次执行。此时为了防止服务器出现故障，导致子任务被自身长时间占据，使得对子任务执行效率降低。本申请实施例中，提供两种可选的应对方式：

1、服务器在获取到针对子任务的分布式锁后，会开始计时。当计时时长达到时长阈值，且子任务仍没有执行完成时。服务器会主动告知缓存组件释放对该子任务的分布式锁。此时其他服务器可以再次申请对该子任务的分布式锁，并处理该子任务。

2、缓存组件在将子任务对应的分布式锁分配给服务器后，会开始计时。当计时时长达到时长阈值时，会主动释放对该子任务的分布式锁。即对该子任务分布式锁的强制解锁。此时任意服务器均可以再次申请对该子任务的分布式锁，并处理该子任务。

实际应用中，技术人员可以选取上述2中应对方式中的任意一种或两种方式进行应用，实现对子任务超时的分布式锁自动解锁。使得单个子任务在执行异常时，可以及时自动释放，并由其他服务器结果。实现了对子任务的自动节点接管。进而使得对子任务执行的可靠性大大增强。

作为本申请的另一个可选实施例。考虑到实际应用中，当子任务数据量较大时，执行完子任务所需耗时较长。当该所需耗时长于时长阈值时，若以数据库获知子任务被服务器选择执行的时间作为最后更新时间，会出现虽然子任务正在被正常执行，但却被判定为执行超时的情况。

例如，假设正常执行子任务A需要6分钟，时长阈值设置为5分钟。同时假设数据库获知子任务A在12点整开始被服务器执行。此时若以仍以12点整作为子任务A的最后更新时间。会导致在12点5分后虽然子任务A正在被服务器正常执行，但却被数据库认为子任务A执行已超时。而超时又会导致子任务可能被多个服务器重复执行，进而导致处理效率降低。

为了防止数据库误判子任务执行超时。本申请实施例中，数据库在接收到商品的属性数据或者异常信息之后，一方面会对接收到的属性数据或者异常信息进行存储。以实现对属性数据的入库以及异常信息的记录。另一方面还会将接收到属性数据或者异常信息的时间，更新为该子任务的最后更新时间。从而实现对子任务执行时长的更新。

另外，作为本申请的一个可选实施例，为了方便向CP反馈商品数据的情况。在本申请实施例中，数据库针对每个父任务均可以创建一个任务细节(TaskDetai)表。并会在接收到异常信息时，将异常信息记录至任务细节表。在对商品数据全部子文件均校验完成之后，任务细节表中即完成了对商品数据对应的所有异常信息的记录。CP可以根据任务细节表明确得知商品数据中哪个商品的那些熟悉数据存在异常。并依此重新提供对应的属性数据。以提高对商品管理的效率。

作为本申请对子任务进行处理的一个可选实施例，对子任务进行处理的整体流程可以参考图2E。在本申请实施例中，采用了多个服务器负责对子任务进行并发处理。同时为了防止单个子任务被多个服务器重复处理，还引入了分布式锁。详述如下：

各个服务器向数据库获取子任务，并同步申请针对子任务的分布式锁。即进行抢锁。

抢锁成功的服务器，会作为S104-S107的执行主体(由于是多服务器并发处理子任务，因此针对每个子任务而言，作为S104-S107执行主体的服务器可以相同或不同)，从NSP中下载子任务对应的子文件。

在下载子文件后，对子文件进行校验。

在校验的过程中，下载商品图片，并将商品图片存储至NSP。同时还会在校验的过程中将子文件内商品的属性数据存储至数据库。从而实现对商品图片和属性数据的并发存储处理。

S108，服务器在将子文件内所有校验通过的商品的属性数据存储至数据库之后，判定对该子任务执行完成。并向数据库发送对子任务的状态更新指令，以将数据库中该子任务的执行状态更新为执行完成。

在得到单个商品的校验结果时(校验通过和校验未通过均视为得到校验结果)，本申请实施例会判定对该商品的校验完成。在对子任务内所有商品均校验完成之后，服务器会向数据库发送状态更新指令，告知数据库该子任务执行完成。数据库在接收到状态更新指令之后，会将该子任务的执行状态更新为执行完成。其中，状态更新指令内具体包含的内容此处不做过多限定

对应于校验通过和校验未通过两种校验结果，在本申请实施例中，子任务执行完成至少包括两种情况：

1、子任务执行完成，且子任务内所有商品的属性数据均校验通过。

2、子任务执行完成，但子任务内有商品存在属性数据异常，即存在商品属性数据校验未通过。

作为本申请的一个可选实施例。对于执行完成，且所有商品的属性数据均校验通过的子任务。可以选择在数据库中删除该子任务，以节省数据库存储空间。

作为本申请的一个可选实施例，若结合图2C所示实施例，采用对子任务申请分布式锁的方式防止单个子任务被多次执行。本申请实施例在判定对当前子任务执行完成之后，服务器会释放对该子任务的分布式锁。

S109，服务器在执行完成该子任务之后，继续向数据库发送任务查询请求。

服务器在执行完成当前子任务之后，会开始继续处理下一个子任务。因此此时会返回执行S104，重新向数据库发送任务查询请求。

S110，数据库在接收到任务查询请求后，识别父任务内各个子任务的执行状态。若父任务中所有子任务均执行完成，判定对商品数据入库结束，生成入库结果，并将入库结果发送至服务器。

S111，服务器将入库结果反馈给CP终端。

若存在未执行完成，例如有未执行的或者有执行中的。则此时执行S105的步骤。

在本申请实施例中，数据库在接收到任务查询请求之后，会识别父任务下各个子任务的执行状态。与父任务和子任务刚在数据库被创建时不同，此时已经有至少一个服务器执行过父任务下的子任务。因此对于父任务而言，存在两种可能的情况：

1、父任务下所有子任务均执行完成。

2、父任务下仍有没执行完成的子任务(包括未执行的和执行中的)。

对于父任务下仍有没执行完成的子任务，此时则需执行S105的操作，进行待执行的子任务。并执行S105-S109对应的操作。

对于父任务下所有子任务均执行完成的情况，此时说明对CP上传的商品数据全部完成了处理。其中，对于校验通过商品的属性数据，完成处理是指完成对属性数据的入库。对校验未通过商品的属性数据，完成处理则是指在数据库中记录了对应的异常信息。因此此时本申请实施例会判定当前对商品数据入库结束。

在确定入库结束之后，需要告知CP入库情况。因此入库结束后，数据库会确定父任务下各个子任务的实际执行情况，并生成对应的入库结果。其中，入库情况可能有以下几种：

1、商品数据内所有商品的属性数据均成功入库。此时可以将对应的入库结果设置为商品数据入库成功。

2、商品数据内，存在商品的属性数据异常。数据库记录了对应的异常信息。此时可以将对应的入库结果设置为部分商品数据入库成功，同时将记录的异常信息作为入库结果的一部分。当采用任务细节表记录异常信息时，则会将任务细节表作为入库结果的一部分内容。

在得到入库结果之后，数据库再将入库结果发送至服务器。由服务器将接收到的入库结果反馈给CP终端。最后再由CP终端将入库结果展示给CP查看。

其中，S110的操作，既可以是数据库自身完成，也可以是数据库所处终端设备完成。具体可由参考S105中的相关说明。

对于商品数据内所有商品的属性数据均成功入库的情况。此时CP实现了对商品数据的有效上传。而对于商品数据内，存在商品的属性数据异常的情况。此时CP可以查看入库结果中的异常信息(如有任务细节表，则可以直接查看任务细节表)。可以根据异常信息来确定存在异常的商品，并重新整理或检查这些异常商品的属性数据。再将这些属性数据作为新的商品数据，重新上传至NSP，以对异常商品的商品数据重新尝试入库。

在本申请实施例中，CP只需按照一定格式要求提供商品数据，该商品数据可以是结构化或非结构化的数据。当选用非结构化的商品数据时，CP可不对商品数据进行结构化处理。商品管理系统在接收到商品数据之后，会对商品数据进行数据拆分，得到多个子文件，并为各个子文件分别创建对应的子任务。随后利用一个或多个服务器，对各个子任务进行数据校验，并同步将子文件内的商品数据存储至数据库，将相应的商品图片存储至网络存储平台。使得入库的效率更高，实现了对商品数据的高效管理。同时，对属性数据逐步入库的操作，即为对商品数据结构化入库的操作。因此无论商品数据是结构化或非结构化的数据，本申请实施例均可以实现对商品数据的结构入库。

本申请实施例的数据管理过程中，CP只需按照格式要求提供商品数据，即可实现对商品数据的离线导入数据库(简称离线导入，离线是指用户上传后无需在线操作)。其中，CP可以不进行数据结构化处理操作。由于实际应用中CP原本就需要整理商品数据(无论是出于库存整理还是上架电商平台等目的，实际应用中CP一般都是需要整理商品数据的)，因此对CP而言，只需要将商品数据按照格式要求整理即可，无需付出过多额外的工作。相对现有技术而言，本申请实施例大大降低了CP操作的技术门槛，可用性更高。同时对商品数据自动化的校验和数据存储，也极大地提升了对商品数据的管理效率。

另外，当结合分布式锁进行应用时。通过分布式锁的特点，在使用多个服务器对子任务进行并发处理时，不用担心多个服务器同时处理同一子任务，导致对子任务处理效率过低的情况。因此本申请实施例可以实现对子任务高并发且高效的处理。而在分布式锁上锁时间过长时，服务器和缓存组件均会对子任务自动解锁。使得子任务可以被其他服务器重新申请上锁和处理，实现了对子任务的节点管理以及自动托管。此时可以防止服务器由于故障等原因，导致服务器无法正常处理子任务，使得子任务长时间无法正常执行的情况出现。使得对子任务处理的可靠性更高。

最后，利用商品数据拆分、支持多服务器并发处理和子任务异常自动托管等技术，本申请实施例可以实现对大批量商品数据的有效处理。因此本申请实施例可以支持对大任务场景的有效处理。而通过对商品属性数据异常信息的分析和反馈，可以实现对任务失败的详情展示，有利于CP针对性地补充异常的属性数据。提高了CP的操作效率。

作为本申请的一个可选实施例，S107中服务器对子文件进行属性数据校验的操作，是在校验的过程中同步实现对属性数据的入库和异常信息的记录。实际应用中，亦可以是先对子文件进行属性数据校验。并在对子文件校验完成后，再将子文件内属性数据和异常信息存储至数据库。参考图3A，此时S107可以被替换为：

S201，服务器对子文件内的各个商品进行属性数据校验。

S202，若对子文件校验完成，则将所述子文件中校验通过的商品的属性数据存储至数据库。对校验未通过的商品，则将记录这些商品的属性数据的异常信息，并将异常信息存储至数据库。

其中，具体对子文件的数据校验操作原理和细节等说明，均可以参考图2A所示实施例的相关说明。此处不予赘述。

需要说明地，在本申请实施例中，服务器在完成对子文件内各个商品的属性数据的校验之后。对校验通过的商品，其所有的属性数据均进行入库处理。而对于校验未通过的商品。则会记录属性数据的异常信息。并会将所有异常信息，一并发送至数据库。其中，对异常信息的说明，可以参考S107的相关说明，此处不予赘述。

应当特别说明地，本申请实施例可以和图2D所示实施例进行结合应用。此时本申请实施例首先会执行S1071-S10711的操作。并会在对子文件校验完成后，再次将属性数据和异常信息存储至数据库。

针对图2A所示实施例(以下称为实施例a)和图3A所示实施例(以下称为实施例b)进行对比分析。对于子文件的校验，在实施例a中，对单个子文件是边校验边进行商品属性数据入库，且每次均是以单个商品的属性数据为对象进行校验和入库。而实施例b中，对单个子文件则是全部校验完成之后才进行商品属性数据的入库。两个实施例之间存在以下几点差异：

1、校验精细度。在实施例a中，服务器每次均是以单个商品的属性数据为对象进行校验和入库。因此每次操作精细度为单个商品级别。而在实施例b之中，服务器则是在单个子文件校验完成之后才进行商品属性数据的入库。因此精细度是单个子文件级别。

由于单个子文件之中往往会包含较多商品的属性数据。因此实施例a的校验精细度要高于实施例b。

2、校验耗时，以及对网络资源的耗费。由于单个子文件中往往会包含商品的属性数据。因此在实施例a对单个子文件的校验过程中，服务器需要多次与数据库进行数据交互。这使得实施例a需要耗费较多的网络资源，且对服务器与数据库之间的网络连接质量要求较高。此外，多次数据交互，也会增加对子文件校验的耗时。因此与实施例b相比，实施例a的校验耗时较长、对网络资源的耗费较高，且对网络连接的质量要求也较高。

3、对服务器异常情况的应对。实际应用中，服务器在校验单个子文件的过程中，可能会出现掉电和宕机等异常情况。此时服务器可能会中止对子文件的校验。

针对实施例a而言，服务器理论上可以做到单个商品级别的属性数据校验操作和入库操作同步。因此在对子文件校验的过程中，数据库内也会同步存储对子文件内各个商品的属性数据或者异常信息。在此基础上，若服务器异常，此时数据库亦可以记录服务器异常之前，对当前子文件内所有校验过的商品属性数据。在此基础上。其他服务器在对该子文件重新进行校验时，可以选择从头开始校验，亦可以选择继续对该子文件内尚未入库的商品属性数据进行校验。

例如假设子文件a中有1000个商品的属性数据。并假设服务器会依次校验各个商品的属性数据，且在校验到第500个商品时出现异常(此时第500商品还未完成属性数据校验)，无法继续校验。此时，前499个商品的属性数据均以入库。其他服务器在对子文件a进行校验时，可以选择重新对1000个商品进行属性数据校验，亦可以选择从第500个商品开始重新进行属性数据校验。

针对实施例b，服务器若出现异常情况导致无法对当前子文件继续进行校验，会使得数据库无法获取到当前子文件内的属性数据。因此其他服务器需要重新对该子文件进行完整的校验。

综上，对于服务器异常的情况，相对实施例b，实施例a理论上可以减少对子文件重复校验的概率，进而减少对子文件校验的工作量，实现对服务器异常情况的有效应对。

基于上述几点差异，技术人员可以结合实际应用需求来选取实施例a或者实施例b进行商品数据的校验和入库。此处不做过多限定。

针对部分一：商品管理系统对商品数据的管理操作的几点补充说明。

(一)、可以对CP展示商品数据离线导入进度。

在图2A至图3A所示实施例的基础上，为了方便CP了解对商品数据的入库情况。在本申请实施例中会由服务器对商品数据离线导入的进度进行统计，并反馈给CP终端。详述如下：

服务器向数据库发送进度查询请求。

数据库在接收到进度查询请求后，获取父任务下执行完成的子任务第一数量，以及父任务下包含的所有子任务第二数量。

数据库根据第一数量和第二数量，生成进度数据，并发送至服务器。

服务器将进度数据发送至CP终端。

CP终端对进度数据进行展示。

在本申请实施例中，服务器可以向数据库发送进度查询请求。数据库再接收到该请求之后，会对请求进行响应。即会获取父任务下执行完成的子任务数量(即第一数量)和子任务的总数量(即第二数量)。并会根据这两个数量来生成进度数据。再发送给服务器，由服务器发送给CP终端进行展示。

其中，服务器可以是以一定规则主动查询，例如定时查询，或者周期查询等。也可以是对CP主动发起的查询进行响应。此时需要CP在CP终端中进行操作。由CP终端向服务器发送查询请求。再由服务器向数据库进行查询。

同时，本申请实施例不对离线导入进度的表征方式进行过多限定。因此，对应的进度数据的格式和分析方法等，此处亦不做限定。可由技术人员根据实际需求设定。例如，可以以百分比的方式表征离线导入进度。此时进度数据即为父任务下执行完成的子任务数量占子任务的总数量百分比。例如假设父任务下共有20个子任务，其中，有10个子任务执行完成。此时进度数据即为(10÷20)×100％＝50％。又例如，亦可以采用“执行完成的子任务数量/子任务的总数量”的方式表征离线导入进度。此时数据库无需对执行完成的子任务数量和子任务的总数量进行处理。并可以将两个数量值作为进度数据反馈至服务器。此种情况下，CP终端可以以“执行完成的子任务数量/子任务的总数量”的方式展示进度。例如假设父任务下共有20个子任务，其中，有10个子任务执行完成。此时CP可以以“10/20”的方式展示离线导入进度。

本申请实施例实现了对商品数据离线导入的进度反馈，使得CP可以及时获知进度情况。

(二)、图2A至图3A所示实施例，亦可用于商品数据的在线管理。

在本申请实施例中，商品数据在线管理包括对商品数据的增加、删除、修改和查询。其中，增加、删除和修改，是指在已入库商品数据的基础上，加入新商品的属性数据、删除已有商品的属性数据和修改已有商品的属性数据。查询是指，在已入库商品数据的基础上，查询已有商品的属性数据。

在CP所需管理的商品数量较多时，可以优先采用图2A至图3A所示实施例实现对商品数据的离线导入和管理。此时CP可以在将商品数据上传商品管理系统之后等候一段时间，即可实现对商品数据的入库和管理。而在所需管理的商品数据较少时，例如仅有几件或者十几件商品需要进行商品数据入库管理时。一方面可以采用图2A至图3A所示实施例实现对商品数据的离线导入。此时图2A至图3A所示实施例会进行商品数据的处理，但由于商品数量较少，此时商品数据的拆分极有可能仅会有一个子文件产生(即不用进行拆分，直接将商品数据作为一个子文件处理)。因此此时处理的步骤会相对简单一些。另一方面，考虑到商品数量较少，商品数据结构化的操作难度较低。因此也可以采用现有技术，先进行商品数据的结构化处理，再上传至存储桶。

综上，CP实际采用的商品数据入库管理方法，可由CP根据需求自行选定，此处不做过多限定。但应当理解地，图2A至图3A所示实施例可以同时适用于商品数量较多或较少的全场景需求。

作为本申请一个可选实施例，服务器向CP终端提供可调用的API。并支持Java、PHP、C++、Python等多种语言的软件开发工具包(Software Development Kit，SDK)。

参考图3B，商品管理系统为CP提供商品管理服务(即图2A至图3A所示实施例实现的商品管理)，同时为用户提供商品的在线搜索服务。CP通过CP终端调用服务器API，触发商品管理系统的商品管理服务，以完成对商品数据的在线管理。其中，当需要商品数据增加时，可以采用图2A至图3A所示实施例中的任一实施例实现。其中，当商品数据较少时，可以不进行子文件拆分。由服务器API直接完成对商品数据内各个属性数据的校验。并实现对属性数据入库和异常信息记录等操作。

而对于删除、修改和查询的操作，则CP可以通过CP终端调用服务器API，告知服务器所需操作的商品，以及具体的操作内容。服务器在获知操作的商品和操作的内容之后。再根操作内容，对数据库中的商品进行操作。例如可以对对数据库中商品A的价格进行查询获知修改，或者删除数据库中商品A的所有属性数据。

作为本申请的一个可选实施例，图3C是一种基于图3B所示实施例的商品管理系统服务场景交互图。本申请实施例的一方面，CP可以根据需求来操作CP终端，利用CP终端调用服务器API，触发商品管理系统的商品管理服务。商品管理系统在商品管理服务触发后，会基于CP终端的实际操作，来进行商品数据的关联，并将管理结果告知CP终端。例如对商品数据的删除、修改和查询的操作结果。而另一方面，用户可以根据需求操作用户终端，通过用户终端向商品管理系统输入商品文本或商品图片，触发商品管理系统的在线搜索服务。商品管理系统在接收到用户终端发送的商品文本或商品图片后，会基于接收到的商品文本或商品图片进行商品在线搜索，并会将在线搜索结果返回至用户终端，以供用户查看。

(三)、对图2A至图3A所示实施例中的服务器说明如下：

在本申请实施例中，存在多处需要服务器作为执行主体的操作，具体操作至少包括以下4组：

1、对商品数据进行拆分，将子文件上传NSP，以及在数据库中创建父任务和子任务。如S102-S103。

2、对子任务进行查询、子文件进行下载、校验以及属性数据入库。如S104、S106、S1061-S1063、S107、S1071-S10711、S108-S109以及S201-S202。

3、将入库结果发送至CP终端。包括S111。

4、对商品数据进行在线管理。包括补充说明点(二)。

实际应用中，有两种可选的方式来实现图2A至图3A所示实施例：

a、仅使用一个服务器来实现上述4组操作。

b、设置多个服务器共同完成上述4组操作。

针对方式a，此时图2A至图3A所示实施例中所有服务器均是同一服务器。适用于CP和商品数据较少的场景。此时服务器的成本较低。

针对方式b，可适用于CP和商品数据较多的场景。此时利用多个服务器共同处理，可以实现对商品数据的多并发处理，提高商品数据管理的效率。相应的，上述4组操作中，每组操作的执行主体均可以是多个服务器中的任一服务器。其中，本申请实施例不对每组操作具体执行主体的确定方式进行过多限定。可由技术人员根据实际需求设定。

例如，对于操作1：对商品数据进行拆分，将子文件上传NSP，以及在数据库中创建父任务和子任务。在一些可选实施例中，可以从设置的多个服务器中选取出一个服务器负责执行操作1。此时无论哪个CP上传商品数据，均会由该服务器进行商品数据拆分、子文件上传和任务创建处理。而在另一些可选实施例中，也可以设置为每次有CP上传商品数据时。随机从多个服务器中选取出一个服务器负责执行操作1。例如，可以引入分布式锁机制，此时各个服务器会同步向缓存组件申请针对商品数据的分布式锁。每次仅由抢到分布式锁的服务器来执行操作1。

对于操作2：对子任务进行查询、子文件进行下载、校验以及属性数据入库。与操作1类似的，在一些可选实施例中，可以从设置的多个服务器中选取出一个服务器负责执行操作2。此时无论哪个CP上传商品数据，均会由该服务器进行子任务进行查询、子文件进行下载、校验以及属性数据入库。而在另一些可选实施例中，也可以设置为在有子任务等待执行时，多个服务器同步查询子任务并进行处理。此时可以实现对子任务的高并发处理。例如，可以引入分布式锁机制，此时各个会同步向缓存组件申请针对子任务的分布式锁。对于单个子任务而言，可以由抢到对应分布式锁的服务器来执行。

针对操作3：将入库结果发送至CP终端。与操作1类似的，在一些可选实施例中，可以从设置的多个服务器中选取出一个服务器负责执行操作3。此时数据库会将入库结果发送至该选取出的服务器，以发送至CP终端。而在另一些可选实施例中，也可以设置为数据库每次得到入库结果时，随机从多个服务器中选取出一个服务器，并将入库结果发送至该服务器。

针对操作4：对商品数据进行在线管理。与操作1类似的，在一些可选实施例中，可以从设置的多个服务器中选取出一个服务器负责执行操作4。此时CP终端会告知该服务器每次所需操作的商品，以及具体的操作内容。由该服务器实现对商品数据的在线管理。而在另一些可选实施例中，也可以设置为每次将CP终端的数据随机发送给多个服务器中的一个服务器，并由该服务器实现对商品数据的在线管理。

部分二：用户进行商品搜索。

在部分一实现对商品数据管理的基础上，为了方便用户查找商品，实现对商品的曝光。本申请实施例会为用户提供商品搜索功能。用户可以根据需求上传商品相关的文本或者图片至商品管理系统。由商品管理系统基于用户上传的文本或图片进行商品搜索和搜索结果反馈。具体而言，商品搜索可以分为搜索前和搜索中两个阶段，详述如下：

(一)、搜索前。

在搜索前，首先需要对商品图片进行图像特征分析，并得到用于图片搜索的图像特征数据。在本申请实施例中，图像特征分析的操作可以发生在以下两个阶段：

阶段1、在图2A至图3A所示实施例对子文件校验过程中，同步对商品图片进行图像特征分析。

阶段2、在图2A至图3A所示实施例完成对商品数据入库之后，对存入NSP的商品图片进行图像特征分析。

实际应用中，技术人员可以根据需求设定为上述两个阶段中的任一阶段进行图像特征分析。

例如，若设定为阶段1进行图像特征分析。图2A至图3A所示实施例中，服务器在完成对单个子文件进行校验时，对校验通过的商品，会对相应的商品图片进行图像特征分析。并会将得到的图片特征数据存储至特征库之中。而若设置为阶段2进行图像特征分析。则可以由服务器在对子文件校验完成之后，对校验通过的商品的商品图片进行图像特征分析。并会得到的图片特征数据存储至特征库之中。

图像特征分析的操作中，对各张商品图片的操作均相同，其中对单张商品图片的操作，包括：

S301，服务器获取商品图片，对商品图片进行图像特征分析，并将得到的图像特征数据存储至特征库。

首先应当说明地，本申请实施例中的服务器，可以是对子文件进行校验的服务器。也可以是其他服务器。具体可由技术人员根据需求设定，此处不予限定。相应的，根据服务器的情况以及图像特征分析发生的阶段不同，商品图片“获取”的方式也可能存在差异。例如，当是执行子文件校验的服务器实现S301时。获取可以是指服务器读取已下载的商品图片(参考S106，此时服务器已经通过图片下载地址下载了商品图片)。而对于本地不包含商品图片的情况，则需从NSP中下载商品图片。此时获取则是指从NSP下载商品图片。

另外，本申请实施例不对具体的图像特征分析方法做过多的限定，可由技术人员根据实际需求确定。例如可以预先训练一些基于神经网络或深度学习的图像特征提取模型，以进行图像特征分析。而图像特征数据的数据类型和包含的内容，则需根据具体的图像特征方法确定。例如，可以是图像特征点和描述特征点信息的特征向量，或者是图像特征向量，如1024维浮点型图像特征向量。亦可以是其他特征数据。

作为本申请的一个可选实施例，考虑到每种类目下的商品特征是具有一定共性的。例如同类目下商品的形状往往较为相似。因此为了提升图像特征分析的效果，使得得到图像特征数据可以更好地表征商品。在本申请实施例中，可以针对不同类目的商品预先设计不同的图像特征提取模型。在进行图像特征分析时，则根据商品实际所属类目(此时商品数据中需包含商品的类目)来选择对应的模型，并进行分析。

以一实例进行举例说明。假设将商品类目分为：服装、数码家电、鞋子、箱包、家居、玩具、美妆、配饰、食品和其它类共10种类目。此时可以针对10种类目分别设计一个图像特征提取模型，得到对应的10个模型。而在对商品进行图像特征分析时，则先根据商品数据中的类目，来确定当前商品对应的图像特征提取模型。再利用该图像特征提取模型来对当前商品进行图像特征分析，得到图像特征数据。

作为本申请的一个可选实施例，为了提高图片搜索的准确性，本申请实施例会同时引入商品信息作为辅助进行商品图片的图像特征分析。详述如下：

本申请实施例会预先训练基于神经网络的图像特征分析模型，并基于该图像特征分析模型来对商品数据进行分析，得到对应的图像特征数据。其中，针对不同类目的商品，可以分别设置对应的图像特征分析模型。

图像特征分析模型的训练流程包括：

预先设置一个初始模型。

获取多个样本商品的商品图片和对应的商品信息，将这些商品图片和商品信息作为样本数据，并为每张商品图片和每个商品信息添加对应样本商品的分类标签。

利用初始模型对作为样本数据的商品信息进行特征提取，并根据提取出的文本特征和对应的分类标签，计算对商品信息的第一损失函数。其中，文本特征可以是词向量，亦可以是其他文本特征。提取方法此处不做过多限定，例如可以对商品信息进行分词，并利用文本嵌入等方法得到词向量。可以先利用全连接层等对文本特征进行处理分类，再基于分类结果和分类标签来计算损失函数。

利用初始模型提取作为样本数据的商品图片的图像特征，并根据图像特征和对应的分类标签，计算对商品图片的第二损失函数。可以先利用全连接层等对图像特征进行处理分类，再基于分类结果和分类标签来计算损失函数。

基于第一损失函数和第二损失函数计算第三损失函数，并根据计算出的第三损失函数值迭代更新初始模型，直至满足预设收敛条件，得到训练完成的模型。

将训练完成的模型中，用于商品图片特征提取的各个网络提取出来，并得到由这些提取出的网络构成的图像特征分析模型。

其中，第一损失函数、第二损失函数和第三损失函数的具体损失函数类型此处不予限定，可由技术人员根据需求自行设定。例如第一损失函数可以是图像三元损失函数(Image Triplet Loss)或图像类损失函数(Image Class Loss)，亦可以是其他损失函数。第二损失函数可以采用文本类损失函数(Text Class Loss)，亦可以是其他损失函数。第三损失函数可以是Kullback-Leibler损失函数。亦可以是其他损失函数。

在本申请实施例中，采用分类模型的训练方式，分别对样本商品的商品图片和商品信息进行处理。在得到两个维度的损失函数之后，再进行多模融合的模型训练。即将两个维度的损失函数值通过一个新的损失函数进行融合，并基于融合得到的损失函数值来进行模型的迭代更新。最后将训练完成的模型中，用于商品图片特征提取的各个网络提取出来(即舍弃商品信息特征提取部分的网络)，组成一个新的用于图像特征分析的模型。实践证明，基于这一方法训练出图像特征分析模型，可以实现对商品图片特征更准确可靠的提取，得到的图像特征数据对商品图片具有较好的表征作用。基于这个图像特征分析模型提取出的图像特征数据，在进行商品图片匹配时，准确率较高。

在得到图像特征分析模型的基础上，本申请实施例会利用该图像特征分析模型对各个商品图片进行分析，从而得到对应的图像特征数据。

作为本申请的一个可选实施例，考虑到实际应用中CP在拍摄商品图片时，很大概率会拍摄到一些商品以外的物体。此时商品图片中可能会包含多个物体。因此若直接对商品图片进行特征分析，得到的是同时包含其他物体的图像特征数据，不利于后续的图像匹配。因此本申请实施例会在图像特征分析之前，先对商品图片进行商品检测。参考图4A，此时S301可以被替换为：

S3011，服务器获取商品图片，对商品图片进行商品检测，并根据检测结果截取出商品图像。

S3012，服务器对商品图像进行图像特征分析，并将得到的图像特征数据存储至特征库。

其中，本申请实施例不对商品检测(实质即为物体识别)的方法进行过多限定，可由技术人员根据实际需求设定。例如在一些实施例中，可以先利用一些物体定位方法来定位出商品图片中包含的所有物体。例如可以使用opencv提供的一些物体定位算法，亦可以使用SSD算法或一些基于深度学习的物体定位模型，来实现物体定位。考虑到拍摄商品时，一般会将商品置于拍摄设备的镜头前。因此在定位出各个物体之后，可以将其中占据像素点面积最大的物体识别为商品，并截取商品目标框内的图像即可。

作为本申请的一个可选实施例，考虑到实际应用中，截取出的商品图像的大小无法预先确定。此时若直接对商品图像进行图像特征分析，可能会导致图像特征数据情况的不可控。不利于后续的图像特征匹配等操作。因此在本申请实施例中，可以在S3012之前先对商品图像进行长宽像素补齐，使得商品图像长宽相同。再将商品图像缩放至预设尺寸，例如299×299大小。最后将缩放得到的商品图像作为S3012的图像特征分析对象。此时得到的图像特征数据，其数据量较为可控。

作为本申请的一个可选实施例，实际应用中，S3011中商品检测的操作亦可以由CP或者技术人员手动完成。此时CP或技术人员可以手动将商品图片中的商品框选出来。并由服务器进行商品图像的截取。

作为本申请的另一个可选实施例，考虑到实际应用中，商品的数量往往较多。特别是有较多CP使用商品管理系统时，商品的数量更是会成倍增长。相应的，对商品图片特征分析得到的图像特征数据的数据量也会急剧增加。使得特征库的数据存储压力较大。为了减小特征库的数据存储压力，以减小特征库成本。本申请实施例在得到图像特征数据之后，还会对图像特征数据进行压缩。再将压缩后的图像特征数据存储至特征库。其中，本申请实施例不对图像特征数据的压缩方法做过多限定，可由技术人员根据需求设定。例如可以是降低图像特征数据的精度，以减小数据体积。

作为本申请中图像特征数据压缩的一种可选实施例，压缩方法可以是以下方法中的任意一种：

1、主成分分析(Principal Component Analysis，PCA)降维法，将图像特征数据的维度由1024维降至512维、256维或者128维的浮点数据；

2、将图像特征数据中的数值类型，由浮点型转化为无符号整型(Uint8)，维度可以保持不变。

3、采用深度哈希(Hash)训练方法，将浮点型图像特征数据转化为二值图像特征数据。

作为本申请的一个可选实施例，参考图4B的离线流程部分，是一种搜索前对商品图片进行图像特征分析的方法流程示意图。说明如下：

服务器从商品数据中获取商品图片，并添加一个用于进行商品图片搜索的API。

服务器对商品图片进行商品检测，并根据检测结果截取出商品图像。

服务器对商品图像进行图像特征分析，得到图像特征数据。

服务器对得到的图像特征数据进行特征压缩，并将特征压缩后的图像特征数据存储至特征库。

具体的操作细节，可参考S103、S3011-S3012以及上述图像特征数据压缩的实施例相关说明，此处不予赘述。

(二)、搜索中。

在完成对商品图片的图像特征数据存储的基础上，本申请实施例中的商品管理系统会为用户提供商品搜索功能。其中商品搜索包括文本搜索和图片搜索。相应的，为了实现文本搜索和图片搜索。在本申请实施例中，要求CP上传的商品数据中，需包含商品图片或者商品图片的下载地址。

在商品搜索过程中，用户可以通过用户终端向商品管理系统发起商品搜索请求，上传待搜索的商品图片或者商品文本(即商品相关的描述文本)。商品管理系统在接收到待搜索的商品图片或者商品文本之后，会以此对已存储的商品数据进行搜索，确定出一个或多个匹配的商品。再将匹配成功商品的属性数据和商品图片返回给用户终端。由用户终端进行显示。

作为本申请的一个可选实施例，商品搜索的逻辑架构示意图可以参考图4C或图4D。其中，商品管理系统负责对商品信息的实时管理，包括商品的增加、删除、修改和查询，以及商品数据的离线导入。具体包括对商品图片和商品文本的搜索，以及对商品数据的入库(即生成商品信息和存储商品信息)。

图4C中，用户终端可以直接将待搜索的商品图片或者商品文本上传至商品管理系统。由商品管理系统进行商品搜索和商品列表结果返回。图4C的右半部分，是指商品管理系统可为各个电商伙伴提供商品数据管理支持。即电商伙伴可以作为CP将商品数据上传至商品管理系统。由商品管理系统利用图2A至图3A所示的各个实施例实现对商品数据的入库管理。

在图4C的基础上，图4D中多设置了一个商品分发服务层。该商品分发服务层主要对接媒体入口。用户终端通过媒体入口将待搜索的商品图片或者商品文本上传至商品分发服务。由商品分发服务对各个用户终端上传的商品图片或者商品文本统一进行管理，并发送给商品管理系统请求进行商品匹配，以实现商品搜索。还负责将商品管理系统生成的商品列表返回至用户终端。考虑到实际应用中在用户数较多时，商品搜索的工作量可能会比较大。因此通过增加一个对接媒体入口并统一管理商品搜索请求，可使得对用户商品搜索的管理和响应更为高效可靠。实际应用中，商品分发服务可以交由一个专用的服务器实现。亦可以从商品管理系统设置的多个服务器中随机选取出一个服务器实现。具体可由技术人员根据实际需求设定，此处不予限定。

对于文本搜索和图片搜索的详述如下：

a、文本搜索。参考图5A，文本搜索的流程包括：

S401，用户终端将用户输入的商品文本发送至服务器。

作为本申请实施例执行主体之一的服务器，是商品管理系统中负责进行商品搜索的服务器。具体而言，该服务器可以是技术人员预先在商品管理系统中选定的一个服务器。也可以是从商品管理系统内包含的一个或多个服务器中，按照一定规则自动选取出的一个服务器。例如可以随机选取。此处不做过多限定。

在本申请实施例中，会用户终端提供商品搜索功能。用户在需要进行商品搜索时，可以启用该商品搜索功能，并输入待搜索的商品文本或者上传对应的商品图片。

其中，商品搜索功能可选的提供方式至少包括以下几种：

1、集成在用户终端本地的搜索功能之中，例如常见的手机负一屏搜索。

2、将商品搜索功能设置于App或网页之中，用户在使用App或者网页时，可以启用其中包含的商品搜索功能。

以一实例进行举例说明，可以参考图5B，此时用户终端为手机。

其中，图5B中的(a)，是将商品搜索功能以输入框的形式集成于手机的本地搜索功能之中。用户在需要时可以打开该功能。例如，可以将商品搜索功能放置于手机负一屏。当用户打开负一屏时，则开启商品搜索功能，并显示对应的输入框。

此时用户可以在输入框中输入商品文本，或者上传商品图片。手机在获取到用户输入的商品文本或者商品图片之后，则会将商品文本或者商品图片上传至商品管理系统内的服务器之中。

图5B中的(b)，是将商品搜索功能以输入框的形式集成于手机的网页之中。用户可以在手机浏览器中访问该网页，并在网页输入框中输入商品文本，或者上传商品图片。网页在获取到用户输入的商品文本或者商品图片之后，则会将商品文本或者商品图片上传至商品管理系统内的服务器之中。

在本申请实施例中，以用户输入了商品文本为例，来进行文本搜索的说明。其中，商品文本是指对商品相关的描述文本。其既可以是一段话，也可以是一些关键词。例如商品的名称、特点或品牌等。实际应用中，商品文本是用户根据自身对待搜索商品的已知情况输入的文本。因此商品文本的实际内容需根据实际应用场景确定。例如在一些可能场景中，可以是如“短裤”、“裙子”或“面包”等关键词，亦可以是如“5G全面屏手机，5000万四摄”等语句。

S402，服务器根据商品文本，对数据库内各个商品的商品信息进行文本匹配，并筛选出文本匹配度最高的前n个商品的第一商品信息。其中，n为正整数。

在得到商品文本之后，本申请实施例中服务器会基于商品文本对数据库内各个商品的商品信息进行文本匹配。进而得到各个商品与商品文本的匹配度。其中，本申请实施例不对文本匹配的方法进行过多限定，可由技术人员根据实际需求设定。例如，可以采用基于语义分析的文本匹配方法，如一些基于神经网络的语义匹配模型。或者采用基于字符的文本匹配方法，如暴力(Brute Force，BF)算法、字符串匹配(Rabin-Karp，RK)算法和字符串查找(Knuth-Morris-Pratt，KMP)算法。

考虑到实际应用中，对用户搜索反馈的商品数不宜过多。因此在计算出各个商品文本与各个商品信息的文本匹配度之后，本申请实施例会从中筛选出部分文本匹配度较高商品，并将对应的商品信息(即第一商品信息)作为匹配结果。其中，具体筛选的商品信息数量n此处不予限定，可由技术人员自行设定。例如可以设定为10～20，或者20～100中的任意值。

作为本申请的一个可选实施例，考虑到实际应用中数据库内存储的商品数量可能极多。此时直接进行文本匹配工作量较大。为了减少文本匹配的工作量，提高匹配效率。在本申请实施例中，会先对商品进行类目筛选。此时S402可以被替换为：S4021-S4022。

S4021，服务器对商品文本进行商品的类目识别，得到对应的第一类目。

在本申请实施例中，会要求CP在商品数据中提供商品的类目属性数据。相应的，此时数据库存储的商品信息中，会记录有每个商品所述的类目。其中，本申请实施例不对类目的具体分类规则做过多限定，可由技术人员预先设定并告知CP。

服务器在接收到商品文本之后，首先会进行商品类目的识别，即确定用户所需搜索的商品具体属于那个类目。本申请实施例不对具体的类目识别方法进行限定，可由技术人员自行设定。例如可以采用关键词匹配的方法。即由技术人员提前设置好各个类目下常见的一些关键词。这些关键词可以以商品名词列表的方式进行记录。例如假设类目中包含“服装”。此时可以在“服装”类目下设置一些如“衣服”、“上衣”、“裤子”和“裙子”等相关的关键词。在获取到商品文本之后，再对商品文本进行关键词查找。并将查找到的关键词所属的类目，作为商品文本对应的类目(即第一类目)。

S4022，服务器根据商品文本，对数据库中第一类目下的商品，进行商品信息的文本匹配，并筛选出文本匹配度最高的至少一个商品的第一商品信息。

在确定出商品文本对应的类目之后，服务器仅会对数据库中该类目下的商品进行商品信息文本匹配。例如假设商品文本对应的类目为“服装”。此时服务器仅会对数据库中，“服装”类目下的商品进行商品信息文本匹配。并得到这些商品对应的文本匹配度。

S403，服务器从数据库中获取第一商品信息内的属性数据，从NSP中获取第一商品信息关联的商品图片。根据获取到的属性数据和商品图片生成商品列表，并将商品列表发送至用户终端。

参考图5A，S403可以细化为S4031-S4033：

S4031，服务器从数据库中获取第一商品信息内的属性数据。

S4032，服务器从NSP中获取第一商品信息关联的商品图片。

S4033，服务器根据获取到的属性数据和商品图片生成商品列表，并将商品列表发送至用户终端。

在筛选出商品信息之后，本申请实施例还会从数据库中下载这些商品信息内包含的属性数据，并从NSP中获取商品信息对应的商品图片。并会将获取到的属性数据和商品图片发送至用户终端。

其中应当说明地，商品信息中包含商品较多的属性数据。但实际应用中，一些属性对用户而言可能并不重要。例如假设商品信息中包含商品图片的下载地址。由于本申请实施例会从NSP中下载商品图片。因此下载地址对用户而言并不重要。基于这一原因，在本申请实施例中，下载的属性数据可以是商品信息内包含的部分或全部属性数据。具体包含的属性数据内容可由技术人员根据实际需求设定。例如可以设置为下载的属性数据包含商品的：名称、价格和链接。若商品信息内包含对商品的描述，亦可以作为下载的属性数据之一。其中，链接可以是网页链接、App链接和快应用链接中的任意一种或多种，用于跳转至对应的网页(包括Html5页面)、App页面或者快应用页面，实现商品的展示。在本申请实施例中，将链接指向的网页、App页面和快应用页面，统称为商品展示页面。

可以理解地，本申请实施例并未对链接指向的商品展示页面所属的电商平台进行过多限定。理论上CP可以根据自身与不同电商平台的合作情况，来设置商品的链家。因此实际应用中，商品的链接所指向的商品展示页面，可以是一种或多种不同电商平台内的商品展示页面。在此基础上，用户可以根据实际需求来点击链接，从而跳转到不同电商平台的商品展示页面。或亦可以预先设置不同的链接优先级，并由用户终端自动调整到优先级较高的链接所指向的商品展示界面。

例如，假设CP1在电商平台A和电商平台B中均销售商品A，即在电商平台A和电商平台B中具有相应的商品展示页面。同时电商平台A和电商平台B，均具有相应的网站、App和快应用。此时CP可以在商品数据中设置电商平台A和电商平台B在网站、App和快应用中分别对应的链接。即总共可以设置至少6条链接。

在得到属性数据和商品图片之后，本申请实施例会以单个商品为单位进行属性数据和商品图片的排序。即先按照一定的规则对各个商品进行排序，并按照商品的顺序来对商品的属性数据和商品图片进行排序。在完成排序之后，将单个商品的属性数据和商品图片放置于同一行，且不同商品的属性数据和商品图片处于不同行，从而得到由排序后的属性数据和商品图片构成的商品列表。再将商品列表作为对商品文本的搜索结果，返回至用户终端。

S404，用户终端对商品列表进行显示。

用户终端在接收到商品列表之后，在屏幕中对商品列表进行显示。使得用户可以看到商品文本的搜索结果。其中，本申请实施例不对商品列表的展示方式做过多限定。可由技术人员根据需求自行设定。

作为本申请的一个可选实施例，可以针对商品列表中每个商品均生成一张卡片，并将商品列表中该商品的属性数据和商品图片，放置在同一卡片中进行显示。此时，可以在用户终端显示屏中显示各个商品一一对应的卡片。

以一实例进行举例说明。可以参考图5C，在图5B中的(a)所示实施例的基础上。假设用户输入商品文本为“红酒杯”。搜索结果中包含4个商品，每个商品均具有商品名称、价格和链接三种属性数据，且具有对应的商品图片。此时本申请实施例针对每个商品均生成了一张卡片。同时会在卡片中显示商品图片和各个属性数据。

作为本申请的一个可选实施例，若商品列表中包含商品的链接。本申请实施例会将各个链接以控件的方式在卡片中显示。当检测到用户对链接的点击操作，则用户终端跳转到链接指向的商品展示页面。

在实现对商品列表的显示基础上，若商品列表中包含商品的链接，且用户点击了该链接。则用户终端会打开链接对应的商品展示页面。当链接为网页链接时，是指启动浏览器，并打开用于商品展示的网页。当链接为App链接时，是指启动对应的App，并从App中打开用于商品展示的App页面。当链接为快应用链接时，则是指启动对应的快应用，并从App中打用于开商品展示的快应用页面。

以一实例进行举例说明。可以参考图5D，在图4C所示实例的基础上。假设用户点击了第一个商品卡片中的网页链接1(参考图5D中的(a))。此时用户终端会启动浏览器，并打开用于商品展示的网站页面(参考图5D中的(b))。此时用户可以在打开的网页中了解商品详情，并可以进行购买等操作。

作为本申请的另一个可选实施例，为了满足CP与不同电商平台的合作需求，以及对用户的使用体验。在本申请实施例中，可以由技术人员或者CP预先设置好不同链接之间的优先级。用户终端在接收到包含链接的商品列表之后，不对链接本身进行显示。可以参考图5E中的(a)，在图5B中的(a)所示实施例的基础上。假设用户输入商品文本为“红酒杯”。搜索结果中包含4个商品，每个商品均具有商品名称、价格和链接三种属性数据，且具有对应的商品图片。此时本申请实施例针对每个商品均生成了一张卡片。同时会在卡片中显示商品图片，以及除链接以外的各个属性数据。

在实现对商品列表的显示基础上，若商品列表中包含商品的链接，且用户点击了该商品对应的卡片。则用户终端会打开优先级最高的链接指向的商品展示页面。若打开失败，则会尝试打开优先级次高的链接指向的商品展示页面。以此类推，直至成功打开一个商品展示页面位置。

以一实例进行说明。假设技术人员预先设置的链接优先级从高到底为：电商平台App链接、快应用链接和网页链接。参考图5E中的(a)，假设用户点击了第一个商品。此时用户终端会按照电商平台App链接、快应用链接和网页链接的顺序，依次判断是否有对应的链接。即若该商品有电商平台App链接。参考图5E中的(b)，此时用户终端会启动电商平台App，并跳转到对应的页面。而若该商品仅有网页链接，则可以参考图5E中的(c)。此时用户终端会启动浏览器，并跳转到对应的页面。其中，若用户终端中没有链接对应的App、快应用或浏览器，则会出现链接跳转失败。此时本申请实施例会重新选取一个优先级次高链接进行跳转。

在本申请实施例中，用户可以通过在用户终端输入商品文本的方式实现对商品的搜索。并可以在用户终端内查看到一个或多个搜索出的商品的属性数据。还可以根据自己的实际需求来查看商品展示页面。因此可以极大地方便用户的商品搜索，提高对商品曝光的效率。

b、图片搜索。参考图6，图片搜索的流程，包括：

S501，用户终端将用户选取的商品图片上传至服务器。

S501的操作与S401基本相同，因此具体的操作细节、原理和有益效果，均可以参考S401中的相关说明，此处不予赘述。

与S401不同之处在于：

1、本申请实施例中，用户需要从用户终端选择一张本地图片作为商品图片上传至服务器。或者亦可以利用用户终端拍摄一张照片作为商品图片上传至服务器。

2、图片搜索的功能入口，理论上可以镶嵌于任何具有拍照或者图片浏览的功能之中。例如除了如图5B以外，也可以将图片搜索功能镶嵌于用户终端的相机功能之中。此时用户可以在日常对物品拍照之后，直接启用图片搜索功能来查询被拍物体对应的商品。同样可以将图片搜索功能镶嵌于用户终端的图库之中。此时用户在浏览图库的同时，可以根据需要启用图片搜索功能来查询图库中某张图片对应的商品。

实际应用中，技术人员可以根据需求，将图片搜索的功能入口设置于用户终端的一个或多个功能之中。本申请实施例中，通过在不同功能中嵌入图片搜索的功能入口，一方面可以方便用户使用图片搜索，实现随时随地的“拍照购”。另一方面，可以增加对商品的曝光度，给商家和电商平台带来更多的流量。

S502，服务器对接收到的商品图片进行图像特征分析，得到第一图像特征数据。

本申请实施例中，对用户上传的商品图片的图像特征分析方法，与对搜索前对已上传的商品图片的图像特征分析相同。因此对图像特征分析的操作可以参考对S301中的相关说明，此处不予赘述。

作为本申请的一个可选实施例，考虑到每种类目下的商品特征是具有一定共性的。例如同类目下商品的形状往往较为相似。因此为了提升图像特征分析的效果，使得得到图像特征数据可以更好地表征商品。在本申请实施例中，可以针对不同类目的商品预先设计不同的图像特征提取模型。在进行图像特征分析时，则先对商品图片进行类目识别(亦可称为意图分类)，以确定出待搜索商品实际所属类目。再以此来选择对应的模型和分析。

在本申请实施例中，商品图片的类目识别，实质是对商品的自动分类。因此此处可以预先针对已知的各个商品类目，设置相应的类目分类模型。再利用该类目分类模型来实现对商品类目的分类识别。本申请实施例不对类目分类模型的模型种类和架构进行过多限定。可由技术人员根据实际需求来设定。

作为本申请的一个可选实施例，在搜索前阶段，若S301使用了基于多模融合得到的图像特征分析模型进行图像特征分析(图像特征分析模型具体可参考S301中对应的实施例说明)。此时S502，也会使用与S301相同的图像特征分析模型对接收到的商品图片进行图像特征分析，进而得到对应的图像特征数据(即第一图像特征数据)。

应当理解地，对商品图片进行商品检测的操作，亦可以适用于本申请实施例。因此此时可以将S3011-S3012应用至本申请实施例。相应的，此时S502可以被替换为：

S5021，服务器对接收到的商品图片进行商品检测，并根据检测结果截取出商品图像。

S5022，服务器对商品图像进行图像特征分析，并得到的第一图像特征数据。

S5021-S5022的操作与S3011-S3012基本相同，因此具体的操作细节、原理和有益效果，均可以参考S3011-S3012中的相关说明，此处不予赘述。

S503，服务器根据第一图像特征数据，对特征库中的图像特征数据进行特征匹配。从特征库中筛选出特征匹配度最高的前n个第二图像特征数据，并确定前n个第二图像特征数据分别对应的n个商品。

在得到对用户上传商品图片的图像特征数据(即第一图像特征数据)之后，本申请实施例会利用该图像特征数据对特征库中存储的图像特征数据进行特征匹配。并筛选出其中特征匹配度最高的前n个图像特征数据(即第二图像特征数据)。再将这些图像特征数据对应的商品，作为此次搜索出的目标商品。

其中，本申请实施例不对特征匹配的具体方法进行过多限定，可由技术人员根据实际需求设定。例如可以采用一些开源检索引擎实现特征匹配。如可以采用Faiss，其原理是计算图像特征相似度，然后根据相似度的高低返回商品个数。具体筛选的图像特征数据数量n此处不予限定，可由技术人员自行设定。例如可以设定为10～20，或者20～100中的任意值。

S504，从NSP中获取n个商品的商品图片，并从数据库中获取n个商品的属性数据。根据获取到的属性数据和商品图片生成商品列表，并将商品列表发送至用户终端。

参考图6，S504可以细化为S5041-S5043：

S5041，服务器从NSP中获取n个商品的商品图片。

S5042，服务器从数据库中获取n个商品的属性数据。

S5043，服务器根据获取到的属性数据和商品图片生成商品列表，并将商品列表发送至用户终端。

在确定出此次搜索出的n个商品之后，本申请实施例会从NSP中下载这些商品的商品图片。同时从数据库中下载n个商品的属性数据。再根据获取到的属性数据和商品图片来生成商品列表，并发送给用户终端。其中，对属性数据的下载操作，以及对商品列表的生成操作，与S406基本相同。具体可参考S406的相关说明，此处不予赘述。

作为本申请的一个可选实施例，为了提高商品列表中各个商品的属性数据和商品图片排序的有效性。需尽可能地将相似度较高的商品的商品属性数据和商品图片排在前方。因此本申请实施例中，在S504中，“将商品列表发送至用户终端”的操作之前，服务器还可以对商品列表中各个商品的商品属性数据和商品图片，进行顺序重排(即重排序)。例如，考虑到实际应用中，商品颜色对于用户体验而言较为重要。此时可以根据商品的颜色，优先将商品列表中与用户终端上传的商品图片颜色相近的商品图片，以及该商品图片对应的属性数据，排在商品列表前方。

作为本申请的重排序的一种可能实现方式，包括：

S601，服务器对用户终端上传的商品图片进行商标检测，得到商品图片包含的第一商标信息。

S602，服务器对商品列表中的各张商品图片分别进行商标检测，得到这些商品图片包含的第二商标信息。

S603，服务器利用利用第一商标信息对各个第二商标信息进行信息匹配，并按照信息匹配度从高到低的顺序，对商品列表内各个商品的属性数据和商品图片进行排序。

其中，商标信息(包括第一商标信息和第二商标信息)包含商标名称和商标图案中的至少一种。具体可由技术人员根据实际需求设定。另外本申请实施例不对商标信息的检测方法做过多限定，可由技术人员自行设定。例如可以是基于神经网络模型的图像识别方法，亦可以是预设一些商标图像，进行图像匹配。

本申请实施例在利用商品图片的图像特征数据进行图片特征匹配的基础上，还会利用商品图片内包含的商标信息进行二次匹配。并会根据二次匹配结果对已得到的商品列表重新进行排序。从而使得与用户待检索的商品相似度较高的商品，可以在用户终端中进行属性数据和商品图片的优先展示。

作为本申请的重排序的另一种可能实现方式，包括：

S604，服务器对用户终端上传的商品图片进行商标检测，得到商品图片包含的第一商标信息。

S605，服务器对根据获取到的属性数据，提取n个商品的第三商标信息。

S606，服务器利用利用第一商标信息对各个第三商标信息进行信息匹配，并按照信息匹配度从高到低的顺序，对商品列表内各个商品的属性数据和商品图片进行排序。

其中，商标信息(包括第一商标信息和第三商标信息)是商标名称。本申请实施例一方面会对商品图片进行商标检测，识别出商品图片中包含的商标的商标名称(即第一商标信息)。另一方面会从n个商品的属性数据中，搜索各个商品的商标名称(即第三商标信息)。再根据商标名称进行二次匹配。并会根据二次匹配结果对已得到的商品列表重新进行排序。从而使得与用户待检索的商品相似度较高的商品，可以在用户终端中进行属性数据和商品图片的优先展示。

作为本申请的重排序的又一种可能实现方式，包括：

S607，服务器对用户终端上传的商品图片进行商标检测，得到商品图片包含的第一商标信息。

S608，服务器对商品列表中的各张商品图片分别进行商标检测，得到这些商品图片包含的第二商标信息。

S609，服务器对根据获取到的属性数据，提取n个商品的第三商标信息。

S6010，服务器利用利用第一商标信息，对n个商品的第二商标信息和第三商标信息进行信息匹配，并按照信息匹配度从高到低的顺序，对商品列表内各个商品的属性数据和商品图片进行排序。

在本申请实施例中，第一商标信息内包含商标名称，在此基础上，也可以同时包含商标图案。若第一商标信息内仅包含商标名称，则第二商标信息为商标名称。若第一商标信息内同时包含商标名称和商标图案，则第二商标信息内可以包含商标名称和商标图案中的任意一种或多种。第三商标信息则为商标名称。

本申请实施例一方面会对商品图片进行商标检测，识别出商品图片中包含的第一商标信息。另一方面会从n个商品的属性数据中，搜索各个商品的商标名称(即第三商标信息)，并对n个商品的商品图片进行第二商标信息的识别。再根据得到的三类商标信息来进行二次匹配，并根据二次匹配结果对已得到的商品列表重新进行排序。从而使得与用户待检索的商品相似度较高的商品，可以在用户终端中进行属性数据和商品图片的优先展示。

其中，本申请实施例不对商标信息的匹配方法做过多限定，可由技术人员根据实际需求设定。例如在一些可选实施例中，可以一方面利用第一商标信息对各个第二商标信息进行匹配，得到n个商品对应的第一匹配度。另一方面利用第一商标信息对各个第三商标信息进行匹配，得到n个商品对应的第二匹配度。再基于第一匹配度和第二匹配度，确定出各个商品的最终匹配度(可以采用权重求和等方式进行处理)，并作为匹配结果。

作为本申请的一个可选实施例，考虑到实际应用中可能会出现CP错误将同一商品的属性数据重复放置在同一商品数据之中的情况。例如一些仅是尺寸存在差别的上衣，若均放置在同一商品数据之中。此时单个商品可能同时对应有多个的属性数据。例如同一个上衣，仅是尺寸不同。若该商品的优先级较高，则可能会出现商品列表内重复有同一商品的属性数据。此时用户体验会有所下降。

为了应对上述情况，在将商品列表发送至用户终端之前，本申请实施例会对商品列表进行商品去重。即对商品列表中相同的商品，仅保留其中一个商品的属性数据和商品图片。并将其他商品的属性数据和商品信息均删除掉。此时可以实现对商品列表的去重更新，提高商品列表的有效性，以提高用户的体验。相应的，S505中展示的是去重更新后的商品列表。

S505，用户终端对商品列表进行显示。

S505的操作与S404基本相同，因此具体的操作细节、原理和有益效果，均可以参考S404中的相关说明，此处不予赘述。

作为本申请的一个可选实施例，对图片搜索结果(即商品列表)的展示，以及对用户点击链接的响应方式。亦可以参考图5C至图5E，此时需将输入的数据由商品文本“红酒杯”，改为红酒杯的图片。

作为本申请的一个可选实施例，参考图4B的在线流程部分，是一种搜索中对用户上传的商品图片进行图片搜索的方法流程示意图。说明如下：

用户终端通过API向服务器上传商品图片。

服务器对商品图片进行商品检测，并根据检测结果截取出商品图像。

服务器对商品图像进行类目识别，得到第二类目。

服务器基于第二类目，对商品图像进行图像特征分析，得到第一图像特征数据。

服务器对第一图像特征数据进行数据压缩，得到压缩后的第一图像特征数据。

服务器基于第一图像特征数据对特征库中的图像特征数据进行特征匹配，得到商品列表。

服务器对商品列表进行重排序，得到排序后的商品列表。

对排序后的商品列表进行商品去重，并将商品去重操作后的商品列表发送至用户终端。

本申请实施例的各个步骤操作细节、原理和有益效果的说明。均可以参考参考图6所示实施例中的相关说明。此处不予赘述。

在本申请实施例中，商品管理系统同时具备文本搜索和图片搜索功能。CP一次商品数据入库，可以实现多种商品分发渠道。为电商平台提供了更为方法的商品搜索功能，具有较高的实用价值。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本申请实施例还提供了一种服务器，所述服务器包括至少一个存储器、至少一个处理器以及存储在所述至少一个存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使所述服务器实现上述任意各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在服务器上运行时，使得服务器执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使对应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

最后应说明的是：以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (19)

1.一种商品数据管理方法，其特征在于，应用于服务器，所述方法包括：

获取商品数据，并将所述商品数据拆分为至少一个第一子文件，其中每个所述第一子文件中包含至少一个商品的属性数据；

对各个所述第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库。

2.根据权利要求1所述的商品数据管理方法，其特征在于，所述对各个所述第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库，包括：

从所述至少一个第一子文件中选取出一个子文件作为第二子文件；

对所述第二子文件进行属性数据校验，并将所述第二子文件中校验通过的属性数据上传至所述数据库；

在完成对所述第二子文件的校验之后，返回执行所述从所述至少一个第一子文件中选取出一个子文件作为第二子文件的操作，直至所有所述第一子文件均被校验完成。

3.根据权利要求1或2任意一项所述的商品数据管理方法，其特征在于，还包括：

若所述商品数据中存在校验失败的属性数据，则获取所述校验失败的属性数据的异常信息，并将所述异常信息存储至所述数据库。

4.根据权利要求1至3任意一项所述的商品数据管理方法，其特征在于，所述商品数据为数据表格式的数据。

5.根据权利要求2至4任意一项所述的商品数据管理方法，其特征在于，所述将所述第二子文件中校验通过的属性数据上传至数据库，包括：

在对所述第二子文件进行属性数据校验的过程中，将所述第二子文件中校验通过的属性数据上传至数据库；或者

在对所述第二子文件进行属性数据校验完成后，将所述第二子文件中校验通过的属性数据上传至数据库。

6.根据权利要求1至5任意一项所述的商品数据管理方法，其特征在于，所述商品数据内的属性数据中，包含商品图片下载地址，所述方法还包括：

根据所述校验通过的属性数据中包含的商品图片下载地址，下载商品图片；

对所述商品图片进行图像特征分析，得到图像特征数据；

将所述图像特征数据存储至特征库。

7.一种商品搜索方法，其特征在于，应用于服务器，所述方法包括：

接收用户终端上传的第一商品图片；

对所述第一商品图片进行图像特征分析，得到第一图像特征数据；

从特征库存储的图像特征数据中，确定出与所述第一图像特征数据特征匹配度最高的至少一个第二图像特征数据；

将与所述至少一个第二图像特征数据一一对应的第二商品图片，以及与所述第二商品图片关联的属性数据发送至所述用户终端，其中，发送的所述第二商品图片及关联的所述属性数据，是基于所述第一商品图片内包含的商标信息进行排序后的所述第二商品图片及所述属性数据。

8.根据权利要求7所述的商品搜索方法，其特征在于，在所述将与所述至少一个第二图像特征数据一一对应的第二商品图片，以及与所述第二商品图片关联的属性数据发送至所述用户终端之前，还包括：

获取所述第一商品图片内包含的第一商标信息；

获取各个目标商品的目标商标信息，所述目标商品是所述第二图像特征数据所关联的商品，所述第二商品图片及关联的所述属性数据，是所述目标商品的商品图片和属性数据；

按照所述目标商标信息与所述第一商标信息的信息匹配度从高到低的顺序，对所述目标商品的所述第二商品图片和所述属性数据进行排序。

9.根据权利要求8所述的商品搜索方法，其特征在于，所述目标商标信息，包括：第二商标信息和/或第三商标信息；

所述第二商标信息是所述目标商品关联的所述第二商品图片内包含的商标信息；

所述第三商标信息是所述目标商品关联的所述属性数据内包含的商标信息。

10.根据权利要求7至9任一所述的商品搜索方法，其特征在于，所述对所述第一商品图片进行图像特征分析，得到第一图像特征数据，包括：

利用预先训练完成的图像特征分析模型对所述第一商品图片进行图像特征分析，得到第一图像特征数据；所述图像特征分析模型是从基于多个商品样本的商品图片样本和属性数据样本训练得到的神经网络模型中，提取出的模型。

11.一种商品数据管理系统，其特征在于，包括：第一服务器、第二服务器和数据库；

所述第一服务器用于获取商品数据，并将所述商品数据拆分为至少一个第一子文件，其中每个所述第一子文件中包含至少一个商品的属性数据；

所述第二服务器用于对各个所述第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库。

12.根据权利要求11所述的商品数据管理系统，其特征在于，所述对各个所述第一子文件进行属性数据校验，并将校验通过的属性数据存储至数据库，具体包括：

所述第二服务器从所述至少一个第一子文件中选取出一个子文件作为第二子文件；

所述第二服务器对所述第二子文件进行属性数据校验，并将所述第二子文件中校验通过的属性数据上传至所述数据库；

所述第二服务器在完成对所述第二子文件的校验之后，返回执行所述获取所述至少一个第一子文件中的一个子文件的操作，直至所有所述第一子文件均被校验完成。

13.根据权利要求12所述的商品数据管理系统，其特征在于，在所述从所述至少一个第一子文件中选取出一个子文件作为第二子文件之前，还包括：

所述第一服务器在所述数据库中创建与所述第一子文件一一对应的第一子任务；

所述第二服务器从所述至少一个第一子文件中选取出一个子文件作为第二子文件，包括：

所述第二服务器从所述数据库存储的所述第一子任务中确定出一个第二子任务，并获取所述至少一个第一子文件中与所述第二子任务关联的一个子文件；

所述第二服务器返回执行所述获取所述至少一个第一子文件中的一个子文件的操作，直至所有所述第一子文件均被校验完成，包括：

所述第二服务器返回执行从所述数据库存储的所述第一子任务中确定出一个第二子任务的操作，直至所有所述第一子任务均被执行完成。

14.根据权利要求13所述的商品数据管理系统，其特征在于，所述从所述数据库存储的所述第一子任务中确定出一个第二子任务的操作，包括：

所述第二服务器向所述数据库发送任务查询请求；

所述数据库响应于接收到的所述任务查询请求，从所述第一子任务中筛选出待执行的子任务，并将所述待执行的子任务发送至所述第二服务器，所述待执行的子任务包括未执行的第一子任务，以及执行中且执行时长超出时长阈值的第一子任务；

所述第二服务器从接收到的所述待执行的子任务中，确定出所述第二子任务。

15.根据权利要求14所述的商品数据管理系统，其特征在于，所述第二服务器从接收到的所述待执行的子任务中，确定出所述第二子任务的操作，包括：

所述第二服务器依次向缓存组件请求对各个所述待执行的子任务的分布式锁；

所述第二服务器在请求到对单个待执行的子任务的分布式锁时，将该待执行的子任务作为第二子任务。

16.根据权利要求15所述的商品数据管理系统，其特征在于，在对所述第二子文件进行属性数据校验的过程中，所述第二服务器还用于：

判断对所述第二子文件的校验时长是否达到时长阈值；

若对所述第二子文件的校验时长达到时长阈值，则释放对所述第二子文件的分布式锁。

17.根据权利要求16所述的商品数据管理系统，其特征在于，还包括：所述缓存组件；

所述缓存组件用于在将对所述第二子文件的分布式锁分配给所述第二服务器后，开始计时；

所述缓存组件还用于在计时时长达到时长阈值时，释放对所述第二子文件的分布式锁。

18.一种服务器，其特征在于，所述服务器包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据权利要求1至6任一项所述方法的步骤。

19.一种芯片系统，其特征在于，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现如权利要求1至6任一项所述的商品数据管理方法。

Images