提供商品对象信息的方法及装置与流程

本申请涉及商品对象信息处理技术领域，特别是涉及提供商品对象信息的方法及装置。

背景技术：

为了提高消费者对大家电等大件商品的购物体验，一些交易平台为商家提供了统一的物流管理平台。通过该平台，商家可以首先入驻到一些特定的仓库(物流管理平台提供的大家电仓库，每个仓库都有自己的配送覆盖范围，能够给消费者提供确定性的物流服务体验)，然后商家将大家电商品入库到大家电仓库。消费者在前端页面中查看前端商品对象时，可以根据消费者所在的地址匹配仓库的覆盖区域范围，如果匹配上后则会将对应仓库中的库存展示给消费者，消费者付款下单后，会生成一个物流订单流入到物流管理平台，物流管理平台对其进行发货，而后“卖家的货物”经过一系列的配送环节派送到消费者指定的收货地址。

随着业务的迅速发展，电商前端交易下单与后端物流服务的联系越来越紧密，比如：时效展现、物流服务(预约配送、送装一体等)的披露等等，这些服务质量也会越来越影响消费者的购买意愿。但是，在披露这些物流服务的过程中，又会涉及多种核心数据的维护，比如：前端商品对象的标签(交易前端根据标签做不同的业务处理，例如，走区域销售模式的标签为2178，等等)、前后端商品绑定关系、仓库覆盖范围、配送时效、库存等等，只要一个发生异常(例如，商家可能会将某前后端商品绑定关系误删、某仓库的覆盖范围可能没有配置，某配送服务方在某区域的配送时效没有配置等等)，就可能会导致前端销售流量的损失(消费者无法正常下单)，这对于“双11”等大型活动来说，简直是一件灾难的事情。

因此，针对大家电等交易链路的复杂性以及商家对于正常下单的迫切需求的现状，如何避免由于交易链路的异常所带来的成交量损失，是需要本领域技 术人员解决的技术问题。

技术实现要素：

本申请提供了提供商品对象信息的方法及装置，能够提高系统效率，避免由于交易链路的异常所带来的成交量损失。

本申请提供了如下方案：

一种提供商品对象信息的方法，包括：

第一服务器确定待校验商品对象；

读取所述待校验商品对象在多个维度上的核心数据，所述核心数据包括交易链路上的关键节点上的数据；

通过判断所述多个维度上的核心数据，对商品对象信息进行校验。

一种提供商品对象信息的装置，应用于第一服务器，包括：

商品对象确定单元，用于确定待校验商品对象；

核心数据读取单元，用于读取所述待校验商品对象在多个维度上的核心数据，所述核心数据包括交易链路上的关键节点上的数据；

校验单元，用于通过判断所述多个维度上的核心数据，对商品对象信息进行校验。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以通过第一服务器，将分散在各个系统中的多项核心数据读取出来，以便通过对核心数据的完整性、一致性等进行校验，确定出商品对象是否可正常交易，或者在发现某商品对象存在交易异常时，快速定位到出现问题的核心数据。因此，可以提高系统效率，避免由于交易链路的异常所带来的成交量损失。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供系统架构示意图；

图2是本申请实施例提供的方法的流程图；

图3是本申请实施例提供的信息交互过程示意图；

图4是本申请实施例提供的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，针对交易链路的复杂性以及第一用户(例如，商家用户等)对于正常下单的迫切需求的现状，为了避免由于交易链路核心数据的异常所带来的成交量损失，提供了可以对商品对象的核心数据进行校验的平台。在该平台中，可以首先在复杂的交易链路中抽象出一套核心数据模型，例如，可以包括：商品对象信息(包括商品对象标签、前后台商品对象绑定关系、是否组合商品对象等等)、仓库列表、仓库覆盖范围、配送范围、线路时效、第一用户的订购关系等，这些核心数据都是交易链路上的关键节点上的数据。由于只要这些核心数据完整，就基本上可以保障第二用户(例如，买家用户，消费者用户等)正常下单，因此，通过该平台，可以将需要校验的商品对象的各项核心数据读取出来，这样可以从整体上对各项核心数据进行完整性校验，而不需要由相关的工作人员从各个系统中查询各项数据。其中，触发校验的时机既可以是定时触发(例如，可以定时对一批商品对象进行核心数据校验，例如， 可以在某大型促销活动开始之前，对参加活动的商品对象的核心数据进行校验，等等)，也可以手工触发(通过指定某一商品对象，校验核心数据的完整性情况，例如，当某商品对象在前端交易过程中被发现无法正常下单时，可以对该商品对象的核心数据进行校验，等等)。

其中，各项待校验的核心数据通常分散在不同的系统中，例如，商品对象信息通常由在商品中心服务器进行保存及维护，仓库列表以及库存信息通常由库存中心服务器进行保存及维护，订购关系信息通常由订购中心服务器进行保存及维护，仓库覆盖范围、配送线路以及配送时效信息通常由资源中心服务器(rc)保存，另外，物流业务系统(例如，delivery)通常也会从资源服务器获取仓库覆盖范围信息，以进行前置路由等操作，等等。因此，参见图1，本申请实施例中可以通过一校验服务器从分散在各系统中的各项核心数据读取出来，以便对商品对象信息进行校验，这样，就可以快速确定出各商品对象是否可正常交易，或者在发现某商品对象存在无法交易现象时，可以快速定位出商品对象信息中存在异常的核心数据。

下面对具体的实现方式进行详细介绍。

参见图2，本申请实施例首先提供了一种提供商品对象信息的方法，该方法可以包括以下步骤：

s201：第一服务器确定待校验商品对象；

具体实现时，可以有多种确定待校验商品对象的实现方式。例如，其中一种实现方式下，可以由工作人员等设定待校验的商品对象列表，具体的，可以是在一些大型促销活动等开始之前，将参加活动的商品对象确定为待校验的商品对象。由于各系统中保存的各项核心数据通常会随着交易的发生、补货等操作发生变化，因此，在这种实现方式下，还可以按照预置的时间间隔，对列表中的各商品对象进行周期性校验。在另一种实现方式下，还可以是在某商品对象被发现存在交易异常现象时，通过接收其他服务器的请求等方式，将出现交易异常的商品对象确定为待校验商品对象，等等。

s202：读取所述待校验商品对象在多个维度上的核心数据，所述核心数据 包括交易链路上的关键节点上的数据；

在确定出待校验商品对象后，第一服务器可以读取出待校验商品对象在多个维度上的核心数据，如前文所述，所谓的核心数据就可以是指交易链路上的关键节点上的数据。

具体实现时，首先可以从第二服务器(例如，商品中心服务器ic等)读取商品对象的标签信息、前端商品对象与后端商品对象之间的绑定关系信息、对应后端商品对象的标签信息以及是否组合商品对象等。其中，所谓的组合商品对象是指：在后端对应多个商品对象，但是在前端售卖时则组合为一个前端商品对象，例如，空调的内机与外机在后端对应两个不同的商品对象，但是，在前端进行售卖时，由于第二用户(例如，买家用户、消费者用户等)在购买空调内机时，通常需要连同外机一起进行购买，因此，为了缩短第二用户的操作路径，可以将空调内机与外机组合为一个前端商品对象，此时，该前端商品对象就可以称为组合商品对象，第二用户只需要对该组合商品对象进行下单，即可实现对空调内机与外机的购买。其中，对于组合商品对象，在第二服务器中保存商品对象信息时，通常会添加上特定的标识等，因此，可以通过这种标识，来识别出一个商品对象是否属于组合商品对象。关于从第二服务器获取的上述各项核心数据，都可能会存在标签信息不准确、前后端商品对象绑定关系被误删等情况，以至于影响商品对象的正常交易，因此，在本申请实施例中，都可以读取出来以便对其进行校验。

另一个维度上的核心数据可以是指商品对象关联仓库的库存数据。具体实现时，可以从第三服务器(例如，库存中心服务器ipm等)读取商品对象关联的存在库存记录的第一仓库列表，以及各仓库的库存数据，以便对各仓库的库存数据进行校验。也就是说，由于第一用户(例如，商家用户、卖家用户等)通常会对一个商品对象进行区域性销售，在分布在不同区域的仓库中都进行铺货，以满足各区域内第二用户的购买需求。因此，一个商品对象通常会关联多个仓库，而关于一个商品对象与哪些仓库关联，在每个仓库中具有多少库存(包括可销库存、占用库存、调拨在途库存等等)等信息，通常可以由第三服务器进行保存以及维护。因此，在本申请实施例中，可以从第三服务器中读取到这 些库存信息，以便对其进行校验。

在实际应用中，第一用户通常只可以向与其具有订购关系的仓库中进行铺货，最初的订购关系通常是在第一用户刚刚入驻统一物流管理平台时确定的，而随着具体售卖过程的进行，平台一般是允许第一用户修改其订购关系的。但是，第一用户的订购关系信息通常由第四服务器进行保存以及维护，也就是说，商品对象的库存信息与第一用户的订购关系信息分布在不同的系统中，双方的信息同步可能不够及时，因此，可能会出现以下情况：通过查询第三服务器获知某商品对象在某仓库中存在可售库存，但是通过查询第四服务器却获知，第一用户已经取消了与该仓库的订购关系，此时，如果将该商品对象直接在前端进行售卖，则就会出现无法交易的情况。为此，在本申请实施例中，还可以确定出待校验商品对象关联的第一用户，然后从第四服务器中读取与所述第一用户具有订购关系的第二仓库列表，以便对所述第一仓库列表与所述第二仓库列表中仓库的一致性进行校验，并确定出当前可用仓库列表。

在确定出当前可用仓库列表的情况下，还可以读取所述当前可用仓库列表中各仓库的覆盖范围、配送线路以及配送时效信息，以便对各仓库的覆盖范围、配送线路以及配送时效信息进行校验。之所以将上述信息也作为待检验的核心数据是因为，这些信息的完整性也会影响到前端的正常交易，而在实际应用中可能会存在某仓库的配送范围、配送时效等信息未配置等情况，因此，在本申请实施例中，还可以将上述信息读取出来，以便对其完整性进行校验。

其中，关于仓库列表中各仓库的覆盖范围、配送线路以及配送时效信息，通常是由第六服务器(例如，资源中心服务器rc等)进行保存以及维护，因此，可以从该第六服务器进行读取。另外，在实际应用中，第五服务器(例如，负责商品相关物流业务的核心系统，处在前台交易系统和后端物流系统之间的服务器delivery等)通常也会从第六服务器读取仓库的覆盖范围信息，以用于在第二用户购买某商品对象并输入了收货地址信息后，利用各仓库的覆盖范围信息进行前置路由，提前确定出发货仓库等。此时，第五服务器中的仓库覆盖范围与第六服务器中保存的仓库覆盖范围信息如果存在不一致的情况，也会影响到商品对象的正常交易，因此，在本申请实施例中，在读取仓库列表中各仓 库的覆盖范围、配送线路以及配送时效信息时，可以从第五服务器中读取各仓库的覆盖范围信息，并从第六服务器中读取各仓库的覆盖范围、配送线路以及配送时效信息，以便对第五服务器与第六服务器中保存的仓库覆盖范围信息的一致性进行比对。

另外，在实际应用中，各个服务器在保存各项核心数据时，通常会在数据库中进行保存，另外，可能还会在缓存(tair)中保存一份，以此来减轻对数据库的读写压力。但是，如果数据库中与缓存中出现数据不一致的情况，同样可能会影响商品对象的正常交易。因此，在本申请实施例中，如果某项核心数据在数据库以及缓存中都有保存，则可以分别从对应服务器的缓存以及数据库中进行读取，以便对缓存与数据库中的数据一致性进行比对，避免存在数据不一致的情况。需要说明的是，在实际应用中，针对同一纬度上的核心数据，服务器在进行缓存时，可能会将在多个缓存单元中保存多份，因此，还可能出现多个缓存单元之间数据不一致的问题，因此，还可以将各个缓存单元里的数据都读取出来，以便对各个缓存之间的数据一致性进行比对。

当然，在实际应用中，可能并不是每项核心数据都存在上述缓存的情况，因此，可以针对部分存在上述情况的核心数据，按照该方式进行处理。例如，对于库存数据，第三服务器通常就会在缓存中进行保存，第五服务器也可能会将仓库覆盖范围信息进行缓存，第六服务器也可能会将仓库覆盖范围、配送线路、线路时效等进行缓存，等等。

s203：通过判断所述多个维度上的核心数据，对商品对象信息进行校验。

在读取出各项核心数据后，就可以提供给校验方进行校验，其中，校验方可以是平台中的工作人员，或者，还可以是用于校验的处理模块。也就是说，在提供出各项核心数据后，后续的校验过程可以是人工完成，或者，还可以是平台自动完成。针对后一种情况，具体实现时，可以预先保存各个维度上核心数据的校验标准信息，在读取到各个维度上的核心数据后，可以利用所述校验标准信息对所述读取到的核心数据进行校验，然后返回校验结果。

其中，各个维度上核心数据的校验标准信息可以根据实际应用中的情况进 行设定，例如，对于前后端商品对象绑定关系信息，可以将校验标准设定为：如果存在前后端绑定关系，则校验通过。对于第三服务器缓存与第三服务器数据库中保存的第一仓库列表，如果信息一致，则校验通过，等等。

总之，在本申请实施例中，可以通过第一服务器，将分散在各个系统中的多项核心数据读取出来，以便通过对核心数据的完整性、一致性等进行校验，确定出商品对象是否可正常交易，或者在发现某商品对象存在交易异常时，快速定位到出现问题的核心数据。因此，可以提高系统效率，避免由于交易链路的异常所带来的成交量损失。

为了便于理解，下面通过各系统之间的信息交互过程示意图，对本申请实施例在实际应用中的一种具体实施方式进行介绍。参见图3，在该图3中涉及到以下交互实体：第一服务器(vspops)、第二服务器(ic)、第三服务器缓存(ipm-tair)、第三服务器数据库(ipm-db)、第四服务器(usa)、第五服务器缓存(delivery-tair)、第五服务器数据库(delivery-db)、第六服务器缓存(rc-tair)、第六服务器数据库(rc-db)。如图所示，该交互过程可以包括：

1：vspops接收输入的待校验商品对象id；

2：从ic获取前端商品对象标签；

3：从ic获取前后端商品对象绑定关系；

4：从ic获取后端货品信息；

5、从ipm-tair获取库存大于0的仓库列表；

6、从ipm-db获取库存大于0的仓库列表；

7、从ipm-db获取库存数据；

8、从usa获取第一用户订购的仓库列表；

9、从delivery-tair获取仓库的覆盖范围信息；

10、从delivery-db获取仓库的覆盖范围信息；

11、从rc-tair获取仓库的覆盖范围信息、配送线路、线路时效信息；

12、从rc-db获取仓库的覆盖范围信息、配送线路、线路时效信息。

后续具体进行校验时，可以对各项核心数据的完整性进行校验，另外还可以对第5步与第6步、第9步与第10步、第11步与第12步、第10步与第12步读取到的核心数据进行一致性校验。

与本申请实施例提供的提供商品对象信息的方法相对应，本申请实施例还提供了一种提供商品对象信息的装置，该装置应用于第一服务器，参见图4，该装置可以包括：

商品对象确定单元401，用于确定待校验商品对象；

核心数据读取单元402，用于读取所述待校验商品对象在多个维度上的核心数据，所述核心数据包括交易链路上的关键节点上的数据；

校验单元403，用于通过判断所述多个维度上的核心数据，对商品对象信息进行校验。

具体实现时，所述商品对象确定单元具体用于：

根据预先设定的待校验商品对象列表，确定待校验商品对象；其中，按照预置的时间间隔对所述列表中的商品对象进行周期性校验。

或者，所述商品对象确定单元具体用于：

接收对指定商品对象进行校验的请求，并将所述指定商品对象确定为待校验商品对象；其中，所述指定商品对象包括在交易过程中被发现无法正常交易的商品对象。

或者，所述核心数据读取单元具体用于：

从第二服务器读取商品对象的标签信息、前端商品对象与后端商品对象之间的绑定关系信息、对应后端商品对象的标签信息以及是否组合商品对象。

或者，所述核心数据读取单元具体用于：

从第三服务器读取商品对象关联的存在库存记录的第一仓库列表，以及各仓库的库存数据，以便对各仓库的库存数据进行校验。

此时，所述核心数据读取单元具体还可以用于：

确定所述待校验商品对象关联的第一用户；

从第四服务器中读取与所述第一用户具有订购关系的第二仓库列表，以便对所述第一仓库列表与所述第二仓库列表中仓库的一致性进行校验，并确定出当前可用仓库列表。

另外，所述核心数据读取单元具体还可以用于：

读取所述当前可用仓库列表中各仓库的覆盖范围、配送线路以及配送时效信息，以便对各仓库的覆盖范围、配送线路以及配送时效信息进行校验。

再者，所述核心数据读取单元具体用于：

从第五服务器中读取各仓库的覆盖范围信息；

从第六服务器中读取各仓库的覆盖范围、配送线路以及配送时效信息，以便对第五服务器与第六服务器中保存的仓库覆盖范围信息的一致性进行比对。

或者，所述核心数据读取单元具体用于：

针对同一维度上的核心数据，分别从对应服务器的缓存以及数据库中进行读取，以便对缓存与数据库中的数据一致性进行比对。

在具体实现时，所述校验单元可以包括：

校验标准信息保存子单元，用于预先保存各个维度上核心数据的校验标准信息；

校验子单元，用于读取到各个维度上的核心数据后，利用所述校验标准信息对所述读取到的核心数据进行校验；

校验结果返回子单元，用于返回校验结果。

通过本申请实施例，可以通过第一服务器，将分散在各个系统中的多项核心数据读取出来，以便通过对核心数据的完整性、一致性等进行校验，确定出商品对象是否可正常交易，或者在发现某商品对象存在交易异常时，快速定位到出现问题的核心数据。因此，可以提高系统效率，避免由于交易链路的异常所带来的成交量损失。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的提供商品对象信息的方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。