CN114422594A - 业务处理方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种业务处理方法、装置、计算机设备和存储介质。所述方法包括：当与服务端的通信网络故障时，获取缓存在本地的指令集合；指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到；确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；根据编号从指令集合中获取下一条指令进行处理。采用本方法能够提高数据利用率，减少资源浪费。

Description

业务处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种业务处理方法、装置、计算机设备和存储介质。

背景技术

随着互联网技术的发展，服务端-客户端模式已经深入到各行各业。在业务的处理过程中，客户端一般情况下都需要基于服务端的信息来做出相应的行为。但是，客户端和服务端之间可能因各种原因而导致网络不可用。而网络不可用的情况下，客户端是无法接收到服务端信息的，从而通常会导致客户端停止工作。传统为了保证网络不可用时仍然能够正常工作，通常预先将服务端的指令全部提前拉取到客户端，在网络不可用时客户端处理提前拉取的指令。

然而，由于客户端工作时长并不固定以及客户端与服务端的网络不可用的概率非常低，传统全部拉取的处理方式导致提前拉取的数据利用率非常的低，从而导致资源浪费。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高利用率减少资源浪费的业务处理方法、装置、计算机设备和存储介质。

一种业务处理方法，其特征在于，所述方法包括：

当与服务端的通信网络故障时，获取缓存在本地的指令集合；所述指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到；

确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；

根据所述编号从所述指令集合中获取下一条指令进行处理。

在其中一个实施例中，所述拉取数量的确定，包括：

统计前一天在线向服务端请求指令的请求总数量和请求成功数量；

根据所述请求总数量和所述请求成功数量计算前一天的在线作业失败率；

根据前一天的所述在线作业失败率确定当天的拉取数量。

在其中一个实施例中，所述根据所述请求总数量和所述请求成功数量计算前一天的在线作业失败率，包括：

计算所述请求成功数量与所述请求总数量的比值，得到在线作业成功率；

根据所述在线作业成功率确定在线作业失败率。

在其中一个实施例中，所述根据前一天的所述在线作业失败率确定当天的拉取数量，包括：

获取服务端的总指令数量；

将所述在线作业失败率与所述总指令数量相乘，得到拉取数量。

在其中一个实施例中，根据拉取所述数量，预先从服务端拉取指令得到指令集合，包括：

根据服务端中各指令的编号，将第一个编号对应的指令作为拉取起点，最后一个编号对应的指令作为拉取终点；

从所述拉取起点开始往所述拉取终点进行拉取，得到与所述拉取数量相等的指令组成指令集合。

在其中一个实施例中，根据拉取数量，预先从服务端拉取指令得到指令集合，包括：

根据服务端中各指令的编号，将最后一个编号对应的指令作为拉取起点，第一个编号对应的指令作为拉取终点；

从所述拉取起点开始往所述拉取终点进行拉取，得到与所述拉取数量相等的指令组成指令集合。

在其中一个实施例中，所述根据所述编号从所述指令集合中获取下一条指令进行处理，包括：

将所述编号作为匹配编号，从所述指令集合中确定编号位于所述匹配编号之后的指令；

从编号位于所述匹配编号之后的指令中，获取编号与所述匹配编号最接近的指令作为下一条指令进行处理；

将当前作为下一条指令的编号作为匹配编号，返回从所述指令集合中确定编号位于所述匹配编号之后的指令的步骤，直至所述指令集合中各指令均被处理完成。

一种业务处理装置，所述装置包括：

获取模块，用于当与服务端的通信网络故障时，获取缓存在本地的指令集合；所述指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到；

确定模块，用于确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；

处理模块，用于根据所述编号从所述指令集合中获取下一条指令进行处理。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述业务处理方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述业务处理方法的步骤。

上述业务处理方法、装置、计算机设备和存储介质，当与服务端的通信网络故障时，获取缓存在本地的指令集合；并确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；进而根据编号从指令集合中获取下一条指令进行处理。该方法由于指令集合是根据前一天在线作业失败率确定的拉取数量预先从服务端拉取指令得到，所以能够在不同的客户端上形成大小不同的指令集合。当在线作业失败率越高时，提前被拉取的指令数量就会越多，反之在线作业失败率越低时，提前被拉取的指令数量也就会越少。通过客户端的行为动态的调整被拉取的数量，从而能够有效的提高被拉取的数据的利用率，减少了资源浪费。

附图说明

图1为一个实施例中业务处理方法的应用环境图；

图2为一个实施例中业务处理方法的流程示意图；

图3为一个实施例中拉取数量的确定方法的流程示意图；

图4为一个实施例中业务处理装置的结构框图；

图5为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的业务处理方法，可以应用于如图1所示的应用环境中。其中，客户端102通过网络与服务端104通过网络进行通信。当客户端102与服务端104的通信网络故障时，客户端102获取缓存在本地的指令集合；指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端104拉取指令得到；客户端102确定当与服务端104的通信网络故障时，最后一条在线作业的指令的编号；客户端102根据编号从指令集合中获取下一条指令进行处理。其中，客户端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务端104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种业务处理方法，以该方法应用于图1中的客户端为例进行说明，包括以下步骤：

步骤S202，当与服务端的通信网络故障时，获取缓存在本地的指令集合；指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到。

其中，通信网络故障是包括但不限于由硬件问题、软件漏洞、病毒侵入等引起网络无法提供正常服务或降低服务质量的状态。指令集合是包括多条指令的集合。在线作业成功率是指客户端与服务端在通信网络未故障的情况下，作业成功的成功率。拉取数量是指需要拉取指令的数量。

具体地，客户端启动后，预先根据前一天在线作业失败率确定的拉取数量从服务端拉取指令组成指令集合缓存到本地。在客户端与服务端网络可用的情况下，客户端和服务端之间会优先使用在线作业模式进行业务处理。即，每次客户端都会先向服务端获取一条指令，然后根据该指令进行作业。而当客户端与服务端的通信网络故障时，由于网络故障所以客户端和服务端之间暂时是无法进行在线作业的。因此，为了保证正常的处理，客户端即从本地获取预先缓存的指令集合进行作业。应当理解的是，为了确保作业成功，拉取指令的同时客户端是会同步将处理该指令所需要的数据同步拉取过来缓存在本地的。

而根据前一天在线作业失败率确定的拉取数量去拉取等同数量的指令，当在线作业失败率越高时，提前被拉取的指令数量就会越高，反之在线作业失败率越低时，提前被拉取的指令数量也就会越低。通过客户端的行为动态的调整被拉取的数量，从而能够有效的提高被拉取的数据的利用率，减少了资源浪费。

步骤S204，确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号。

其中，编号是用于唯一标识区分各指令前后处理顺序的编号。由于待处理的指令通常都是根据生成请求时间的先后有固定的处理顺序。即，先生成指令的先处理，后生成的指令后处理。因此，为了确保指令原本的处理顺序，指令的编号优选按照指令的原始处理顺序进行编号。最后一条在线作业的指令是指网络故障时，最后一条进行在线作业模式处理的指令。例如，当客户端成功的从服务端请求到指令A后网络故障了，则指令A的编号即为最后一条在线作业的指令的编号。而若客户端处理完指令A对应的业务后，继续向服务端发出获取在线作业请求但还未成功请求到下一条指令时网络就故障了，此时最后一条在线作业请求的指令仍然是指令A。

具体地，由于为了确保指令的原始处理顺序，所以客户端和服务端作业时是会按照编号顺序有序的进行。因此，当确定客户端与服务端的通信网络故障之后，客户端即可获取最后一条在线作业的指令。因为最后一条在线作业的指令是在线作业模式中最后被处理过的指令。进而客户端根据指令携带的编号确定最后一条在线作业的指令的编号。

步骤S206，根据编号从指令集合中获取下一条指令进行处理。

其中，下一条指令是根据编号的顺序确定的下一次处理的指令，为了确保能够按照指令的原始顺序进行顺序处理，从指令集合中获取的下一条指令的编号应当是所有在当前编号之后的编号中与当前编号最接近的下一个编号。

在一个实施例中，步骤S206，包括：将编号作为匹配编号，从指令集合中确定编号位于匹配编号之后的指令；从编号位于匹配编号之后的指令中，获取编号与匹配编号最接近的指令作为下一条指令进行处理；将当前作为下一条指令的编号作为匹配编号，返回从指令集合中确定编号位于匹配编号之后的指令的步骤，直至指令集合中各指令均被处理完成。

其中，位于匹配编号之后的指令根据编号规则有所不同，当编号是从小到大表示指令先后处理顺序时，位于匹配编号之后的编号应当都比匹配编号大。而当编号是从小到大表示指令的先后处理顺序时，位于匹配编号之后的编号应当都比匹配编号小。

具体地，以最后一条在线作业的指令的编号为匹配编号。根据指令的编号，从指令集合中匹配在匹配编号之后的指令。例如，假设编号规则是按照时间先后进行从小到大的编号，则假设最后一条在线作业的指令的编号是2时，当指令集合中各指令的编号为1、2、3、5时，此时位于该匹配编号2之后指令包括编号3、5对应的指令，而与匹配编号2最接近的编号是编号3，则编号3对应的指令是下一条指令。同理，当指令集合中各指令的编号为1、2、5、8时，此时所获取的下一条指令应当时编号5对应的指令。而当指令接货中各指令的编号是5、8、10、11时，此时所获取的下一条指令应当时编号5对应的指令。

进而，当从本地的指令集合中获取到一条指令作为下一条指令并且处理完成之后，即可以用同样的方式从指令集合中继续获取下一条指令，直至指令集合中的指令均被处理过，从而实现在网络故障后通过离线模式继续处理。即，将作为下一条指令的指令对应的编号作为匹配编号。然后返回从指令集合中确定编号位于匹配编号之后的指令的步骤，直至指令集合中各指令均被处理完成。例如，第一次以匹配编号2从指令集合中获取到编号3对应的指令作为下一条指令，而后继续将编号3作为匹配编号再获取下一条指令。其中，被处理过的指令不仅包括离线作业处理过的指令，还包括在线作业请求处理过的指令。即最后一条在线作业的指令的编号是2时，若指令集合中包括编号1的指令，则编号1对应的指令也是被在线作业处理过的。

上述业务处理方法，当与服务端的通信网络故障时，获取缓存在本地的指令集合；并确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；进而根据编号从指令集合中获取下一条指令进行处理。该方法由于指令集合是根据前一天在线作业失败率确定的拉取数量预先从服务端拉取指令得到，所以能够在不同的客户端上形成大小不同的指令集合。当在线作业失败率越高时，提前被拉取的指令数量就会越多，反之在线作业失败率越低时，提前被拉取的指令数量也就会越少。通过客户端的行为动态的调整被拉取的数量，从而能够有效的提高被拉取的数据的利用率，减少了资源浪费。

在一个实施例中，如图3所示，拉取数量的确定方法，包括以下步骤：

步骤S302，统计前一天在线向服务端请求指令的请求总数量和请求成功数量。

其中，请求总数量是指客户端在线作业模式时向服务端请求指令的请求总数量，请求成功数量则是客户端向服务端发起的在线作业请求中被请求成功的数量。

具体地，客户端启动之后，初始化请求总数量和成功数量。例如，初始化请求总数量C2＝0，以及初始化成功数量C1＝0。而当客户端向在线向服务端发起一次作业请求时，C2递增1，C2＝C2+1。而如果客户端对该作业请求成功，则将C1递增1，C1＝C1+1。如果该作业请求失败，不进行额外的处理。

步骤S304，根据请求总数量和请求成功数量计算前一天的在线作业失败率。

其中，在线作业失败率用于表示在线作业模式失败的概率。

具体地，当统计到请求总数量和请求成功数量之后，根据请求总数量和请求成功数量能够计算得到在线作业成功率。进而，根据在线作业成功率就能得到在线作业失败率。

在一个实施例中，步骤S304包括：计算请求成功数量与请求总数量的比值，得到在线作业成功率；根据在线作业成功率确定在线作业失败率。

具体地，计算请求成功数量C1与请求总数量C2的比值S＝C1/C2，得到在线作业成功率S。根据在线作业成功率确定在线作业失败率，即在线作业失败率P＝1-S。

步骤S306，根据前一天的在线作业失败率确定当天的拉取数量。

其中，拉取数量是指需要从服务端预先拉取的请求指令的总数量。

具体地，获取服务端的总指令数量。根据总指令数量和前一天的在线作业失败率计算后一天的拉取数量。

在一个实施例中，步骤S306，包括：获取服务端的总指令数量；将在线作业失败率与总指令数量相乘，得到拉取数量。

其中，服务端的总指令数量根据实际需求可以进行配置，例如总指令数量C＝10000。

具体地，获取服务单的总指令数量，然后将在线作业失败率P与总指令数量C相乘得到拉取数量N。即，N＝C*P。

本实施例中，通过客户端和服务端的在线作业成功率确定在线作业失败率，进而根据在线作业失败率计算拉取数量，实现对客户端的在线行为的统计与分析，能够动态的根据客户端的在线行为动态调整拉取数量，从而提高利用率，减少资源消耗。

在一个实施例中，根据拉取数量，预先从服务端拉取指令得到指令集合，包括：根据服务端中各指令的编号，将第一个编号对应的指令作为拉取起点，最后一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

其中，第一个编号和最后一个编号是根据编号规则从编号中确定的排序在第一个的编号和排序在最后一个的编号。例如，当指令的编号是按照指令的生成时间顺序从先到后进行从小到大排序进行编号的，也就是越先处理的指令的编号越小，进行作业时也是按照编号从小到大进行。那么，第一个编号就是编号最小的编号，最后一个编号就是编号最大的编号。反之，按照时间先后从大到小排序进行编号，也就是越先处理的指令的编号越大，进行作业时是按照编号从小到大进行。那么，第一个编号就是编号最大的编号，最后一个编号就是编号最小的编号。

具体地，无论是哪一种编号规则，当根据拉取数量从服务端拉取指令时，客户端以第一个编号对应的指令作为拉取起点，最后一个编号对应的指令作为拉取终点。然后，从拉取起点开始往拉取终点从服务端进行拉取，得到与拉取数量相等的指令组成指令集合。例如，假设服务端的指令按照编号排序包括指令1、指令2、指令3、……、指令10。当在线作业失败率为30％时，即从指令1拉取到指令3，指令集合中包括指令1、指令2、指令3。

当客户端与服务端网络故障时，若在线作业请求结束在客户端请求指令3之前，假设是指令2，则在故障之后，客户端还能够从指令集合中获取指令3进行处理，从而确保被拉取到客户端的指令均被处理完成，从而能够尽可能达到拉取数据的百分百利用率，减少资源浪费。而若在线请求结束在客户端请求指令3之后，此时由于指令集合中的指令以及指令对应的数据在在线作业模式中都已经被利用过了，同样达到了百分百的利用率。

在另一个实施例中，根据拉取数量，预先从服务端拉取指令得到指令集合，包括：根据服务端中各指令的编号，将最后一个编号对应的指令作为拉取起点，第一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

具体地，由于无论是在线作业模式还是离线作业模式，被作业请求处理的指令是按照顺序进行的。也就是说，由于同一客户端和服务端前后两天出现差异较大的故障的概率较小。因此，当根据前一天的在线作业情况统计到前一天的在线作业失败率时，是能够根据前一天失败率得知客户端今天进行在线作业时大概率会失败的节点。进而以此节点去拉取数量，不仅能够保证被拉取数量的利用率还能确保在故障后通过离线尽可能的处理更多的指令。

所以，本实施例以最后一个编号对应的指令作为拉取起点，第一个编号对应的指令作为拉取终点进行拉取。即，假设服务端的指令按照编号排序包括指令1、指令2、指令3、……、指令10。当在线作业失败率为30％时，拉取是从指令10往前拉取到指令8，指令集合中包括指令8、指令9、指令10。因为前一天的失败率是30％，也就是前一天客户端在线作业是能够处理到指令7的。所以今天大概率也是能够在线作业处理到指令7的。因此，从指令7开始将可能在线作业请求失败的指令全部预先拉取到客户端缓存。当今天客户端处理在线请求到7失败时，即可以通过离线模式继续往指令7之后进行处理。而即使今天未在线作业请求到指令7，当通过编号获取下一条指令处理的时候也是能够从指令8开始进行处理的，从而不仅确保了拉取数据的利用率，还能够提高将10个指令全部处理完成的概率。

在一个实施例中，以客户端的在线作业过程对业务处理方法进行详细说明，包括以下步骤：

S1，客户端的应用程序app启动，获取前一天确定的拉取数量，根据前一天的拉取数量拉取今天的指令存储到本地，得到指令集合。同理，为了作业成功，可以同时拉取指令对应的数据存储在本地。其中，拉取指令可以从第一个指令往最后一个指令拉取，也可以最后一个指令往第一个指令拉取。

S2，客户端向服务端发起一次在线作业请求。

S3，将请求总数量C2增加1，C2＝C2+1。

S4，如果在线作业请求成功，则将C1增加1，C1＝C1+1。如果在线作业请求失败，不进行额外处理。

S5，重新计算客户端在线作业成功率：S＝C1/C2。

S6，重新计算客户端提前拉取服务端指令比例(即在线作业失败率)：P＝1-S。

S7，重新计算客户端提前拉取服务端指令数(即拉取数量)：N＝C*P

S8，不断重复S2～S7直到客户端的应用程序app退出。

S9，将最后计算得到的拉取数量作为明天拉取指令时的拉取数量。

应该理解的是，虽然图2-3的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-3中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图4所示，提供了一种业务处理装置，包括：获取模块402、确定模块404和处理模块406，其中：

获取模块402，用于当与服务端的通信网络故障时，获取缓存在本地的指令集合；指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到。

确定模块404，用于确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号。

处理模块406，用于根据编号从指令集合中获取下一条指令进行处理。

在一个实施例中，业务处理装置还包括统计模块，用于统计前一天在线向服务端请求指令的请求总数量和请求成功数量；根据请求总数量和请求成功数量计算前一天的在线作业失败率；根据前一天的在线作业失败率确定当天的拉取数量。

在一个实施例中，统计模块还用于计算请求成功数量与请求总数量的比值，得到在线作业成功率；根据在线作业成功率确定在线作业失败率。

在一个实施例中，统计模块还用于获取服务端的总指令数量；将在线作业失败率与总指令数量相乘，得到拉取数量。

在一个实施例中，业务处理装置还包括拉取模块，用于根据服务端中各指令的编号，将第一个编号对应的指令作为拉取起点，最后一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

在一个实施例中，拉取模块还用于根据服务端中各指令的编号，将最后一个编号对应的指令作为拉取起点，第一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

在一个实施例中，处理模块406还用于将编号作为匹配编号，从指令集合中确定编号位于匹配编号之后的指令；从编号位于匹配编号之后的指令中，获取编号与匹配编号最接近的指令作为下一条指令进行处理；将当前作为下一条指令的编号作为匹配编号，返回从指令集合中确定编号位于匹配编号之后的指令的步骤，直至指令集合中各指令均被处理完成。

关于业务处理装置的具体限定可以参见上文中对于业务处理方法的限定，在此不再赘述。上述业务处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种业务处理方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

当与服务端的通信网络故障时，获取缓存在本地的指令集合；指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到；

确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；

根据编号从指令集合中获取下一条指令进行处理。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：统计前一天在线向服务端请求指令的请求总数量和请求成功数量；根据请求总数量和请求成功数量计算前一天的在线作业失败率；根据前一天的在线作业失败率确定当天的拉取数量。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：计算请求成功数量与请求总数量的比值，得到在线作业成功率；根据在线作业成功率确定在线作业失败率。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：获取服务端的总指令数量；将在线作业失败率与总指令数量相乘，得到拉取数量。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据服务端中各指令的编号，将第一个编号对应的指令作为拉取起点，最后一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据服务端中各指令的编号，将最后一个编号对应的指令作为拉取起点，第一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：将编号作为匹配编号，从指令集合中确定编号位于匹配编号之后的指令；从编号位于匹配编号之后的指令中，获取编号与匹配编号最接近的指令作为下一条指令进行处理；将当前作为下一条指令的编号作为匹配编号，返回从指令集合中确定编号位于匹配编号之后的指令的步骤，直至指令集合中各指令均被处理完成。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

当与服务端的通信网络故障时，获取缓存在本地的指令集合；指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到；

确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；

根据编号从指令集合中获取下一条指令进行处理。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：统计前一天在线向服务端请求指令的请求总数量和请求成功数量；根据请求总数量和请求成功数量计算前一天的在线作业失败率；根据前一天的在线作业失败率确定当天的拉取数量。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：计算请求成功数量与请求总数量的比值，得到在线作业成功率；根据在线作业成功率确定在线作业失败率。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：获取服务端的总指令数量；将在线作业失败率与总指令数量相乘，得到拉取数量。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据服务端中各指令的编号，将第一个编号对应的指令作为拉取起点，最后一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据服务端中各指令的编号，将最后一个编号对应的指令作为拉取起点，第一个编号对应的指令作为拉取终点；从拉取起点开始往拉取终点进行拉取，得到与拉取数量相等的指令组成指令集合。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：将编号作为匹配编号，从指令集合中确定编号位于匹配编号之后的指令；从编号位于匹配编号之后的指令中，获取编号与匹配编号最接近的指令作为下一条指令进行处理；将当前作为下一条指令的编号作为匹配编号，返回从指令集合中确定编号位于匹配编号之后的指令的步骤，直至指令集合中各指令均被处理完成。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

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

当与服务端的通信网络故障时，获取缓存在本地的指令集合；所述指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到；

确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；

根据所述编号从所述指令集合中获取下一条指令进行处理。

2.根据权利要求1所述的方法，其特征在于，所述拉取数量的确定，包括：

统计前一天在线向服务端请求指令的请求总数量和请求成功数量；

根据所述请求总数量和所述请求成功数量计算前一天的在线作业失败率；

根据前一天的所述在线作业失败率确定当天的拉取数量。

3.根据权利要求2所述的方法，其特征在于，所述根据所述请求总数量和所述请求成功数量计算前一天的在线作业失败率，包括：

计算所述请求成功数量与所述请求总数量的比值，得到在线作业成功率；

根据所述在线作业成功率确定在线作业失败率。

4.根据权利要求2所述的方法，其特征在于，所述根据前一天的所述在线作业失败率确定当天的拉取数量，包括：

获取服务端的总指令数量；

将所述在线作业失败率与所述总指令数量相乘，得到拉取数量。

5.根据权利要求1所述的方法，其特征在于，根据拉取所述数量，预先从服务端拉取指令得到指令集合，包括：

根据服务端中各指令的编号，将第一个编号对应的指令作为拉取起点，最后一个编号对应的指令作为拉取终点；

从所述拉取起点开始往所述拉取终点进行拉取，得到与所述拉取数量相等的指令组成指令集合。

6.根据权利要求1所述的方法，其特征在于，根据拉取数量，预先从服务端拉取指令得到指令集合，包括：

根据服务端中各指令的编号，将最后一个编号对应的指令作为拉取起点，第一个编号对应的指令作为拉取终点；

从所述拉取起点开始往所述拉取终点进行拉取，得到与所述拉取数量相等的指令组成指令集合。

7.根据权利要求1所述的方法，其特征在于，所述根据所述编号从所述指令集合中获取下一条指令进行处理，包括：

将所述编号作为匹配编号，从所述指令集合中确定编号位于所述匹配编号之后的指令；

从编号位于所述匹配编号之后的指令中，获取编号与所述匹配编号最接近的指令作为下一条指令进行处理；

将当前作为下一条指令的编号作为匹配编号，返回从所述指令集合中确定编号位于所述匹配编号之后的指令的步骤，直至所述指令集合中各指令均被处理完成。

8.一种业务处理装置，其特征在于，所述装置包括：

获取模块，用于当与服务端的通信网络故障时，获取缓存在本地的指令集合；所述指令集合根据前一天在线作业失败率确定的拉取数量，预先从服务端拉取指令得到；

确定模块，用于确定当与服务端的通信网络故障时，最后一条在线作业的指令的编号；

处理模块，用于根据所述编号从所述指令集合中获取下一条指令进行处理。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述的方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images