CN104063772B - 一种物流信息可靠性检验方法及装置 - Google Patents

Abstract

本申请公开了一种物流信息可靠性检验方法及装置。一种物流信息可靠性检验方法包括：接收物流信息服务器主动推送的物流信息；对所接收的物流信息进行抽样；利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。上述技术方案一方面，以主动推送物流信息的方式，避免物流信息服务器频繁地被动接收查询，有效平衡物流公司对应的服务器的查询负荷；另一方面，在信息查询侧，通过对推送信息进行抽样以及反向查询，从而实现对主动推送的物流信息可靠性的检验。

Description

一种物流信息可靠性检验方法及装置

技术领域

本申请涉及互联网数据处理技术领域，特别是涉及一种物流信息可靠性检验方法及装置。

背景技术

随着计算机和网络的普及，越来越多的个人用户开始接触电子商务。与企业之间的电子商务活动相比，个人用户数量更大、交易次数更为频繁，这也为物流信息的管理带来了很大的挑战。

在一次交易的物流过程中，物流状态会发生多次变化，例如，卖方发货、货物到达某中转站、买方签收等等，无论对于买方用户还是卖方用户，都存在实时追踪物流信息的需求。目前很多交易平台本身并不直接提供物流服务，而是采用与物流公司合作的方式。物流信息本身通常为物流公司的数据，但是一般用户的使用习惯都是从交易平台中直接查询物流状态。为了满足用户的上述需求，交易平台需要通过实时查询物流公司网站的获取最新的物流信息，进而反馈给用户。

然而，来自于交易平台的频繁查询，也给物流公司对应的服务器(如隶属于物流公司或者物流公司租用的服务器，还可以是由交易平台为该物流公司配置的服务器等，本申请实施例中以“物流信息服务器”表示)提出了更高的要求。在QPS(Query Per Second)，每秒查询率非常高的情况下，很多物流公司对应的服务器无法承受海量数据查询的负荷，导致无法响应查询、或者反馈的信息不准确、不及时等各种异常情况。另一方面，对于物流公司所反馈的信息，交易平台也无法进行检验，因此，在很多情况下，交易平台展示给用户的物流信息都是存在问题的，并不能反应当时实际的物流状态变化。

发明内容

为解决上述技术问题，本申请实施例提供一种物流信息可靠性检验方法及装置，以降低物流公司对应的服务器的查询负荷，并且在信息接收侧实现对查询结果可靠性的检验。技术方案如下：

一种物流信息可靠性检验方法，包括：

接收物流信息服务器主动推送的物流信息；

对所接收的物流信息进行抽样；

利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；

将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。

本申请实施例还提供一种物流信息可靠性检验装置，包括：

信息接收模块，用于接收物流信息服务器主动推送的物流信息；

信息抽样模块，用于对所接收的物流信息进行抽样；

信息反向查询模块，用于利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；

检验模块，用于将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。

应用本申请实施例所提供的物流信息可靠性检验方案，一方面，以主动推送物流信息的方式，避免物流信息服务器频繁地被动接收查询，有效平衡物流公司对应的服务器的查询负荷；另一方面，在信息查询侧，通过对推送信息进行抽样以及反向查询，从而实现对主动推送的物流信息可靠性的检验。

附图说明

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

图1为本申请实施例物流信息交互系统的一种结构示意图；

图2为本申请实施例物流信息可靠性检验方法的一种流程图；

图3为本申请实施例物流信息可靠性检验方法的第二种流程图；

图4为本申请实施例物流信息可靠性检验装置的一种结构示意图。

具体实施方式

本申请实施例方案一种典型的应用场景是：交易平台本身并不直接提供物流服务、而是通过查询物流公司对应的服务器获取实时物流状态信息以满足用户需求的场景，图1所示为这种应用场景下的物流信息交互系统的一种结构示意图。交易平台100与用户端300之间、交易平台100与物流信息服务器200之间分别通过网络实现相互通信，其中，不同用户使用不同的用户端1、2、......m，多个物流信息服务器1、2......n可以对应一家物流公司对应的多台服务器，也可以对应多家物流公司对应的多台服务器。

用户在交易平台进行买卖交易，在物流过程中，物流状态随时会发生变化，而用户方面则存在查询物流状态的需求。为满足用户的查询需求，现有技术的实现方式如下：

用户端300以某种查询条件(例如，交易号、订单号、运单号等等)向交易平台100发起查询请求；交易平台100接收到用户端300发出的物流信息实时查询需求后，进而向物流信息服务器200发送查询请求；物流信息服务器200接收查询请求后，向交易平台100反馈相应的查询结果；交易平台100将查询结果进一步反馈至用户端300。

在现有技术的实现方案中，物流信息服务器200随时需要处理来自于交易平台的查询，除此之外，可能还需要处理来自个人用户的查询请求。与专业的交易平台不同，物流公司的优势在于对货物的快速投递，而在网络、服务器等设施建设上往往投入不够，难以承受海量数据查询的负荷。因此，一旦查询频率超过一定限度，物流信息服务器200就可能出现异常，导致反馈给交易平台100的信息不准确，而交易平台100方面又无法对反馈的信息的可靠性进行检验，进而导致将不准确的信息反馈给用户端300，造成很差的用户体验。

为解决上述问题，本申请实施例提供一种物流信息可靠性检验方法，该方法包括以下步骤：

接收物流信息服务器主动推送的物流信息；

对所接收的物流信息进行抽样；

利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；

将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。

上述步骤的执行主体为直接向物流信息服务器发起查询请求的物流信息查询方，如背景技术所述，该“物流信息查询方”的一种典型应用实例是交易平台，当然这并不应该理解为对本申请方案的限制，例如，在特定应用场景下，该“物流信息查询方”也可以是物流公司管理单位、甚至个人用户等等。

应用本申请实施例所提供的物流信息可靠性检验方案，一方面，以主动推送物流信息的方式，避免物流信息服务器频繁地被动接收查询，有效平衡物流公司对应的服务器的查询负荷；另一方面，在物流信息查询侧，通过对推送信息进行抽样以及反向查询，从而实现对主动推送的物流信息可靠性的检验。

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

图2所示，为本申请一种物流信息可靠性检验方法的流程图，该方法可以包括以下步骤：

S101，接收物流信息服务器主动推送的物流信息；

在本实施例中，以交易平台作为“物流信息查询方”为例，对本申请的方案进行说明，以下步骤的执行主体可以是交易平台的服务器本身，或者是交易平台中其他形式的物流信息处理功能模块。

物流信息服务器是拥有物流信息数据的实体，在整个物流过程中，可监控每个物流状态的变化，例如，卖方发货、货物到达某中转站、买方签收，并随时将最新的状态录入服务器，其中每条物流状态信息录入的基本内容包括“发生时间”、“状态描述”等等，表1示出了一次交易的物流信息片段示意：

发生时间	状态描述
		2013-02-2717:45:01	您的订单已经拣货完成
2013-02-2718:04:01	您的订单已通过扫描确认
		2013-02-2718:12:59	您的订单已打包完毕
2013-02-2718:22:21	您的订单已完成分拣
		2013-02-2718:27:24	您的订单等待送往文慧园站
2013-02-2807:03:32	您的货物已分配，等待配送
		2013-02-2808:51:08	配送员已经从站点出发，请您准备收货

表1

根据本申请方案，在物流信息服务器侧，每产生一条新的物流状态信息后，将该条信息主动推送至交易平台。当然，在实际实施时，这个推送操作并不一定要求是“即时”的，例如，可以周期性地将最新产生的物流信息批量推送至交易平台，也可以在系统空闲时将最新产生的物流信息批量推送至交易平台。这样处理一方面是考虑到物流信息服务器的负荷，另一方面是考虑到实际的物流状态信息也并非每分每秒都在变化。因此总的推送原则是：在不影响物流信息服务器正常工作的前提下，尽量快速、及时地将最新产生的信息推送至交易平台。在本申请实施例中，并不需要对具体的推送策略进行限定。

交易平台接收到物流信息服务器主动推送的物流信息后，对接收到的信息进行存储。一般而言，物流信息都以“运单”为逻辑单位进行存储，即将每一张运单所对应的物流信息分别存储。当然，在实际实施过程中，存储信息所使用的逻辑单位可能是更为广义的“订单”、“交易”等等，本申请实施例对此并不需要进行限定。

在本申请实施例中，由于物流信息服务器会持续将最新的物流状态主动推送给交易平台，因此交易平台可以采用增量存储的方式，即每次存储时，在当前已存储信息的基础上，仅保存最新推送来的物流信息。

交易平台保存物流信息服务器主动推送的物流信息后，后续可以直接利用所存储的信息响应用户发出的物流状态查询请求。而本申请实施例的一个主要目的是：利用物流信息服务器主动推送的物流信息进行反向查询，从而实现对推送信息的检验。在本实施例后面的步骤中，将详细介绍如何实现对推送信息的检验。

S102，对所接收的物流信息进行抽样；

抽样是统计学中的概念，是指从全部分析对象中抽取一部分样本，通过对样本的分析结果来估计或推断全部分析对象的特性，抽样是质量检验中普遍采用的一种方法。在本申请实施例中，采用抽样的方式，通过判断一小部分物流信息样本是否准确，进而估计该物流信息服务器所推送的全部物流信息是否是值得信赖的。

一种直接抽样方法是以“物流信息”作为抽样单位，但是，从用户的角度来看，往往并不会单独关注一次交易中每一条具体的物流信息正确与否，而是从整体上关注这次交易的所有物流信息是否准确及时。根据用户的上述习惯，可以将“运单”作为分析单位，即将每笔运单所对应的所有信息作为一个整体看待，有多少笔运单，就有多少组需要分析的数据对象。相应的抽样操作也以“运单”为单位进行，每次抽取操作得到的都是一笔运单所对应的物流信息。

对物流信息进行抽样的频率，可以根据实际需求灵活设置，例如，设为10％，即平均每10笔运单中，抽取1笔运单的所对应的物流信息。具体的抽取策略举例如下：

1)交易平台从当前已接收的所有运单中抽取10％作为样本；

2)交易平台每隔一段固定的时间间隔T，从该T时段内发生更新的运单中抽取10％作为样本；

3)交易平台每收到10条新的物流信息，则从中抽取1笔运单的所对应的物流信息；

在具体实施过程中，还有很多其他的抽取策略可供选择，在本实施例中不一一列举。可以理解的是，由于运单的信息会在一段时间内多次更新，因此单笔运单数据存在多次被抽样的可能，“抽样频率”应理解为一个广义上的标准，而并不一定完全对应于精确的统计数字，当然这些并不会影响本申请方案的实施。

S103，利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；

在本申请方案中，交易平台对于抽样得到的物流信息样本，向物流信息服务器发起反向查询。如果在步骤S102中是以“运单”单位进行抽样，则在本步骤中，可以以运单的标识(即运单号)作为查询条件发送至物流信息服务器。

值得注意的是，本步骤中交易平台尽管需要向物流信息服务器发送查询请求，但是，由于是仅针对抽样得到的数据进行查询，因此给物流信息服务器带来的查询负荷明显降低了，例如，抽样频率为10％，则与现有技术相比，物流信息服务器仅需承担10％的查询负荷。

S104，将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。

物流信息服务器针对交易平台发送的查询请求，向交易平台反馈查询结果后，交易平台对物流信息服务器反馈的查询结果与物流信息样本进行比较，由于在步骤S103中，查询请求就是根据所抽取的物流信息样本生成的，因此，在正常情况下，比较结果应该是完全一致的，如果比较结果不一致，则说明物流信息服务器存在推送信息不及时、或者推送信息不准确等问题。

如果在步骤S102中是以“运单”单位进行抽样，则在本步骤中，可以采用以下策略对同一运单对应的两组的物流信息进行比较：

1)比较物流信息样本中所包含的信息数量和物流信息服务器反馈的信息数量是否一致；

这样比较的目的主要是，检验物流信息服务器推送物流信息是否足够及时，如果比较结果不一致，一般来说大多是物流信息样本中所包含的信息数量少于物流信息服务器反馈的信息数量，例如：物流信息样本中所包含的信息共有5条，如表2所示：

发生时间	状态描述
		2013-02-2717:45:01	您的订单已经拣货完成
2013-02-2718:04:01	您的订单已通过扫描确认
		2013-02-2718:12:59	您的订单已打包完毕
2013-02-2718:22:21	您的订单已完成分拣
		2013-02-2718:27:24	您的订单等待送往文慧园站

表2

而物流信息服务器反馈的信息数量如前面的表1所示，共有6条，这说明物流信息服务器并没有及时对最新的物流状态“2013-02-2807:03:32您的货物已分配，等待配送”进行推送。

当然，如果出现物流信息样本中所包含信息数量多于物流信息服务器反馈信息数量的情况，则说明物流信息服务器可能是完全推送了一组错误的物流信息。

2)比较物流信息样本中最后一条信息和物流信息服务器反馈的最后一条信息内容是否相同。

这种比较方式仅通过比较两组物流信息的最后一条信息内容是否相同，从而判断二者是否一致，其中，比较的对象可以是两组物流信息中最后一条信息的更新时间，也可以两组物流信息中最后一条信息的描述文本，当然也可以对两者都进行比较、或者进一步比较两组物流信息中最后一条信息的其他字段。只要两组物流信息中最后一条信息的任何地方存在不一致的情况，都可以认为是流信息服务器主动推送的物流信息存在问题。

以上列举的两种比较策略，都是假设实时查询得到的物流信息是真实可靠的，然后通过比较物流信息服务器之前推送的物流信息样本与实时查询得到的物流信息是否一致，判断物流信息服务器主动推送的物流信息是否真实可靠。两种比较策略的原则都是根据物流信息的实际特点，通过尽量少的比较步骤找到两组物流信息所存在的不一致。在实际的实施过程中，上述两种比较策略可以分别独立使用，也可以结合使用，本领域技术人员也可以根据实际应用场景采用其他比较策略，这些并不影响本申请方案的实现。

考虑到在实际应用中，个别运单的信息推送错误或者不及时属于允许现象，为了避免个别比较结果不一致对整个物流服务器的评价造成影响，在本申请方案的一种具体实施方式中，可以对每组抽样数据对应的比较结果进行统计：如果满足所有的一致性条件，则计该组数据“合格”，如果不满足任一项一致性条件，则计该组数据“不合格”，最后统计所有抽样数据的“合格率”，即所有抽样数据比较结果的一致率，如果一致率大于某个预设的阈值(例如95％)则判定该物流信息服务器推送的物流信息是可靠的。

需要说明的是，在上述实施例中，以“运单”作为抽样单位仅是一种具体的实施方式，在实际应用中，如果以单条物流信息作为抽样单位，则后续以所抽取单条物流信息标识生成查询条件，向物流信息服务器发起反向查询，然后根据反馈结果与该条物流信息是否一致，判断该条物流信息是否合格，同样能够实现检验物流信息服务器推送的物流信息是否可靠的目的。

图3所示，为上述提供的物流信息可靠性检验方法的交互流程图，应用上述方案，一方面，以主动推送物流信息的方式，避免物流信息服务器频繁地被动接收查询，有效平衡物流公司对应的服务器的查询负荷；另一方面，在物流信息查询侧，通过对推送信息进行抽样以及反向查询，从而实现对主动推送的物流信息可靠性的检验。如果判定物流信息服务器推送的物流信息是不可靠的，则交易平台可以采取相应的处理措施，例如，与相应的物流公司进行联系，建议其提高信息推送质量，在物流公司响应之前，还可以临时采用实时查询获取物流信息的方式，以满足用户的查询需求。

可以理解的是，上述方案中所说的物流信息服务器，可以是特定的一台服务器或一组服务器集群。基于本申请所提供的方案，如果交易平台分别从多台物流信息服务器或多组服务器集群获取物流信息，则可以分别针对每台服务器或每组服务器集群所推送的信息进行抽样、反向查询以及信息比较操作，相应可以得到各台服务器或各组服务器集群所推送信息是否可靠的评价结果。

在实际应用中，对于不同的物流信息服务器推送的物流数据，可以设置不同的物流信息抽样频率。例如，对于一些规模较大、评价较高的物流公司，可以对其对应的服务器所推送的数据设置较低的抽样频率，相反对于一些评价较差(这里仅值物流信息推送方面)的物流公司，可以对其对应的服务器所推送的数据设置较高的抽样频率。

在本申请的一种具体实施方式中，所设置的抽样频率可以是相对固定的，也可以是动态进行调整的。例如，在某一段历史时期内(例如，过去的一周、过去的一个月等等)，发现某一物流信息服务器(集群)推送信息的抽样合格率高于某个预设的阈值，或者有变高的趋势，则可以相应降低针对该物流信息服务器(集群)的信息抽样频率；相反如果某一物流信息服务器(集群)推送信息的抽样合格率低于某个预设的阈值，或者有变低的趋势，则可以相应提高针对该物流信息服务器(集群)的信息抽样频率。通过这种动态调整抽样频率的方式，能够进一步平衡推送信息可靠性检验与物流信息服务器查询负荷之间的矛盾。

相应于上面的方法实施例，本申请还提供一种物流信息可靠性检验装置，其特征在于，参见图4所示，该装置可以包括：信息接收模块110、信息抽样模块120、信息反向查询模块130、检验模块140。以下对各模块的功能和协作关系进行详细说明：

在本实施例中，以交易平台作为“物流信息查询方”为例，对本申请的方案进行说明，则上述物流信息可靠性检验装置可以位于交易平台的服务器中。

信息接收模块110，用于接收物流信息服务器主动推送的物流信息；

根据本申请方案，在物流信息服务器侧，每产生一条新的物流状态信息后，将该条信息推送至交易平台。

信息接收模块110接收到物流信息服务器主动推送的物流信息后，对接收到的信息进行存储。

在本申请实施例中，由于物流信息服务器会持续将最新的物流状态主动推送给信息接收模块110，因此信息接收模块110可以采用增量存储的方式，即每次存储时，在当前已存储信息的基础上，仅保存最新推送来的物流信息。

信息接收模块110保存物流信息服务器主动推送的物流信息后，后续可以直接利用所存储的信息响应用户发出的物流状态查询请求。

信息抽样模块120，用于对所接收的物流信息进行抽样；

信息反向查询模块130，用于利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；

检验模块140，用于将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。

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

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

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种物流信息可靠性检验方法，其特征在于，该方法包括：

接收物流信息服务器主动推送的物流信息；

对所接收的物流信息进行抽样；

利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；

将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。

2.根据权利要求1所述的方法，其特征在于，所述对所接收的物流信息进行抽样，包括：

以运单为抽样单位，每次抽取一笔运单所对应的物流信息。

3.根据权利要求2所述的方法，其特征在于，所述利用抽样得到的物流信息样本生成查询条件，向物流信息服务器发送查询请求，包括：

利用被抽样运单的标识作为查询条件，向物流信息服务器请求查询该笔运单所对应的物流信息。

4.根据权利要求3所述的方法，其特征在于，所述将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，包括：

比较物流信息样本中所包含的信息数量和物流信息服务器反馈的信息数量是否一致；

和/或

比较物流信息样本中最后一条信息和物流信息服务器反馈的最后一条信息内容是否相同。

5.根据权利要求1所述的方法，其特征在于，所述根据比较结果的一致性判断所述物流信息服务器推送的物流信息是否可靠，包括：

统计每组抽样数据对应的比较结果，如果比较结果一致率大于预设的阈值，则判定所述物流信息服务器推送的物流信息可靠。

6.根据权利要求1所述的方法，其特征在于，该方法还包括：

针对不同的物流信息服务器，设置不同的物流信息抽样频率。

7.根据权利要求1所述的方法，其特征在于，该方法还包括：

根据预设历史时段内的抽样比较结果统计，动态调整物流信息的抽样频率。

8.一种物流信息可靠性检验装置，其特征在于，该装置包括：

信息接收模块，用于接收物流信息服务器主动推送的物流信息；

信息抽样模块，用于对所接收的物流信息进行抽样；

信息反向查询模块，用于利用抽样得到的物流信息样本生成查询条件，向所述物流信息服务器发送查询请求；

检验模块，用于将物流信息服务器反馈的查询结果与所述物流信息样本进行比较，根据比较结果的一致性，判断所述物流信息服务器推送的物流信息是否可靠。

9.根据权利要求8所述的装置，其特征在于，所述信息抽样模块，具体用于：

以运单为抽样单位，每次抽取一笔运单所对应的物流信息。

10.根据权利要求9所述的装置，其特征在于，所述信息反向查询模块，具体用于：

利用被抽样运单的标识作为查询条件，向物流信息服务器请求查询该笔运单所对应的物流信息。