订单信息采集方法及系统与流程

本申请涉及数据处理技术领域，尤其涉及一种订单信息采集方法及系统。

背景技术：

随着互联网技术的迅速发展，用户既可以线上办理运营商业务，也可以线下通过营业厅窗口办理业务，因而运营商的各业务系统会产生大量的订单。目前，运营商可以提供一个用户查询平台，供用户查询自己的历史订单信息、处理中的订单信息。

现有技术中，通常是为各业务系统开发实时同步接口，将每个业务系统产生的订单信息汇总到一个处理系统中，由该处理系统进行分析、分类和归总，并将处理后的订单信息提供给用户查询平台，以供用户查询。

但是，由于每个业务系统的接口处理规则不同，每个业务系统可能只发送一个订单的部分数据信息，导致汇总到用户查询平台的数据信息不完整，存在查询结果不准确的问题。

技术实现要素：

本申请提供一种订单信息采集方法及系统，以克服现有技术中订单信息查询结果不准确的问题。

本申请第一方面提供的一种订单信息采集方法，适用于订单信息采集系统，所述系统包括：至少一个省分系统、总部系统和处理系统，所述方法包括：

对于所述至少一个省分系统中的任意一个省分系统，所述省分系统获取存储单元的信息修改记录，并基于所述信息修改记录获取最新订单信息；

所述省分系统将所述最新订单信息分发至所述总部系统的至少一个主题文件中；

所述处理系统获取所述总部系统中所述至少一个主题文件的子订单信息，基于所有主题文件的子订单信息得到目标订单信息，所述目标订单信息存储至用户查询平台中供用户查询。

在第一方面的一种可能设计中，所述省分系统获取存储单元的信息修改记录，并基于所述信息修改记录获取最新订单信息，包括：

所述省分系统基于数据备份插件和日志回滚机制，抓取所述存储单元的信息修改记录；

所述省分系统根据所述信息修改记录，获取所述信息修改记录对应的所述最新订单信息。

在第一方面的另一种可能设计中，在所述省分系统将所述最新订单信息分发至所述总部系统的至少一个主题文件中之前，所述方法还包括：

所述省分系统将所述最新订单信息存储至日志追踪文件中；

所述省分系统通过数据泵进程读取所述日志追踪文件中的所述最新订单信息并传输至省分处理主机。

在第一方面的再一种可能设计中，所述省分系统将所述最新订单信息分发至所述总部系统的至少一个主题文件中，包括：

所述省分系统确定所述最新订单信息各部分的业务类型；

所述省分系统根据所述最新订单信息各部分的业务类型，将所述最新订单信息拆分成至少一个第一子订单信息；

所述省分系统基于预设的分发规则，将所述至少一个第一子订单信息分发至所述总部系统的至少一个主题文件中。

在第一方面的又一种可能设计中，所述省分系统将所述最新订单信息分发至所述总部系统的至少一个主题文件中，包括：

所述省分系统确定所述最新订单信息各部分的数据量；

所述省分系统根据所述最新订单信息各部分的数据量，将所述最新订单信息拆分成至少一个第二子订单信息；

所述省分系统基于预设的分发规则，将所述至少一个第二子订单信息分发至所述总部系统的至少一个主题文件中。

本申请第二方面提供一种订单信息采集系统，包括：至少一个省分系统、总部系统和处理系统；对于所述至少一个省分系统中的任意一个省分系统，所述省分系统包括：第一获取模块、第一处理模块和分发模块；

所述第一获取模块，用于获取存储单元的信息修改记录；

所述第一处理模块，用于基于所述信息修改记录获取最新订单信息；

所述分发模块，用于将所述最新订单信息分发至所述总部系统的至少一个主题文件中；

所述处理系统包括：第二获取模块、第二处理模块；

所述第二获取模块，用于获取所述总部系统中所述至少一个主题文件的子订单信息；

所述第二处理模块，用于基于所有主题文件的子订单信息得到目标订单信息，所述目标订单信息存储至用户查询平台中供用户查询。

在第二方面的一种可能设计中，所述第一获取模块，具体用于基于数据备份插件和日志回滚机制，抓取所述存储单元的信息修改记录；

所述第一处理模块，具体用于根据所述信息修改记录，获取所述信息修改记录对应的所述最新订单信息。

在第二方面的另一种可能设计中，所述第一处理模块，还用于在所述分发模块将所述最新订单信息分发至所述总部系统的至少一个主题文件中之前，将所述最新订单信息存储至日志追踪文件中；

所述分发模块，具体用于通过数据泵进程读取所述日志追踪文件中的所述最新订单信息并传输至省分处理主机。

在第二方面的再一种可能设计中，所述第一处理模块，具体用于确定所述最新订单信息各部分的业务类型，根据所述最新订单信息各部分的业务类型，将所述最新订单信息拆分成至少一个第一子订单信息；

所述分发模块，具体用于基于预设的分发规则，将所述至少一个第一子订单信息分发至所述总部系统的至少一个主题文件中。

在第二方面的又一种可能设计中，所述第一处理模块，具体用于确定所述最新订单信息各部分的数据量，根据所述最新订单信息各部分的数据量，将所述最新订单信息拆分成至少一个第二子订单信息；

所述分发模块，具体用于基于预设的分发规则，将所述至少一个第二子订单信息分发至所述总部系统的至少一个主题文件中。

本申请第三方面提供一种订单信息采集系统，包括处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述第一方面以及第一方面各种可能设计所述的方法。

本申请第四方面提供一种存储介质，所述存储介质中存储有指令，当其在计算机上运行时，使得计算机执行如第一方面以及第一方面各种可能设计所述的方法。

本申请实施例提供的订单信息采集方法及系统，省分系统获取存储单元的信息修改记录并基于该信息修改记录获取最新订单信息，将该最新订单信息分发至总部系统的至少一个主题文件中，该处理系统获取该总部系统中至少一个主题文件的子订单信息，并基于所有主题文件的子订单信息得到目标订单信息，该目标订单信息存储至用户查询平台中供用户查询。该技术方案可以保证每个订单信息环境的准确性和实时性，提高了订单信息查询结果的准确度。

附图说明

图1为本申请实施例提供的订单信息采集系统的结构示意图；

图2为本申请实施例提供的订单信息采集方法实施例一的流程示意图；

图3为本申请实施例提供的订单信息采集方法实施例二的流程示意图；

图4为本申请实施例中采集省分系统中订单信息的流向示意图；

图5为本申请实施例提供的订单信息采集方法实施例三的流程示意图；

图6为本申请实施例提供的订单信息采集方法实施例四的流程示意图；

图7为本申请实施例提供的订单信息采集方式的汇总示意图；

图8为本申请实施例提供的订单信息采集系统实施例一的结构示意图；

图9为本申请实施例提供的订单信息采集系统实施例二的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下，对本申请实施例中的部分用语进行解释说明，以便于本领域技术人员理解：

oraclegoldengate软件是一种基于日志的结构化数据复制备份软件，它通过解析源数据库在线日志或归档日志获得数据的增量变化，再将这些变化应用到目标数据库，从而实现源数据库与目标数据库同步。

oraclegoldengate可以在异构的it基础结构(包括几乎所有常用操作系统平台和数据库平台)之间实现大量数据亚秒一级的实时复制，从而可以在应急系统、在线报表、实时数据仓库供应、交易跟踪、数据同步、集中/分发、容灾、数据库升级和移植、双业务中心等多个场景下应用。

插件是一种遵循一定规范的应用程序接口编写出来的程序，其只能运行在程序规定的系统平台下(可能同时支持多个平台)，而不能脱离指定的平台单独运行。所以，oraclegoldengate插件是oraclegoldengate软件平台的插件，其只能运行在oraclegoldengate软件平台上。

kafka是一个开源流处理平台，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据，这些动作流数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。kafka的目的是通过hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

本申请实施例提供的订单信息采集方法适用于订单信息采集系统。图1为本申请实施例提供的订单信息采集系统的结构示意图。如图1所示，该订单信息采集系统可以包括：至少一个省分系统11、总部系统12和处理系统13。

在本申请的实施例中，每个省分系统11均可以包括：省分存储主机111和省分处理主机112。每个省分系统11的省分存储主机111均可以获取其内部存储进程的信息修改记录，并基于该信息修改记录确定出该省分系统11的最新订单信息。其中，该最新订单信息可以是通过插入、删除、更新等方式得到的。本申请实施例并不限定最新订单信息的生成方式。

相应的，每个省分系统11的省分处理主机112可以获取上述确定的最新订单信息，并将该最新订单信息按照业务类型或数据量划分成多个子订单信息，并分别分发至总部系统12中的多个主题文件中。

示例性的，在本申请的实施例中，该总部系统12包括：至少一个消息通道集群，每个消息通道集群包括：至少一个主题文件。也即，每个消息通道集群中可以有若干个主题文件；同时由于消息通道集群是分布式系统，每个主题文件又分成若干个子文件，因而，每个省分处理主机112分发到该总部系统12的子订单信息则分布在各个主题文件的子文件中。

可选的，在本实施例中，该消息通道可以采用kafka的形式实现。

示例性的，该处理系统13也即数据采集系统，其可以从总部系统12的至少一个主题文件中上述最新订单信息的每个子订单信息，并对所有的子订单信息进行分析和数据归集处理，从而提取到该最新订单信息中的核心内容，进而得到该目标订单信息。

值得说明的是，本申请实施例提供的订单信息采集系统并不局限于包括省分系统、总部系统和处理系统，在某些应用场景下，其还可以包括其他设备，例如，用于对订单信息进行审计的稽核系统、用于监控订单处理周期的监控系统等，此处不再赘述。

本申请实施例提供的订单信息采集方法，省分系统获取存储单元的信息修改记录并基于该信息修改记录获取最新订单信息，将该最新订单信息分发至总部系统的至少一个主题文件中，该处理系统获取该总部系统中至少一个主题文件的子订单信息，并基于所有主题文件的子订单信息得到目标订单信息，该目标订单信息存储至用户查询平台中供用户查询。该技术方案可以保证每个订单信息环境的准确性和实时性，提高了订单信息查询结果的准确度。

下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请实施例提供的订单信息采集方法实施例一的流程示意图。该方法适用于图1所示的订单信息采集系统。示例性的，如图2所示，该订单信息采集方法可以包括如下步骤：

步骤21：对于至少一个省分系统中的任意一个省分系统，该省分系统获取存储单元的信息修改记录，并基于该信息修改记录获取最新订单信息。

可以理解的是，本申请的技术方案可以适用于订单信息采集系统中的任意一个省分系统，为了简化描述，下述以订单信息采集系统中的一个省分系统进行说明。

示例性的，在本申请的实施例中，当省分系统的存储单元中一旦有订单信息的更改时，例如，订单插入、更新、删除等操作时，该省分系统则可以获取该存储单元的信息修改记录，这时省分系统的提取进程则可以基于该信息修改记录获取到从该存储单元获取到该信息修改记录对应的最新订单信息。

步骤22：该省分系统将上述最新订单信息分发至该总部系统的至少一个主题文件中。

在本实施例中，省分系统的提取进程获取到最新订单信息后，可以将通过存储再提取的方式，将该最新订单信息传输至省分处理主机，这样省分处理主机可以对最新订单信息进行相应的处理，最后将处理后的最新订单信息分发至总部系统，并存储到至少一个主题文件中。

关于本步骤的实现原理可以参见下述图5或图6所示实施例中的记载，此处不再赘述。

步骤23：该处理系统获取总部系统中上述至少一个主题文件的子订单信息，基于所有主题文件的子订单信息得到目标订单信息，该目标订单信息存储至用户查询平台中供用户查询。

示例性的，在本实施例中，该数据采集系统与该总部系统具有一致的数据传输接口，因而，该处理系统可以实时从总部系统中总部消息通道的至少一个主题文件处获取存储在每个主题文件中的子订单信息。其中，每个最新订单信息包括多个子订单信息，且多个子订单信息可以被分发到总部系统的不同主题文件中。

值得说明的是，在本实施例中，以该处理系统获取上述最新订单信息的子订单信息进行说明。在实际应用中，该处理系统可以获取多个最新订单信息的子订单信息，后续再将同一个最新订单信息的所有子订单信息进行整合、分析，从而得到最新订单信息对应的目标订单信息。

示例性的，省分处理主机对每个最新订单信息进行处理得到的子订单信息可以携带订单标识，这样处理系统从总部系统的至少一个主题文件中获取到多个子订单信息后，可以根据每个子订单信息携带的订单标识，将订单标识一致的所有子订单信息进行汇总、整理、分析、处理和归集，从而得到信息准确的目标订单信息。

可选的，该目标订单信息可以是上述最新订单信息的一部分或全部，通常情况下，该目标订单信息是该最新订单信息的主要内容。

在本实施例中，处理系统基于从总部系统获取到的子订单信息确定出目标订单信息后，可以将该目标订单信息传输并存储至用户查询平台中，由该用户查询平台对外提供接口查询能力。

本申请实施例提供的订单信息采集方法，对于订单信息采集中的至少一个省分系统中的任意一个省分系统，该省分系统获取存储单元的信息修改记录并基于该信息修改记录获取最新订单信息，以及将该最新订单信息分发至总部系统的至少一个主题文件中，这样处理系统可以获取该总部系统中至少一个主题文件的子订单信息，并基于所有主题文件的子订单信息得到目标订单信息，该目标订单信息存储至用户查询平台中供用户查询。该技术方案无需开发针对不同省分系统的同步接口，能够获取到准实时的同步订单及相关属性信息，提高了查询结果的准确性，灵活性高。

示例性的，在上述实施例的基础上，图3为本申请实施例提供的订单信息采集方法实施例二的流程示意图。如图3所示，在该订单信息采集方法中，上述步骤21可以通过如下步骤实现：

步骤31：省分系统基于数据备份插件和日志回滚机制，抓取该存储单元的信息修改记录。

在本申请的实施例中，每个省分系统、总部系统等业务支撑系统均具有存储单元，存储单元可以用于存储对应业务支撑系统的相关信息，例如，订单信息、日志数据等。

示例性的，该省分系统中安装有与该存储单元对应的数据备份插件，且该存储单元的日志回滚机制处于开启状态，这样一旦存储单元有事务提交，利用该数据备份插件和日志回滚机制，该事务对应的信息修改记录均能够被获取到。

步骤32：该省分系统根据该信息修改记录，获取该信息修改记录对应的最新订单信息。

在本实施例中，省分系统通过分析该存储单元的信息修改记录，例如，信息插入、更新、删除等方式，再基于该信息修改记录查询存储单元，从该存储单元中获取该信息修改记录对应的最新订单信息。

在本实施例中，省分系统基于数据备份插件和日志回滚机制抓取该存储单元的信息修改记录，再根据该信息修改记录获取该信息修改记录对应的最新订单信息，从而在存储单元存在信息修改记录时可以获取到该信息修改记录完整的最新订单信息，为后续提取到准确的目标订单信息提供了条件。

进一步的，在本实施例的一种可能设计中，如图3所示，在上述步骤22之前，也即，在步骤32之后，该方法还可以包括如下步骤：

步骤33：省分系统将该最新订单信息存储至日志追踪文件中。

可选的，在本实施例中，由于省分系统中包括多个进程，多个进程之间存在通信局限性，因而，在省分系统获取到最新订单信息后可以首先将其存储到日志追踪文件中，这样省分系统的数据泵进程可以直接从该日志追踪文件中获取该最新订单信息，从而无需经过类型转换等处理操作。

步骤34：省分系统通过数据泵进程读取日志追踪文件中的最新订单信息并传输至省分处理主机。

在本实施例中，省分系统的数据泵进程可以直接从日志追踪文件中读取该最新订单信息，并通过省分存储主机和省分处理主机之间的数据接口，将该最新订单信息传输至省分处理主机。

可选的，该数据接口可以是传输控制协议/网际协议(transmissioncontrolprotocol/internetprotocol，tcp/ip)接口，因而，该数据泵进程可以通过tcp/ip将该最新订单信息传输至省分处理主机。

示例性的，图4为本申请实施例中采集省分系统中订单信息的流向示意图。该图4是在图1所示订单信息采集系统的基础上执行的。本实施例以一个省分系统进行举例说明。如图4所示，在该省分系统中，该省分存储主机包括：存储进程、提取进程、数据泵进程，以及设置在提取进程和数据泵进程之间作为信息传递的第一日志追踪文件。该省分处理主机包括：收集进程、数据分发进程，以及设置在收集进程和数据分发进程之间作为信息传递的第二日志追踪文件。

在本实施例中，该存储进程包括存储单元，当该存储单元有信息修改时，该存储进程可以获取该存储单元的信息修改记录，并基于该信息修改记录确定出该省分系统的最新订单信息，以及将其写入日志回滚机制。

相应的，提取进程可以从该日志回滚机制中提取到上述最新订单信息，并将其写入第一日志追踪文件。该数据泵进程从该第一日志追踪文件中读取该最新订单信息并将其传输至省分处理主机的收集进程。

省分处理主机的收集进程可以接收到的最新订单信息写入第二日志追踪文件，这样数据分发进程从该第二日志追踪文件中读取该最新订单信息并对其处理后分发至总部系统的至少一个主题文件中，例如，主题文件a、主题文件b和主题文件n。示例性的，该主题文件a、主题文件b和主题文件n位于消息通道集群中。

相应的，该处理系统可以从总部系统的消息通道集群包括的主题文件a、主题文件b和主题文件n中提取消息，从而，该处理系统可以执行消息提取，数据分析和数据归集操作，最后得到目标订单信息。

例如，假设该省分系统中的存储单元通过数据库实现时，例如，oracle数据库，则该oracle数据库对应的数据备份插件为oraclegoldengate插件(简称ogg插件)，oracle数据库的日志回滚机制即为redolog机制。

因而，在本实施例中，该省分系统中安装有与oracle数据库对应的ogg插件，同时该oracle数据库的redolog机制处于开启状态，由于redolog机制是oracle数据库为确保已经提交的事务不会丢失而建立的一个机制，所以，在该省分系统中，每次数据库提交的事务都可以被获取到，这样ogg插件的提取进程可以抓取到数据库的修改记录。

同理，上述数据泵进程可以通过ogg泵进程实现，收集进程可以通过ogg收集进程实现。

本申请实施例提供的订单信息采集方法，通过ogg插件、日志追踪文件和日志回归机制实现了订单信息的采集和传输，具有高效性、可扩展性及支持海量数据等特点，且数据同步方式的参数可配置，灵活性高。

示例性的，在上述任一实施例的基础上，图5为本申请实施例提供的订单信息采集方法实施例三的流程示意图。如图5所示，作为一种示例，上述步骤22可以通过如下步骤实现：

步骤51：省分系统确定该最新订单信息各部分的业务类型。

在本实施例中，省分系统通过对最新订单信息进行分析，确定出该最新订单信息的多个部分以及各个部分的业务类型。示例性的，若省分系统的订单信息是按照主表、子表等形式进行存储的，主表用于描述该订单信息包括的几个部分，子表用于描述每个部分的详细信息。子表的类型可以认为是该部分的业务类型。

例如，一个完整的订单信息包括：产品信息、订单信息、用户信息等多个部分，所以，省分系统可以首先确定出该最新订单信息的产品信息部分、订单信息部分、用户信息部分。

步骤52：省分系统根据该最新订单信息各部分的业务类型，将该最新订单信息拆分成至少一个第一子订单信息。

可选的，为了后续对订单信息的各个部分进行分发，省分系统可以首先基于各个部分的业务类型对最新订单信息进行拆分，对最新订单信息进行拆分，从而得到至少一个第一子订单信息。

步骤53：省分系统基于预设的分发规则，将上述至少一个第一子订单信息分发至总部系统的至少一个主题文件中。

在本实施例中，省分系统和总部系统中均配置有预设的分发规则，该分发规则是省分系统和总部系统双方约定好的规则。

一般情况下，每个第一子订单信息与至少一个主题文件相对应，且每个主题文件中也可以存储多个子订单信息，本申请实施例并不对第一子订单信息和主题文件的对应方式进行限定，其可以根据实际情况确定。

示例性的，省分系统通过对最新订单信息进行拆分得到至少一个子订单信息时，便可以基于系统内预设的分发规则，将上述至少一个第一子订单信息分发到总部系统的至少一个主题文件中，从而实现分发功能。

本申请实施例提供的订单信息采集方法，省分系统确定该最新订单信息各部分的业务类型，然后根据该最新订单信息各部分的业务类型，将该最新订单信息拆分成至少一个第一子订单信息，最后基于预设的分发规则，将上述至少一个第一子订单信息分发至总部系统的至少一个主题文件中。该技术方案，基于最新订单信息各部分的业务类型进行拆分，并分别分发至对应的主题文件，提高了后续数据整理、提取和归集的效率。

示例性的，图6为本申请实施例提供的订单信息采集方法实施例四的流程示意图。本实施例是上述步骤22的另一实现方式。具体的，如图6所示，上述步骤22还可以通过如下步骤实现：

步骤61：省分系统确定该最新订单信息各部分的数据量。

在本实施例中，省分系统通过对最新订单信息进行分析，确定出该最新订单信息各个部分的数据量。示例性的，若省分系统的订单信息按照主表、子表等形式存储后，其可以首先确定出该最新订单信息各部分的数据量。

步骤62：省分系统根据该最新订单信息各部分的数据量，将该最新订单信息拆分成至少一个第二子订单信息。

本步骤与上述图5所示实施例中的步骤52类似，省分系统可以首先基于各个部分的数据量，按照总部系统中各主题文件的数据容量将该最新订单信息进行拆分，从而得到至少一个第二子订单信息。

值得说明的，本实施例中的第二子订单信息与上述第一子订单信息只是为了表示两个不同的子订单信息，其并不表示顺序，在某些特殊情况下，该第二子订单信息与第一子订单信息包括的内容可以相同，当然在其他的情况下，两者包含的内容也可以不同。

步骤63：省分系统基于预设的分发规则，将该至少一个第二子订单信息分发至总部系统的至少一个主题文件中。

该步骤63的实现原理与上述图5所示实施例中步骤53的实现原理类似，此处不再赘述。

本申请实施例提供的订单信息采集方法，省分系统确定该最新订单信息各部分的数据量，根据该最新订单信息各部分的数据量，将该最新订单信息拆分成至少一个第二子订单信息，最后基于预设的分发规则，将该至少一个第二子订单信息分发至总部系统的至少一个主题文件中。该技术方案中，省分系统基于最新订单信息各部分的数据量进行拆分并分别分发至对应的主题文件中，同样提高了后续数据整理、提取和归集的效率。

示例性的，如图1和图4所示，该总部系统包括：至少一个消息通道集群，每个消息通道集群包括：至少一个主题文件。所以，在本实施例中，省分系统将读取的最新订单消息分发到总部系统，可以存储到不同消息通道集群的不同主题文件里。示例性的，该消息通道集群可以是kafka集群。

例如，对于kafka集群来说，kafka集群中间件中的消息是按主题分组的，每个kafka集群中可以有若干个主题文件；同时由于kafka是分布式系统，每个主题文件又分成若干个分文件；上述子订单信息就分布在各个主机系统上的分文件中，这样处理系统在读取消息时，需要读取每个主题文件下的所有分文件。

值得说明的是，本申请实施例提供的订单信息采集系统还可以包括稽核和监控系统，这样各个省份系统中的大量订单信息可以自动汇集到总部系统，并被处理系统采集到，这样稽核和监控系统就可以对处理系统中的目标订单信息进行监督。

例如，稽核和监控系统可以将关注点聚焦到处理系统中的某些订单异常的目标订单信息上，比如，目标订单信息在某环节处理时长特别的长，这时可以向处理系统发送提醒消息以使其优先处理这类订单等。

本实施例的订单信息采集系统在数据提取时，能够保证对原系统(省分系统、总部系统)影响小、侵入低，对数据变化响应快速，对流程中断和失败容忍度高等特点。

此外，本实施例的订单信息采集系统还可以为其他有需要的系统或者模块提供订单的实时查询服务。

在本申请实施例的一种可能设计中，图7为本申请实施例提供的订单信息采集方式的汇总示意图。如图7所示，该系统可以通过文件采集、实时接口采集、增量日志采集等多种方式实现订单信息采集的方案。

作为一种示例，对于运营商系统中各省分系统(例如，销售系统或生产系统)中的原始数据，各省分系统可以将历史订单信息和属性表等原始数据导出形成平面数据文件(例如，csv格式)，再传输至订单采集系统。

作为另一种示例，对于运营商系统中已具有的、且已实现实时同步业务传输的各省分系统，其可以通过实时业务接口采集和消息总线的方式进行订单采集。

作为再一种示例，对于运营商系统中各省分系统，若系统中安装有数据备份插件(例如，ogg插件)，这时，省分系统可以通过增量日志采集模块，即数据备份插件和消息总线的方式自动采集该系统中的待处理订单信息，其可以实时采集增量日志数据，来进行通信行业订单数据的分析。

本申请实施例通过上述多种数据采集方式与外部系统进行交互，减少了系统的耦合度及调用的难度，灵活度高。

下述为本申请系统实施例，可以用于执行本申请方法实施例。对于本申请系统实施例中未披露的细节，请参照本申请方法实施例。

图8为本申请实施例提供的订单信息采集系统实施例一的结构示意图。如图8所示，该订单信息采集系统可以包括：至少一个省分系统81、总部系统82和处理系统83。图8所示的实施例以一个省分系统进行说明。

对于至少一个省分系统中的任意一个省分系统，如图8所示，该省分系统81包括：第一获取模块811、第一处理模块812和分发模块813。

其中，该第一获取模块811，用于获取存储单元的信息修改记录；

该第一处理模块812，用于基于所述信息修改记录获取最新订单信息；

该分发模块813，用于将所述最新订单信息分发至所述总部系统82的至少一个主题文件中；

在本实施例中，该处理系统83包括：第二获取模块831、第二处理模块832。

该第二获取模块831，用于获取所述总部系统82中所述至少一个主题文件的子订单信息；

该第二处理模块832，用于基于所有主题文件的子订单信息得到目标订单信息，所述目标订单信息存储至用户查询平台中供用户查询。

在本实施例的一种可能设计中，该第一获取模块811，具体用于基于数据备份插件和日志回滚机制，抓取所述存储单元的信息修改记录；

该第一处理模块812，具体用于根据所述信息修改记录，获取所述信息修改记录对应的所述最新订单信息。

在本实施例的另一种可能设计中，该第一处理模块812，还用于在该分发模块813将所述最新订单信息分发至所述总部系统82的至少一个主题文件中之前，将所述最新订单信息存储至日志追踪文件中；

该分发模块813，具体用于通过数据泵进程读取所述日志追踪文件中的所述最新订单信息并传输至省分处理主机。

在本实施例的再一种可能设计中，该第一处理模块812，具体用于确定所述最新订单信息各部分的业务类型，根据所述最新订单信息各部分的业务类型，将所述最新订单信息拆分成至少一个第一子订单信息；

该分发模块813，具体用于基于预设的分发规则，将所述至少一个第一子订单信息分发至所述总部系统82的至少一个主题文件中。

在本实施例的又一种可能设计中，该第一处理模块812，具体用于确定所述最新订单信息各部分的数据量，根据所述最新订单信息各部分的数据量，将所述最新订单信息拆分成至少一个第二子订单信息；

该分发模块813，具体用于基于预设的分发规则，将所述至少一个第二子订单信息分发至所述总部系统82的至少一个主题文件中。

本申请实施例提供的系统，可用于执行图2至图6所示实施例中的方法，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上系统的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，确定模块可以为单独设立的处理元件，也可以集成在上述系统的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述系统的存储器中，由上述系统的某一个处理元件调用并执行以上确定模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(applicationspecificintegratedcircuit，asic)，或，一个或多个微处理器(digitalsignalprocessor，dsp)，或，一个或者多个现场可编程门阵列(fieldprogrammablegatearray，fpga)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessingunit，cpu)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，soc)的形式实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk(ssd))等。

图9为本申请实施例提供的订单信息采集系统实施例二的结构示意图。如图9所示，该系统可以包括：处理器91、存储器92、通信接口93和系统总线94，所述存储器92和所述通信接口93通过所述系统总线94与所述处理器91连接并完成相互间的通信，所述存储器92用于存储计算机执行指令，所述通信接口93用于和其他设备进行通信，所述处理器91执行所述计算机指令时实现如上述图2至图6所示实施例的方案。

该图9中提到的系统总线可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。所述系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于实现数据库访问系统与其他设备(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(randomaccessmemory，ram)，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

上述的处理器可以是通用处理器，包括中央处理器cpu、网络处理器(networkprocessor，np)等；还可以是数字信号处理器dsp、专用集成电路asic、现场可编程门阵列fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可选的，本申请实施例还提供一种存储介质，所述存储介质中存储有指令，当其在计算机上运行时，使得计算机执行如上述图2至图6所示实施例的方法。

可选的，本申请实施例还提供一种运行指令的芯片，所述芯片用于执行上述图2至图6所示实施例的方法。

本申请实施例还提供一种程序产品，所述程序产品包括计算机程序，所述计算机程序存储在存储介质中，至少一个处理器可以从所述存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序时可实现上述图2至图5所示实施例的方法。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中，a，b，c可以是单个，也可以是多个。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

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

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