CN110704465B - 一种处理业务工单表的方法、装置及存储介质 - Google Patents

Abstract

一种处理业务工单表的方法、装置及存储介质，该方法包括：创建业务工单表，基于受理工单监听处理器获取的工单数据与上游系统进行通信交互；根据工单数据生成第一时长内的受理工单数据；通过产品工单监听处理器根据受理工单数据与产品平台进行交互处理，生成与受理工单数据对应的产品工单数据；根据产品工单数据开通产品工单，将产品工单的工单施工结果状态发送给上游系统；在预设时长后，将第一时长内的受理工单数据和产品工单数据，分别对历史时长内的受理工单数据和产品工单数据进行切分，分别添加至受理工单历史表和产品工单历史表。采用本方案能够避免对数据库造成很大的数据查询和读写压力，提高系统处理性能和加快业务工单施工效率。

Description

一种处理业务工单表的方法、装置及存储介质

技术领域

本申请实施例涉及电信业务技术领域，尤其涉及一种处理业务工单表的方法、装置及存储介质。

背景技术

随着电信传统业务和新兴ICT业务的迅猛发展，尤其近年来数字化、智能化技术的不断深入，电信业务工单的受理接入和产品服务越来越多，且日均交易、并发体量逐渐庞大。

在对现有技术的研究和实践过程中，本申请实施例的发明人发现，大多数工单处理系统存在并发处理量小、容纳规模不足、处理过程耗时长、传输延时、用户体验差等缺点。

发明内容

本申请实施例提供了一种处理业务工单表的方法、装置及存储介质，能够解决现有系统中工单处理并发处理量小、容纳规模不足、处理过程耗时长、传输延时、用户体验差等业务和技术问题。

第一方面中，本申请实施例提供一种处理业务工单表的方法，所述方法包括：

创建业务工单表，所述业务工单表包括受理工单表、产品工单表、受理工单历史表和产品工单历史表中的至少一项业务工单数据；

通过受理工单监听处理器获取上游系统发送的工单数据，基于所述工单数据与所述上游系统进行通信交互；

在本次通信交互完成后，根据所述工单数据生成第一时长内的受理工单数据；

通过产品工单监听处理器根据所述受理工单数据与产品平台进行交互处理，并生成与所述受理工单数据对应的产品工单数据；

根据所述产品工单数据开通产品工单，获取所述产品工单的施工结果状态；

将所述工单施工结果状态发送给所述上游系统；

在预设时长后，将所述第一时长内的受理工单数据和产品工单数据，分别对所述历史时长内的受理工单数据和产品工单数据进行切分，将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表。

一种可能的设计中，所述受理工单表和受理工单历史表的字段信息相同，均包括主键ID、交易流水号、交易时间、业务类型、省份编码、地区编码、客户ID、客户编码、客户名称、联系电话、客户描述、订购产品ID和产品属性信息。

一种可能的设计中，所述方法还包括：

设置生产者/消费者模式、序号管理器、线程之间的无锁交换方式、以及线程网络通信机制；

其中，所述生产者/消费者模式是指产生数据的生产者将数据放入缓冲区，处理数据的消费者从缓冲区取出所述数据；

所述序号管理器用于基于队列模型，监听和响应计数器，使用顺序递增序号管理消息的处理进度；

所述线程之间的无锁交换方式是指基于序号管理器的实现，生产者、消费者都可以记录自己的次序，允许多个生产者与多个消费者共享相同的数据结构；

所述线程网络通信机制是指具备跨越多种传输协议的套接字的通信框架，基于消息队列的多线程网络库，对套接字类型、连接处理、帧、路由的底层信息进行抽象处理。

一种可能的设计中，所述将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表之前，所述方法还包括：

基于DataX框架将工作拆分为多个任务，将多个任务合并到任务组中运行；

基于DataX框架在离线模式下同步任务，以及基于逻辑判断策略对数据进行迁移和处理。

第二方面中，本申请实施例提供一种用于处理业务工单表的装置，具有实现对应于上述第一方面提供的处理业务工单表的方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。

一种可能的设计中，所述用于处理业务工单表的装置包括：

处理模块，用于创建业务工单表，所述业务工单表包括受理工单表、产品工单表、受理工单历史表和产品工单历史表中的至少一项业务工单数据；

收发模块，用于通过受理工单监听处理器获取上游系统发送的工单数据，基于所述工单数据与所述上游系统进行通信交互；

所述处理模块还用于在本次通信交互完成后，根据所述工单数据生成第一时长内的受理工单数据；通过产品工单监听处理器根据所述受理工单数据与产品平台进行交互处理，并生成与所述受理工单数据对应的产品工单数据；根据所述产品工单数据开通产品工单，通过所述收发模块获取所述产品工单的施工结果状态；通过所述收发模块将所述工单施工结果状态发送给所述上游系统；在预设时长后，将所述第一时长内的受理工单数据和产品工单数据，分别对所述历史时长内的受理工单数据和产品工单数据进行切分，将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表。

一种可能的设计中，所述受理工单表和受理工单历史表的字段信息相同，均包括主键ID、交易流水号、交易时间、业务类型、省份编码、地区编码、客户ID、客户编码、客户名称、联系电话、客户描述、订购产品ID和产品属性信息。

一种可能的设计中，所述处理模块还用于：

设置生产者/消费者模式、序号管理器、线程之间的无锁交换方式、以及线程网络通信机制；

其中，所述生产者/消费者模式是指产生数据的生产者将数据放入缓冲区，处理数据的消费者从缓冲区取出所述数据；

所述序号管理器用于基于队列模型，监听和响应计数器，使用顺序递增序号管理消息的处理进度；

所述线程之间的无锁交换方式是指基于序号管理器的实现，生产者、消费者都可以记录自己的次序，允许多个生产者与多个消费者共享相同的数据结构；

所述线程网络通信机制是指具备跨越多种传输协议的套接字的通信框架，基于消息队列的多线程网络库，对套接字类型、连接处理、帧、路由的底层信息进行抽象处理。

一种可能的设计中，所述处理模块在将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表之前，还用于：

基于DataX框架将工作拆分为多个任务，将多个任务合并到任务组中运行；

基于DataX框架在离线模式下同步任务，以及基于逻辑判断策略对数据进行迁移和处理。

本申请实施例又一方面提供了一种计算机装置，其包括至少一个连接的处理器、存储器和收发器，其中，所述存储器用于存储计算机程序，所述处理器用于调用所述存储器中的计算机程序来执行上述第一方面所述的方法。

本申请实施例又一方面提供了一种计算机可读存储介质，其包括指令，当其在计算机上运行时，使得计算机执行上述第一方面所述的方法。

相较于现有技术，本申请实施例提供的方案中，基于所述工单数据与所述上游系统进行通信交互，将处理的工单数据插入到工单处理表，与下游产品系统交互，以完成工单，在预设时长后将工单数据挪入工单历史表。通过在工单的核心交互环节引入消息监控处理机制，在随后的工单传递处理过程中摒弃单一数据库表批量插入/变更、一级大量查询的架构设计，采用数据水平切分方式，采用本方案能够避免对数据库造成很大的数据查询和读写压力，进一步提高系统处理性能，加快业务工单施工效率，满足当前电信领域业务工单体量大、追求用户体验至上的需求。

附图说明

图1为本申请实施例中处理业务工单表的方法的一种流程示意图；

图2为本申请实施例中用于处理业务工单表的装置的一种结构示意图；

图3为本申请实施例中计算机装置的一种结构示意图。

具体实施方式

本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本申请实施例中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个系统中，或一些特征可以忽略，或不执行，另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合或通信连接可以是电性或其他类似的形式，本申请实施例中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请实施例方案的目的。

本申请实施例供了一种处理业务工单表的方法、装置及存储介质，可用于电信业务工单，适用于单机部署和集群服务部署，为客户和合作伙伴根据自身资源情况提供最优选择。

参照图1，以下介绍本申请实施例所提供的一种处理业务工单表的方法，所述方法包括：

101、创建业务工单表。

其中，所述业务工单表包括受理工单表、产品工单表、受理工单历史表和产品工单历史表中的至少一项业务工单数据。

一些实施方式中，所述受理工单表和受理工单历史表的字段信息相同，均包括主键ID、交易流水号、交易时间、业务类型、省份编码、地区编码、客户ID、客户编码、客户名称、联系电话、客户描述、订购产品ID和产品属性信息。

所述产品工单表和产品工单历史表的字段信息相同，都包括主键ID、受理工单流水号、省份编码、地区编码、客户ID、客户编码、客户名称、开通产品、交易类型、产品档位、产品资费、交易时间和响应状态。

所述主键ID为随机生成的32位字符串，用于唯一标识该条数据；

所述交易流水号为业务工单的流水号，由上游系统下发订单时生成；

所述交易时间为工单处理时的系统时间；

所述业务类型为客户需要办理的业务类型；

所述省份编码为业务工单所属的省份；

所述地区编码为业务工单所属的地市；

所述客户ID为客户在电信客户关系管理系统唯一标识；

所述客户编码为客户在电信客户关系管理系统对应的编码；

所述客户名称为客户在电信客户关系管理系统对应的名称；

所述联系电话为客户联系方式；

所述客户描述为客户的简介描述信息；

所述订购产品ID为客户本次需要订购的产品唯一标识；

所述产品属性信息为客户本次订购的产品详细属性。

所述产品工单表和产品工单历史表的字段信息相同，都包括主键ID、受理工单流水号、省份编码、地区编码、客户ID、客户编码、客户名称、开通产品、交易类型、产品档位、产品资费、交易时间、响应状态；

所述主键ID为随机生成的32位字符串，用于唯一标识该条数据；

所述受理工单流水号为对应业务受理工单的流水号；

所述省份编码为业务工单所属的省份；

所述地区编码为业务工单所属的地市；

所述客户ID为客户在电信客户关系管理系统唯一标识；

所述客户编码为客户在电信客户关系管理系统对应的编码；

所述客户名称为客户在电信客户关系管理系统对应的名称；

所述开通产品为客户本次需要开通的产品信息；

所述交易类型为本次开通产品对应类型，区分新增\变更\退订；

所述产品档位为客户本次订购的产品对应的档位；

所述产品资费为客户本次订购的产品对应的资费；

所述交易时间为工单处理时的系统时间；

所述响应状态为该工单的施工结果状态(成功\失败)。

102、通过受理工单监听处理器获取上游系统发送的工单数据，基于所述工单数据与所述上游系统进行通信交互；

一些实施方式中，所述受理工单监听处理器可在系统中配置初始化的生产者\消费者任务数量(例如选择20)，配置每个生产者\消费者的初始化线程大小(例如选择25)。

一些实施方式中，还可引入集群服务配置，例如配置各服务节点的启动和交互信息，具体规格参考依据为：单台配置16C(处理器CPU)、64G(内存)、2*500G(磁盘)，满足日均400万规模性能优越；参考依据非固定标准，需要结合实际业务情况考虑，集群部署非简单的数学加法，如使用上述配置5台进行集群部署，与惯常配置的日均400*5万处理量相比，本发明经过集群配置和参数配置可以达到日均5000万规模的处理能力。可见，通过与上游系统建立一种无锁的消息处理机制，能够快速的、无竞争的基于所述工单数据与所述上游系统进行通信交互。

103、在本次通信交互完成后，根据所述工单数据生成第一时长内的受理工单数据；

其中，第一时长可以是指几天、一天、几小时等时段，本申请不对此作限定。

104、通过产品工单监听处理器根据所述受理工单数据与产品平台进行交互处理，并生成与所述受理工单数据对应的产品工单数据；

105、根据所述产品工单数据开通产品工单，获取所述产品工单的施工结果状态，将所述工单施工结果状态发送给所述上游系统；

106、在预设时长后，将所述第一时长内的受理工单数据和产品工单数据，分别对所述历史时长内的受理工单数据和产品工单数据进行切分，将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表。

例如，当系统时间为凌晨2:00-4:00时，则将前一天受理工单数据和产品工单数据水平切入到历史表中；凌晨一般为业务量小、系统空闲时间，系统任务调度触发将工单处理表数据水平切入历史表，提高工单处理表检索和处理效率，查询历史数据到历史表中查询即可。

与现有机制相比，本申请实施例中，基于所述工单数据与所述上游系统进行通信交互，将处理的工单数据插入到工单处理表，与下游产品系统交互，以完成工单，在预设时长后将工单数据挪入工单历史表。通过在工单的核心交互环节引入消息监控处理机制，在随后的工单传递处理过程中摒弃单一数据库表批量插入/变更、一级大量查询的架构设计，采用数据水平切分方式，采用本方案能够避免对数据库造成很大的数据查询和读写压力，进一步提高系统处理性能，加快业务工单施工效率，满足当前电信领域业务工单体量大、追求用户体验至上的需求。

可选的，在本申请实施例的一些实施例中，所述方法还包括：

设置生产者/消费者模式、序号管理器、线程之间的无锁交换方式、以及线程网络通信机制。以下分别进行介绍：

一、生产者/消费者模式

所述生产者/消费者模式是指产生数据的生产者将数据放入缓冲区，处理数据的消费者从缓冲区取出所述数据。具体来说，所述生产者/消费者模式涉及两个组件，一个组件负责生产数据，这些数据由另一个组件来负责处理(组件有很多分类，如：类、函数、线程等，本发明具体指线程)。产生数据的组件称为生产者，处理数据的组件就称为消费者，同时还要引入缓冲区的概念，作为一个中介，生产者把数据放入缓冲区，而消费者从缓冲区取出数据，这样就构成了一个完整的生产者/消费者模式。之所以引入缓冲区，主要为解耦，使得生产者和消费者依赖于缓冲区，不直接依赖，降低了两者之间的交换成本。同时，解决了数据并发处理和忙闲不均的问题，生产者和消费者是两个独立的并发主体，生产者把生产出来的数据放入缓冲区，就可以继续生产下一个数据；如果生产数据的速度时快时慢，缓冲区的好处就体现出来了，当数据生产快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中，等生产者的生产速度慢下来，消费者再慢慢处理掉。

二、序号管理器

所述序号管理器用于基于队列模型，监听和响应计数器，使用顺序递增序号管理消息的处理进度。具体来说，使用顺序递增序号来管理消息的处理进度，即定义一个64位long整数型，从1开始，平滑型增长，记录生产者的生产编号，记录消费者的消费编号。序号管理器底层基于队列模型，遵循先进先出原则，设置监听响应中央计数器，对每个生产者和消费者都有一个次序计数器，每个生产者、消费者都能设定和领取自己的任务，都能够操作自己的次序计数器。中央计数器设置状态位，0代表“可写入”，1代表“可读取”，生产者和消费者都能够通过中央计数器获知对方的计数器所处的次序和状态为，这样，生产者和消费者均能够确保所处次序位置是空闲可写入\可读取状态。

三、所述线程之间的无锁交换方式

所述线程之间的无锁交换方式是指基于序号管理器的实现，生产者、消费者都可以记录自己的次序，允许多个生产者与多个消费者共享相同的数据结构。可见，该线程间的交换方式不再是通过资源抢占获得执行权力，而是达到了真正的无锁化。

四、线程网络通信机制

所述线程网络通信机制是指具备跨越多种传输协议的套接字的通信框架，基于消息队列的多线程网络库，对套接字类型、连接处理、帧、路由的底层信息进行抽象处理。

各生产者、消费者通过在执行器(executor)中自动生成任务ID(taskId)，各自分工、交互进行，将数据通过网络传输的方式传递出去。

该通信框架提供跨越多种传输协议的套接字，是一个可伸缩，可并行运行，分布式部署的高效通信框架。

本申请实施例中，并发是指两个或两个以上的任务同时并行的执行，但是也要通过争抢资源才得以执行，争抢的资源可能是数据库、文件系统、套接字、甚至于内存中的一块区域。并发执行包括两个方面：互斥性和改变的可见性。互斥性是指线程对资源进行争用状态的改变的管理，而改变可见性是指控制何时这种改变对其他线程可见。在任何并发的环境中，争用写操作是花费最大代价的，为了支持多个并发的线程对同一块资源进行写操作是需要花费复杂而昂贵的代价来进行协调的。锁提供了互斥性并且确保改变对其他线程的可见性以一种命令式的方式发生，但锁的代价消耗是巨大的，因为它们当遇到争用时需要进行仲裁。这种仲裁是通过一种上下文切换到操作系统的内核，挂起线程等待锁的释放，在这样的上下文切换过程中，也会交还控制权给操作系统，操作系统此时可能同时决定去做一些其他的清理工作，这样正在执行中的上下文对象将会丢失之前预读的缓存中的数据和指令。

为便于理解，以具体实例为例。本发明对生产者和消费者传统的缓冲区进行优化，例如将底层数据结构配置为固定大小的数组(假设为：Size)，形成环形的缓冲区(假设命名为：Ring)。生产者根据自身所需向序号管理器发出指令要求，序号管理器监控并分配其所需的序号大小(假设为：Seq)，所有生产者的序号大小取整运算，可按照Total(Seq)/Size)运算得出生产数据在环形(Ring)中的循环次数；对序号大小进行取余运算，可按照Seq％Size)运算得到生产数据所处的数组游标Size[i]和下一生产者起始的位置，i为0～Size-1之间的整数。消费者的读取机制同理，同时，序号管理器会实时将数组对应位置的状态，通知生产者或消费者，0代表状态为“可写入”，1代表状态为“可读取”。举例来说：

初始化数组A：Size为10，下标A[0]～A[9]；

生产者1：需要生产消息6个，序号管理器分配生产序号6；

生产者2：需要生产消息5个，序号管理器将生产序号自增至11；

消费者1：需要消费消息5个，序号管理器分配消费序号5；

消费者2：需要消费消息3个，序号管理器将消费序号自增至8；

得出结果：

生产者1：

6％10＝6，对应的数组元素为A[0]～A[5]，A[6]为下一个生产者起始的数组元素；

生产者2：

11/10＝1，11>10*1说明循环次数达到第2次；11％10＝1，A[1]为下一个生产者起始的数组元素，生产者2需要的5个元素对应的数组元素为A[6]～A[9]和下一循环的A[0]；

消费者1：

5％10＝5，对应的数组元素为A[0]～A[4]，A[5]为下一个消费者起始的数组元素；

消费者2：

8/10＝0,说明循环次数还处在第1次内，数组大小满足消费，8％10＝8，A[8]为下一个消费者起始的数组元素，消费者2需要的3个元素对应的数组元素为A[5]～A[7]。

可选的，在本申请实施例的一些实施例中，所述将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表之前，所述方法还包括：

基于DataX框架将工作(job)拆分为多个任务(task)，将多个任务合并到任务组中运行；

基于DataX框架在离线模式下同步任务，以及基于逻辑判断策略对数据进行迁移和处理。

其中，DataX是一个异构数据源离线同步工具，实现包括关系型数据库(MySQL、Oracle等)、FTP等各种异构数据源之间稳定高效的数据同步功能。在DataX的逻辑模型中包括job、task两个维度，通过将job进行task拆分，然后将task合并到taskGroup进行运行。

job实例运行在jobContainer容器中，它是所有任务的master，负责初始化、拆分、调度、运行、回收、监控和汇报，但它并不做实际的数据同步操作。

Job:Job是DataX用以描述从一个源头到一个目的端的同步作业，是DataX数据同步的最小业务单元。比如：从一张mysql的表同步到odps的一个表的特定分区。

Task:Task是为最大化而把Job拆分得到的最小执行单元。比如：读一张有1024个分表的mysql分库分表的Job，拆分成1024个读Task，用若干个并发执行。

TaskGroup:描述的是一组Task集合。在同一个TaskGroupContainer执行下的Task集合称之为TaskGroup。

JobContainer:Job执行器，负责Job全局拆分、调度、前置语句和后置语句等工作的工作单元。类似Yarn中的JobTracker。

TaskGroupContainer:TaskGroup执行器，负责执行一组Task的工作单元，类似Yarn中的TaskTracker。

图1所对应的实施例中所提及的任一技术特征也同样适用于本申请实施例中的图2和图3所对应的实施例，后续类似之处不再赘述。

以上对本申请实施例中一种处理业务工单表的方法进行说明，以下对执行上述处理业务工单表的装置进行介绍。

上面对本申请实施例中的一种处理业务工单表的方法进行了描述，下面对本申请实施例中的用于处理业务工单表的装置进行描述。

参阅图2，如图2所示的一种用于处理业务工单表的装置的结构示意图，其可应用于电信业务。本申请实施例中的用于处理业务工单表的装置能够实现对应于上述图1所对应的实施例中所执行的处理业务工单表的方法的步骤。用于处理业务工单表的装置实现的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。所述用于处理业务工单表的装置可包括处理模块和收发模块，所述处理模块和所述收发模块的功能实现可参考图1所对应的实施例中所执行的操作，此处不作赘述。例如，所述处理模块可用于控制所述输入输出模块的输入输出操作，以及控制所述显示模块的显示操作。

一些实施方式中，所述处理模块可用于创建业务工单表，所述业务工单表包括受理工单表、产品工单表、受理工单历史表和产品工单历史表中的至少一项业务工单数据；

所述收发模块可用于通过受理工单监听处理器获取上游系统发送的工单数据，基于所述工单数据与所述上游系统进行通信交互；

所述处理模块还用于在本次通信交互完成后，根据所述工单数据生成第一时长内的受理工单数据；通过产品工单监听处理器根据所述受理工单数据与产品平台进行交互处理，并生成与所述受理工单数据对应的产品工单数据；根据所述产品工单数据开通产品工单，通过所述收发模块获取所述产品工单的施工结果状态；通过所述收发模块将所述工单施工结果状态发送给所述上游系统；在预设时长后，将所述第一时长内的受理工单数据和产品工单数据，分别对所述历史时长内的受理工单数据和产品工单数据进行切分，将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表。

与现有机制相比，本申请实施例中，所述处理模块基于所述工单数据与所述上游系统进行通信交互，将处理的工单数据插入到工单处理表，与下游产品系统交互，以完成工单，在预设时长后将工单数据挪入工单历史表。通过在工单的核心交互环节引入消息监控处理机制，在随后的工单传递处理过程中摒弃单一数据库表批量插入/变更、一级大量查询的架构设计，采用数据水平切分方式，采用本方案能够避免对数据库造成很大的数据查询和读写压力，进一步提高系统处理性能，加快业务工单施工效率，满足当前电信领域业务工单体量大、追求用户体验至上的需求。

一些实施方式中，所述受理工单表和受理工单历史表的字段信息相同，均包括主键ID、交易流水号、交易时间、业务类型、省份编码、地区编码、客户ID、客户编码、客户名称、联系电话、客户描述、订购产品ID和产品属性信息。

一些实施方式中，所述处理模块还用于：

设置生产者/消费者模式、序号管理器、线程之间的无锁交换方式、以及线程网络通信机制；

其中，所述生产者/消费者模式是指产生数据的生产者将数据放入缓冲区，处理数据的消费者从缓冲区取出所述数据；

所述序号管理器用于基于队列模型，监听和响应计数器，使用顺序递增序号管理消息的处理进度；

所述线程之间的无锁交换方式是指基于序号管理器的实现，生产者、消费者都可以记录自己的次序，允许多个生产者与多个消费者共享相同的数据结构；

所述线程网络通信机制是指具备跨越多种传输协议的套接字的通信框架，基于消息队列的多线程网络库，对套接字类型、连接处理、帧、路由的底层信息进行抽象处理。

一些实施方式中，所述处理模块在将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表之前，还用于：

基于DataX框架将工作拆分为多个任务，将多个任务合并到任务组中运行；

基于DataX框架在离线模式下同步任务，以及基于逻辑判断策略对数据进行迁移和处理。

上面从模块化功能实体的角度对本申请实施例中的网络认证服务器和终端设备进行了描述，下面从硬件处理的角度分别对本申请实施例中的网络认证服务器和终端设备进行描述。需要说明的是，在本申请实施例图2所示的实施例中的收发模块对应的实体设备可以为输入/输出单元，处理模块对应的实体设备可以为处理器，显示模块所对应的实体设备可以是显示屏等显示单元。图2所示的装置可以具有如图3所示的结构，当图2所示的装置具有如图3所示的结构时，图3中的处理器和收发器能够实现前述对应该装置的装置实施例提供的处理模块和收发模块相同或相似的功能，图3中的中央存储器存储处理器执行上述处理业务工单表的方法时需要调用的计算机程序。在本申请实施例图2所示的实施例中的收发模块所对应的实体设备可以为输入输出接口，处理模块对应的实体设备可以为处理器。

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

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

另外，在本申请实施例各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

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

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

Claims (10)

1.一种处理业务工单表的方法，其特征在于，所述方法包括：

创建业务工单表，所述业务工单表包括受理工单表、产品工单表、受理工单历史表和产品工单历史表中的至少一项业务工单数据；

通过受理工单监听处理器获取上游系统发送的工单数据，基于所述工单数据与所述上游系统进行通信交互；

在本次通信交互完成后，根据所述工单数据生成第一时长内的受理工单数据；

通过产品工单监听处理器根据所述受理工单数据与产品平台进行交互处理，并生成与所述受理工单数据对应的产品工单数据；

根据所述产品工单数据开通产品工单，获取所述产品工单的施工结果状态；

将所述工单施工结果状态发送给所述上游系统；

在预设时长后，将所述第一时长内受理的工单数据和产品工单数据，分别对所述第一时长内的受理工单数据和产品工单数据进行切分，将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表。

2.根据权利要求1所述的方法，其特征在于，所述受理工单表和受理工单历史表的字段信息相同，均包括主键ID、交易流水号、交易时间、业务类型、省份编码、地区编码、客户ID、客户编码、客户名称、联系电话、客户描述、订购产品ID和产品属性信息。

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

设置生产者/消费者模式、序号管理器、线程之间的无锁交换方式、以及线程网络通信机制；

其中，所述生产者/消费者模式是指产生数据的生产者将数据放入缓冲区，处理数据的消费者从缓冲区取出所述数据；

所述序号管理器用于基于队列模型，监听和响应计数器，使用顺序递增序号管理消息的处理进度；

所述线程之间的无锁交换方式是指基于序号管理器的实现，生产者、消费者记录自己的次序，允许多个生产者与多个消费者共享相同的数据结构；

所述线程网络通信机制是指具备跨越多种传输协议的套接字的通信框架，基于消息队列的多线程网络库，对套接字类型、连接处理、帧、路由的底层信息进行抽象处理。

4.根据权利要求3所述的方法，其特征在于，所述将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表之前，所述方法还包括：

基于DataX框架将工作拆分为多个任务，将多个任务合并到任务组中运行；

基于DataX框架在离线模式下同步任务，以及基于逻辑判断策略对数据进行迁移和处理。

5.一种用于处理业务工单表的装置，其特征在于，所述装置包括：

处理模块，用于创建业务工单表，所述业务工单表包括受理工单表、产品工单表、受理工单历史表和产品工单历史表中的至少一项业务工单数据；

收发模块，用于通过受理工单监听处理器获取上游系统发送的工单数据，基于所述工单数据与所述上游系统进行通信交互；

所述处理模块还用于在本次通信交互完成后，根据所述工单数据生成第一时长内的受理工单数据；通过产品工单监听处理器根据所述受理工单数据与产品平台进行交互处理，并生成与所述受理工单数据对应的产品工单数据；根据所述产品工单数据开通产品工单，通过所述收发模块获取所述产品工单的施工结果状态；通过所述收发模块将所述工单施工结果状态发送给所述上游系统；在预设时长后，将所述第一时长内的受理工单数据和产品工单数据，分别对所述历史时长内的受理工单数据和产品工单数据进行切分，将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表。

6.根据权利要求5所述的装置，其特征在于，所述受理工单表和受理工单历史表的字段信息相同，均包括主键ID、交易流水号、交易时间、业务类型、省份编码、地区编码、客户ID、客户编码、客户名称、联系电话、客户描述、订购产品ID和产品属性信息。

7.根据权利要求6所述的装置，其特征在于，所述处理模块还用于：

设置生产者/消费者模式、序号管理器、线程之间的无锁交换方式、以及线程网络通信机制；

其中，所述生产者/消费者模式是指产生数据的生产者将数据放入缓冲区，处理数据的消费者从缓冲区取出所述数据；

所述序号管理器用于基于队列模型，监听和响应计数器，使用顺序递增序号管理消息的处理进度；

所述线程之间的无锁交换方式是指基于序号管理器的实现，生产者、消费者记录自己的次序，允许多个生产者与多个消费者共享相同的数据结构；

所述线程网络通信机制是指具备跨越多种传输协议的套接字的通信框架，基于消息队列的多线程网络库，对套接字类型、连接处理、帧、路由的底层信息进行抽象处理。

8.根据权利要求7所述的装置，其特征在于，所述处理模块在将切分后的所述受理工单数据添加至受理工单历史表，以及将切分后的所述产品工单数据添加至产品工单历史表之前，还用于：

基于DataX框架将工作拆分为多个任务，将多个任务合并到任务组中运行；

基于DataX框架在离线模式下同步任务，以及基于逻辑判断策略对数据进行迁移和处理。

9.一种计算机装置，其特征在于，所述装置包括：

至少一个处理器、存储器和收发器；

其中，所述存储器用于存储计算机程序，所述处理器用于调用所述存储器中存储的计算机程序来执行如权利要求1-4中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，其包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-4中任一项所述的方法。

Images