服务订单的处理方法、装置、设备、介质及程序产品

技术领域

本申请涉及计算机技术领域，尤其涉及一种服务订单的处理方法、装置、设备、介质及程序产品。

背景技术

随着互联网的高速发展，居民可以通过互联网发送服务订单，为居民提供服务的用户通过互联网获取服务订单进行处理，从而满足居民需求。然而，当多名用户都可以对同一服务订单进行处理时，例如，当多名互联网医生处于同一门诊单对应的科室，都可以对该门诊单进行处理时；或处于同一派送区域的多名外卖员，都可以对同一订餐单进行处理时，如何获取服务订单是关键。

目前，获取服务订单的方式主要通过服务器将居民发送的服务订单存放在数据存储设备中，当并发量要求较高时，还可以提前将服务订单加载进入缓存。当接收到用户的查询请求时，从数据存储设备或缓存中获取该用户可以处理的服务订单，并显示在服务订单列表中，方便用户对服务订单进行选择。用户从服务订单列表中选择自己想要处理的服务订单，并进一步对选取的服务订单进行处理。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：在获取服务订单的过程中，由于数据存储设备和缓存中的头部订单容易被用户并发争抢，导致排在后部的服务订单无人问津，使得服务订单的处理时间较长，处理效率较低。

发明内容

本申请提供一种服务订单的处理方法、装置、设备、介质及程序产品，以解决在获取服务订单的过程中，由于数据存储设备和缓存中的头部订单容易被用户并发争抢，导致排在后部的订单无人问津，使得服务订单的处理时间较长，处理效率较低的问题。

第一方面，本申请实施例提供一种服务订单的处理方法，包括：

接收用户的终端设备发送的查询请求，所述查询请求包括用户信息以及页码参数，所述页码参数用于确定服务订单列表的页码；

根据所述用户信息，从活跃度列表中获取所述用户对应的抢单活跃度，所述活跃度列表中包括多个用户对应的抢单活跃度；

根据所述抢单活跃度，所述页码参数以及订单池总数量，获取第一订单池编号，并从所述第一订单池编号对应的第一订单池中获取待处理的服务订单，每个订单池中存储的服务订单不同；

根据所述待处理的服务订单生成所述服务订单列表；

将所述服务订单列表返回所述用户的终端设备。

在第一方面的一种可能设计中，所述根据待处理的服务订单生成所述服务订单列表之前，所述方法还包括：

若获取的服务订单的数量小于所述服务订单列表可显示的订单数量，且递归次数未超过所述订单池总数量，则根据所述第一订单池编号，所述递归次数以及所述订单池总数量，计算第二订单池编号，并从所述第二订单池编号对应的第二订单池中继续获取待处理的服务订单，重复本步骤，直至获取到的待处理的服务订单数量达到所述服务订单列表可显示的订单数量，所述递归次数用于表示已获取服务订单的订单池的数量。

在第一方面的另一种可能设计中，所述活跃度列表中的多个用户的抢单活跃度按照从大到小的顺序排列，则所述根据所述用户信息，从活跃度列表中获取所述用户对应的抢单活跃度，包括：

根据所述用户信息，查询所述用户信息在所述活跃度列表中的排列位置；

根据所述排列位置，确定所述用户对应的抢单活跃度。

可选的，所述方法还包括：

将所述用户对应的抢单活跃度更新至所述活跃度列表的第一位。

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

接收所述用户的所述终端设备发送的刷新请求，所述刷新请求用于指示重新获取服务订单列表；

根据所述刷新请求，对所述查询请求中的页码参数进行更新，得到新的页码参数；

根据所述抢单活跃度，所述新的页码参数以及所述订单池总数量，获取第三订单池编号，并从所述第三订单池编号对应的第三订单池中获取新的待处理的服务订单；

根据所述新的待处理的服务订单生成新的服务订单列表；

将所述新的服务订单列表返回所述用户的终端设备。

在第一方面的又一种可能设计中，所述接收用户的终端设备发送的查询请求之前，所述方法还包括：

对多个订单池进行编号；

根据每个订单池的编号，将获取到的服务订单分别存储至所述多个订单池。

可选的，所述根据每个订单池的编号，将获取到的服务订单分别存储至所述多个订单池，包括：

根据每个订单池的剩余容量，按照订单池编号的顺序，依次将获取到的服务订单存储至订单池，每个订单池的剩余容量用于表示所述订单池中还可以存储的订单数量。

可选的，所述方法还包括：

若未获取到新的服务订单，则根据每个订单池的剩余容量，将所述订单池编号在后的订单池中的订单转存至订单池编号在前的订单池中。

第二方面，本申请实施例提供一种服务订单的处理装置，包括：

接收模块，用于接收用户的终端设备发送的查询请求，所述查询请求包括用户信息以及页码参数，所述页码参数用于确定服务订单列表的页码；

处理模块，用于根据所述用户信息，从活跃度列表中获取所述用户对应的抢单活跃度，所述活跃度列表中包括多个用户对应的抢单活跃度；

所述处理模块，还用于根据所述抢单活跃度，所述页码参数以及订单池总数量，获取第一订单池编号，并从所述第一订单池编号对应的第一订单池中获取待处理的服务订单，每个订单池中存储的服务订单不同；

所述处理模块，还用于根据所述待处理的服务订单生成所述服务订单列表；

发送模块，用于将所述服务订单列表返回所述用户的终端设备。

在第二方面的一种可能设计中，所述处理模块，还用于若获取的服务订单的数量小于所述服务订单列表可显示的订单数量，且递归次数未超过所述订单池总数量，则根据所述第一订单池编号，所述递归次数以及所述订单池总数量，计算第二订单池编号，并从所述第二订单池编号对应的第二订单池中继续获取待处理的服务订单，重复本步骤，直至获取到的待处理的服务订单数量达到所述服务订单列表可显示的订单数量，所述递归次数用于表示已获取服务订单的订单池的数量。

在第二方面的另一种可能设计中，所述活跃度列表中的多个用户的抢单活跃度按照从大到小的顺序排列，所述处理模块，具体用于：

根据所述用户信息，查询所述用户信息在所述活跃度列表中的排列位置；

根据所述排列位置，确定所述用户对应的抢单活跃度。

可选的，所述处理模块，还用于：

将所述用户对应的抢单活跃度更新至所述活跃度列表的第一位。

在第二方面的再一种可能设计中，所述接收模块，还用于接收所述用户的所述终端设备发送的刷新请求，所述刷新请求用于指示重新获取服务订单列表；

所述处理模块，还用于根据所述刷新请求，对所述查询请求中的页码参数进行更新，得到新的页码参数；

所述处理模块，还用于根据所述抢单活跃度，所述新的页码参数以及所述订单池总数量，获取第三订单池编号，并从所述第三订单池编号对应的第三订单池中获取新的待处理的服务订单；

所述处理模块，还用于根据所述新的待处理的服务订单生成新的服务订单列表；

所述发送模块，还用于将所述新的服务订单列表返回所述用户的终端设备。

在第二方面的又一种可能设计中，所述处理模块，还用于：

对多个订单池进行编号；

根据每个订单池的编号，将获取到的服务订单分别存储至所述多个订单池。

可选的，所述处理模块，具体用于：

根据每个订单池的剩余容量，按照订单池编号的顺序，依次将获取到的服务订单存储至订单池，每个订单池的剩余容量用于表示所述订单池中还可以存储的订单数量。

可选的，所述处理模块，还用于：

若未获取到新的服务订单，则根据每个订单池的剩余容量，将所述订单池编号在后的订单池中的订单转存至订单池编号在前的订单池中。

第三方面，本申请实施例提供一种服务器，包括：处理器、收发器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序指令，所述处理器执行所述计算机程序指令时用于实现第一方面以及各可能设计提供的方法。

第四方面，本申请实施例可提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现第一方面以及各可能设计提供的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时用于实现第一方面以及各可能设计提供的方法。

本申请实施例提供的服务订单的处理方法，服务器接收用户的终端设备发送的查询请求，其中，查询请求包括用户信息以及页码参数，页码参数用于确定服务订单列表的页码。之后服务器根据用户信息，从活跃度列表中获取用户对应的抢单活跃度，并根据抢单活跃度，页码参数以及订单池总数量，获取第一订单池编号，并从第一订单池编号对应的第一订单池中获取待处理的服务订单。最后，服务器根据待处理的服务订单生成服务订单列表，并将服务订单列表返回用户的终端设备。其中，活跃度列表中包括多个用户对应的抢单活跃度，每个订单池中存储的服务订单不同。服务器通过根据抢单活跃度，页码参数以及订单池总数量，从获取的第一订单池编号对应的第一订单池中获取待处理的服务订单，使得服务器能够从数据存储设备中的不同部位获取服务订单，为使用终端设备的用户提供差异性的服务订单列表，减少服务订单的处理时间，提高处理效率。

附图说明

图1A为本申请实施例提供的服务订单的处理方法的一种应用场景示意图；

图1B为本申请实施例提供的服务订单的处理方法的一种原理示意图；

图2为本申请实施例提供的服务订单的处理方法实施例一的流程示意图；

图3为本申请实施例一提供的活跃度列表示意图；

图4为本申请实施例提供的服务订单的处理方法实施例二的流程示意图；

图5为本申请实施例提供的服务订单的处理方法实施例三的流程示意图；

图6为本申请实施例提供的服务订单的处理方法实施例四的流程示意图；

图7为本申请实施例提供的服务订单的处理方法实施例五的流程示意图；

图8为本申请实施例提供的服务订单的处理装置实施例的结构示意图；

图9为本申请实施例提供的服务器的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

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

在介绍本申请的实施例之前，首先对本申请实施例的应用场景进行解释：

随着互联网的高速发展，居民足不出户就可以满足自身的需求。居民可以根据自身的需求通过互联网发送服务订单，为居民提供服务的用户可以通过互联网获取服务订单进行处理，从而满足居民需求。

以互联网医院为例进行举例说明，居民在身体不适的情况下，可以根据不适的部位向互联网医院中相应的门诊室发送服务订单，也就是问诊单。门诊室中的医生选取自己能够处理的问诊单，根据问诊单的内容与居民进行沟通，并做进一步处理。然而，由于同一门诊室中的多个医生可以对同一问诊单进行处理，那么，每个医生如何获取问诊单是关键。

目前，每个医生获取问诊单的方式主要通过服务器将获取的问诊单存放在数据存储设备中，当并发量要求较高时，为了提高医生获取问诊单的速度，还可以提前将问诊单加载进入缓存。在医生想要获取问诊单的时候，需要向服务器发送查询请求，服务器接收到该查询请求后，根据该查询请求获取数据存储设备或缓存中该医生能处理的排在前面的头部订单，并显示在服务订单列表中，方便医生对问诊单进行选择。医生对从服务订单列表中选择自己想要处理的问诊单，并进一步对选取的问诊单进行处理。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：在获取服务订单的过程中，由于数据存储设备和缓存中的头部订单容易被用户并发争抢，导致排在后部的服务订单无人问津，使得服务订单的处理时间较长，处理效率较低。且服务器需要每次拉取数据存储设备或缓存中该医生能处理的所有服务订单，服务订单数量较多时，服务订单的数据包体积较大，导致服务器的输入/输出(Input Output，IO)压力较大。

针对上述问题，本申请的发明构思如下：在目前的方案中，由于医生根据服务订单列表选取的问诊单是数据存储设备或缓存中的头部订单，因此头部订单能够优先获取处理，导致排在后部的服务订单需要等待较长的时间才能得到处理，处理时间较长，处理效率较低。基于此，发明人发现，如果服务器能够从数据存储设备或缓存中的不同位置开始获取服务订单，那么医生每次就可以处理数据存储设备或缓存中的不同位置的服务订单，就能够解决现有技术中排在数据存储设备或缓存后部的服务订单需要等待较长的时间才能得到处理的问题，减少了处理时间，从而提高处理效率。

示例性的，本申请实施例提供的服务订单的处理方法可以应用于图1A所示的一种应用场景示意图中。图1A为本申请实施例提供的服务订单的处理方法的一种应用场景示意图，用以解决上述技术问题。如图1A所示，该应用场景可以包括：至少一个终端设备(图1A示出了两个终端设备，分别为终端设备A、终端设备B)和服务器，其中，每个终端设备与服务器均可以通过网络进行通信。可选的，图1所示的应用场景还可以包括与服务器连接的数据存储设备，该数据存储设备中设置有多个订单池，以X个订单池为例进行举例说明，分别为订单池A、订单池B、订单池C……订单池X。

示例性的，在图1A所示的应用场景中，服务器可以通过网络获取终端设备A发送的服务订单，并将服务订单储存在数据存储设备中。服务器还可以通过网络获取终端设备B发送的查询请求，根据该查询请求对储存的服务订单进行处理，从订单池中获取服务订单，生成服务订单列表，并将该服务订单列表返回至终端设备B，便于用户选取服务订单列表中的服务订单。使用终端设备B的用户根据服务器发送的服务订单列表，选取服务订单列表中的服务订单，并与该服务订单对应的使用终端设备A的居民进行沟通，并针对服务订单进行进一步处理。

若用户无法从终端设备B的服务订单列表中获取合适的服务订单，用户还可以向服务器发送刷新请求，服务器接收终端设备B发送的刷新请求，重新为终端设备B获取新的服务订单列表，并将新的服务订单列表返回到终端设备B中。

需要说明的是，图1A仅是本申请实施例提供的一种应用场景的示意图，本申请实施例不对图1A中包括的设备进行限定，也不对图1A中设备之间的位置关系进行限定，例如，在图1A中，数据存储设备相对服务器可以是外部存储器，在其它情况下，也可以将数据存储设备放置于服务器中。

示例性的，在上述应用场景的基础上，图1B为本申请实施例提供的服务订单的处理方法的一种原理示意图。如图1B所示，服务器可以包括定时模块11、接收模块12、活跃度获取模块13、计算模块14、订单池控制模块15。

其中，定时模块11用于按照一定频率将服务订单存储到多个订单池中。

接收模块12主要用于接收用户的终端设备发送的查询请求，并获取请求中携带的用户信息以及页码参数。

活跃度获取模块13主要用于根据用户信息从活跃度列表中获取该用户对应的抢单活跃度。

计算模块14主要用于获取接收模块12接收的查询请求中的页码参数，活跃度获取模块13获取的抢单活跃度，以及订单池总数量，获取第一订单池编号。

其中，若订单池控制模块15获取的服务订单的数量小于服务订单列表可显示的订单数量，且递归次数未超过订单池总数量，计算模块14还用于根据第一订单池编号，递归次数以及订单池总数量，计算第二订单池编号。重复计算，直至订单池控制模块15获取到的待处理的服务订单数量达到服务订单列表可显示的订单数量。

订单池控制模块15用于根据第一订单池编号获取其对应的第一订单池中获取待处理的服务订单。

订单池控制模块15还用于根据第二订单池编号获取其对应的第二订单池中获取待处理的服务订单，重复获取，直到计算模块14不再计算新的订单池编号。

下面，通过具体实施例对本申请的技术方案进行详细说明。

需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请实施例提供的服务订单的处理方法实施例一的流程示意图。如图2所示，该服务订单的处理方法可以包括如下步骤：

S101：接收用户的终端设备发送的查询请求。

在本步骤中，为了给使用终端设备的用户提供服务订单列表，便于用户从中选取待处理的服务订单，服务器首先需要接受用户通过终端设备发送的查询请求。

其中，查询请求包括用户信息以及页码参数。

示例性的，用户信息可以是用户id，也可以是现有技术中其他用来标注用户身份的信息，可以根据实际情况进行设定，本方案对此不进行限定。

示例性的，页码参数用于确定服务订单列表的页码，举例来说，该页码参数可以为1，2，3，4等，也可以为其他正整数，可以根据实际情况进行设定，本方案对此不进行限定。

示例性的，对于互联网医院问诊的应用场景中，用户信息可以为该互联网医院中每个医生的姓名，如：医生A，医生B，医生C等，也可以是每个医生对应的工号。

S102：根据用户信息，从活跃度列表中获取用户对应的抢单活跃度。

在本步骤中，服务器获取到查询请求后，需要根据该查询请求中携带的用户信息，从活跃度列表中获取该用户对应的抢单活跃度，以便于后续根据该用户的抢单活跃度，获取待处理的服务订单。

示例性的，服务器可以通过远程字典服务(Remote dictionary server，Redis)的有序集合(sorted set，zset)方案获取活跃度列表，也可以通过现有技术中的其他方式获取活跃度列表，可以根据实际情况进行选取，本方案对此不进行限定。

其中，活跃度列表中包括多个用户对应的抢单活跃度，且活跃度列表中的多个用户的抢单活跃度按照从大到小的顺序排列。

应理解的是，活跃度列表中的所有用户都可以对每个订单池的中所有服务订单进行处理。

可选的，活跃度列表中排列位置与抢单活跃度存在映射关系，如排在活跃度列表第一位的用户的抢单活跃度为1，排在活跃度列表第二位的用户的抢单活跃度为2，以此类推，应理解，活跃度列表中排列位置与抢单活跃度之间还可以存在其他形式的映射关系，本方案对此不进行具体限制。

在一种具体的实现方式中，服务器根据查询请求中携带的用户信息，查询该用户信息在活跃度列表中的排列位置，并根据该排列位置，通过排列位置与抢单活跃度的映射关系确定该用户对应的抢单活跃度。

示例性的，对于互联网医院问诊的应用场景中，图3为本申请实施例一提供的活跃度列表示意图。如图3所示，该活跃度列表中包括多名用户信息，如医生A，医生B，其中，抢单活跃度越大的医生在活跃度列表中的位置越靠前，如医生A的抢单活跃度大于医生B，则医生A在活跃度列表中排在医生B的前面。

示例性的，如查询请求中用户信息为医生A，则服务器需要获取医生A的抢单活跃度。服务器首先需要获取医生A在活跃度列表中的位置，如图3所示，医生A在活跃度列表中的第一位，之后根据活跃度列表中排列位置与抢单活跃度之间的映射关系，获取医生A的抢单活跃度，也就是医生A的活跃度为1。

S103：根据抢单活跃度，页码参数以及订单池总数量，获取第一订单池编号，并从第一订单池编号对应的第一订单池中获取待处理的服务订单。

在本步骤中，为了解决现有技术中排在后部的服务订单需要等待较长的时间才能得到处理的问题，可以预先将待处理的服务订单存储至不同的订单池中，并根据抢单活跃度，页码参数以及订单池总数量确定获取服务订单的订单池，在该订单池中获取待处理的服务订单。

其中，订单池用于存储待处理的服务订单，每个订单池中存储的服务订单不同，且每个订单池标有对应的编号。

示例性的，订单池的编号可以为1，2，3，4等形式，还可以存在其他编号形式，可以根据实际情况进行设定，本方案实施例对此不进行具体限制。

在一种具体的实施方式中，服务器可以根据抢单活跃度，页码参数以及订单池总数量，通过代码(index+A-1)％count获取第一订单池编号。其中，index为该用户的抢单活跃度，A为页码参数，count为订单池总数量。服务器获取第一订单池编号后，从该第一订单池编号对应的第一订单池中获取待处理的服务订单，该待处理的服务订单的数量不超过服务订单列表可显示的订单数量。

进一步的，若获取的服务订单的数量小于服务订单列表可显示的订单数量，且递归次数未超过订单池总数量，则根据第一订单池编号，递归次数以及订单池总数量，通过代码(startindex+step)％count计算第二订单池编号。其中，startindex为第一订单池编号，step为递归次数。接下来从第二订单池编号对应的第二订单池中继续获取待处理的服务订单，重复本步骤，直至获取到的待处理的服务订单数量达到服务订单列表可显示的订单数量。

其中，递归次数用于表示已获取服务订单的订单池的数量，当递归次数超过订单池总数量时，若继续重复上述步骤则会从已获取服务订单的订单池中再次获取服务订单，容易重复获取服务订单。

S104：根据待处理的服务订单生成服务订单列表。

在本步骤中，服务器获取待处理的服务订单后，可以将该待处理的服务订单生成服务订单列表，以便于后续用户进行查看。

可选的，可以将该待处理的服务订单按照一定预设的顺序进行排列，将排列好的待处理的服务订单生成服务订单列表。

示例性的，预设的顺序可以是服务器接收服务订单的时间排序，也可以是发送服务订单的居民姓名的首字母顺序，还可以是其他的顺序，可以根据实际需求进行预先设定，本方案对此不进行具体限定。

可选的，服务订单列表中可以包括发送服务订单的居民姓名，订单详情，发送服务订单的时间，还可以包括其他服务订单的详细信息，本申请对此不进行具体设置。

示例性的，对于互联网医院问诊的应用场景中，服务订单列表中可以包括发送问诊单的居民姓名，针对不适部分的详细描述，发送问诊单的时间等。

进一步的，服务器还需要将用户对应的抢单活跃度更新至活跃度列表的第一位。

在一种具体的实施方式中，对于互联网医院问诊的应用场景中，服务器生成服务订单列表后，将异步触发一次活跃度列表，将该医生放入活跃度列表的排头，代表医生刚刚活跃，也就是说将该医生对应的抢单活跃度更新至活跃度列表的第一位。

S105：将服务订单列表返回用户的终端设备。

在本步骤中，服务器可以通过浏览器或客户端将生成的服务订单列表返回该用户的终端设备。

可选的，该服务订单列表可以在终端设备中的图形用户界面中进行显示，以便于用户通过该图形用户界面选取想要处理的服务订单。

本申请实施例提供的服务订单的处理方法，服务器接收用户的终端设备发送的查询请求，其中，查询请求包括用户信息以及页码参数，页码参数用于确定服务订单列表的页码。之后服务器根据用户信息，从活跃度列表中获取用户对应的抢单活跃度，并根据抢单活跃度，页码参数以及订单池总数量，获取第一订单池编号，并从第一订单池编号对应的第一订单池中获取待处理的服务订单。最后，服务器根据待处理的服务订单生成服务订单列表，并将服务订单列表返回用户的终端设备。其中，活跃度列表中包括多个用户对应的抢单活跃度，每个订单池中存储的服务订单不同。服务器通过根据抢单活跃度，页码参数以及订单池总数量，从获取的第一订单池编号对应的第一订单池中获取待处理的服务订单，使得服务器能够从数据存储设备中的不同部位获取服务订单，为使用终端设备的用户提供差异性的服务订单列表，减少服务订单的处理时间，提高处理效率。

此外，在本申请的实施例中，与在现有技术中增加乱序模块，利用乱序模块打乱数据存储设备中服务订单的顺序相比，服务器只需要拉取订单池中服务订单，由于每个订单池中的服务订单的数据包的体积较小，能够有效减小服务器的IO压力。

示例性的，在上述实施例的基础上，图4为本申请实施例提供的服务订单的处理方法实施例二的流程示意图。如图4所示，在本实施例中，该服务订单的处理方法还可以包括以下步骤：

第1步、接收用户的终端设备发送的查询请求，查询请求包括用户信息以及页码参数；

第2步、根据该用户信息，获取用户的抢单活跃度；

第3步、获取订单池总数量；

第4步、根据抢单活跃度，页码参数以及订单池总数量，获取第一订单池编号，并从第一订单池编号对应的第一订单池中获取待处理的服务订单；

第5步、判断获取的服务订单的数量是否等于服务订单列表可显示的订单数量，若是，则跳转至第9步，若否，则将递归次数设置为2，跳转至第6步；

第6步、根据第一订单池编号，递归次数以及订单池总数量，计算新的订单池编号，并从新的订单池编号对应的订单池中继续获取待处理的服务订单；

第7步、判断获取的服务订单的总数量是否等于服务订单列表可显示的订单数量，若是，则跳转至第9步，若否，跳转至第8步；

第8步、判断递归次数是否超过订单池总数量，若是，则跳转至第9步，若否，则将递归次数加1，并跳转至第6步；

第9步、将获取的待处理的服务订单生成服务订单列表；

第10步、异步触发活跃度列表；

第11步、将服务订单列表返回用户的终端设备。

示例性的，在上述实施例的基础上，图5为本申请实施例提供的服务订单的处理方法实施例三的流程示意图。如图5所示，在本实施例中，S103还可以包括以下步骤：

第1步，根据抢单活跃度，页码参数以及订单池总数量，获取第一订单池编号。

示例性的，本申请实施例以互联网医院问诊的应用场景为例进行举例说明。如图5所示，在该应用场景下，订单池总数量为4个，订单池的编号分别为1，2，3，4，每个订单池最多可以储存10单服务订单，服务订单列表可显示的订单数量为10单。具体的，订单池的编号为1，2，3，4的订单池中的订单数量分别为10，10，5，0。其中，该用户信息为医生X，

其中，服务器根据活跃度列表获取该医生的抢单活跃度，该医生的活跃度为3。

在本步骤中，通过代码(index+A-1)％count获取第一订单池编号，该第一订单池编号为3。

第2步，从第一订单池编号对应的第一订单池中获取待处理的服务订单。

在本步骤中，从订单池编号为3的订单池中，获取待处理的服务订单，本步骤中获取的服务订单的数量为5单，由于服务器获取的服务订单的数量小于服务订单列表可显示的订单数量，且递归次数未超过订单池总数量，则需要继续获取待处理的服务订单。

第3步，根据第一订单池编号，递归次数以及订单池总数量，计算第二订单池编号，从第二订单池编号对应的第二订单池中获取待处理的服务订单。

在本步骤中，递归次数为2，通过代码(startindex+step)％count计算第二订单池编号。通过计算获取第二订单池编号为4，从订单池编号为4的订单池中，获取待处理的服务订单，本步骤中获取的服务订单的数量为0单，由于服务器获取的服务订单的总数量为5单，小于服务订单列表可显示的订单数量(10单)，且递归次数未超过订单池总数量，则需要继续获取待处理的服务订单。

第4步，根据第二订单池编号，递归次数以及订单池总数量，计算新的订单池编号，从新的订单池编号对应的新的订单池中获取待处理的服务订单，生成服务订单列表，并将用户对应的抢单活跃度更新至活跃度列表的第一位。

在本步骤中，递归次数为3，通过代码(startindex+step)％count计算新的订单池编号。通过计算获取新的订单池编号为1，从订单池编号为1的订单池中，获取待处理的服务订单，本步骤中获取的服务订单的数量为5单。此时，服务器获取的服务订单的总数量为10单，等于服务订单列表可显示的订单数量，停止获取待处理的服务订单。

进一步的，服务器还需要将获取的待处理的服务订单生成服务订单列表，并将医生X对应的抢单活跃度更新至活跃度列表的第一位。

本申请实施例提供的服务订单的处理方法，服务器根据抢单活跃度，页码参数以及订单池总数量，获取第一订单池编号，并从第一订单池编号对应的第一订单池中获取待处理的服务订单。之后，根据第一订单池编号，递归次数以及订单池总数量，计算第二订单池编号。最后，根据第二订单池编号，递归次数以及订单池总数量，计算新的订单池编号，并将用户对应的抢单活跃度更新至活跃度列表的第一位。由此可以看出，服务器可以根据用户的抢单活跃度生成服务订单列表，当用户的抢单活跃度不同时，生成的服务订单列表也不同。可以达到将问诊单在一定程度上在医生间散开，避免头部问诊单被集中抢夺，后部问诊单无人刷到的情况，有效提高问诊单的处理效率。

示例性的，在上述实施例的基础上，图6为本申请实施例提供的服务订单的处理方法实施例四的流程示意图。如图6所示，在本实施例中，该服务订单的处理方法还可以包括以下步骤：

S201：接收用户的终端设备发送的刷新请求。

在本步骤中，在上述实施例的基础上，若服务器向终端设备返回的服务订单列表中，没有用户需要的服务订单，则服务器还可以接收用户的终端设备发送的刷新请求，根据该刷新请求重新获取新的服务订单列表。

在一种具体的实施方式中，用户的终端设备通过响应用户点击图形用户界面中的翻页控件的操作，生成刷新请求，发送给服务器。服务器接收终端设备发送的刷新请求，以便于后续根据该刷新指令重新获取服务订单列表。

应理解，终端设备根据翻页控件生成的刷新请求用于指示重新获取服务订单列表，即换一批待处理的服务订单，生成新的服务订单列表，而非现有技术中用于指示显示下一页内容。

S202：根据刷新请求，对查询请求中的页码参数进行更新，得到新的页码参数。

在本步骤中，服务器根据获取的刷新请求，将之前的查询请求中的页码参数进行更新，得到新的页码参数，以便于重新获取新的待处理的服务订单。

可选的，可以将页码参数加1，还可以将页码参数进行随机更改，使新的页码参数与之前的页码参数不同，还可以通过其他的方式对页码参数进行更新，从而获取新的页码参数，可以根据实际情况进行选择，本申请实施例对此不进行具体限制。

S203：根据抢单活跃度，新的页码参数以及订单池总数量，获取第三订单池编号，并从第三订单池编号对应的第三订单池中获取新的待处理的服务订单。

在本步骤中，步骤S203的技术名词、技术效果、技术特征，以及可选实施方式，可参照步骤S103理解，对于重复的内容，在此不再累述。

S204：根据新的待处理的服务订单生成新的服务订单列表。

在本步骤中，步骤S204的技术名词、技术效果、技术特征，以及可选实施方式，可参照步骤104理解，对于重复的内容，在此不再累述。

S205：将新的服务订单列表返回用户的终端设备。

在本步骤中，步骤S205的技术名词、技术效果、技术特征，以及可选实施方式，可参照步骤S105理解，对于重复的内容，在此不再累述。

本申请实施例提供的服务订单的处理方法，服务器接收用户的终端设备发送的刷新请求，根据该刷新请求，对查询请求中的页码参数进行更新，得到新的页码参数。之后，服务器根据抢单活跃度，新的页码参数以及订单池总数量，获取第三订单池编号，并从第三订单池编号对应的第三订单池中获取新的待处理的服务订单。最后，服务器根据新的待处理的服务订单生成新的服务订单列表，并将新的服务订单列表返回用户的终端设备。其中，刷新请求用于指示重新获取服务订单列表。服务器根据刷新请求，重新获取新的服务订单列表，为用户处理服务订单提供了更大的便利，进一步为用户选择服务订单提供了更多的选择性。

示例性的，在上述实施例的基础上，图7为本申请实施例提供的服务订单的处理方法实施例五的流程示意图。如图7所示，在本实施例中，上述S101之前，还可以包括以下步骤：

S301：对多个订单池进行编号。

在本步骤中，为了方便后续根据订单池的编号获取待处理的服务订单，服务器首先需要对多个订单池进行编号。

其中，可以通过现有技术中的编号方式对多个订单池进行编号，订单池的编号可以为1，2，3，4等，也可以为其他的数字编号，对多个订单池进行编号的方式以及订单池的编号可以根据实际需求进行设定，本方案对此不进行具体限制。

S302：根据每个订单池的编号，将获取到的服务订单分别存储至多个订单池。

在本步骤中，服务器获取居民通过终端设备发送的服务订单后，为了方便后续从订单池中获取待处理的服务订单，服务器需要将服务订单储存至多个订单池。

可选的，以互联网医院问诊的应用场景为例进行举例说明，服务器可以将获取的服务订单(也就是针对同一科室的问诊单)存储在科室订单池中，以便于后续将存储在科室订单池中的订单存储到多个订单池。

其中，服务器可以利用预先设定的频率，在该频率对应的时间将获取到的服务订单分别存储至多个订单池。

其中，可以通过填充池预先设定向订单池中存储服务订单的频率。

其中，从第一个订单池开始进行存储服务订单，直到最后一个订单池结束，这个过程为一次存储过程。

在一种具体的实施方式中，服务器根据每个订单池的剩余容量，按照订单池编号的顺序，依次将获取到的服务订单存储至订单池。服务器可以将获取的服务订单按照订单池编号由小到大的顺序，将获取到的服务订单存储至订单池中，使得订单池中的订单数量达到订单池中的最多可以储存的服务订单数量，使该订单池的剩余容量为0。

其中，每个订单池的剩余容量用于表示订单池中还可以存储的订单数量。

进一步的，若服务器未获取到新的服务订单，则根据每个订单池的剩余容量，将订单池编号在后的订单池中的订单转存至订单池编号在前的订单池中。当订单池编号最小的订单池中存在剩余容量，则将订单池编号最大的订单池中的服务订单转存在订单池编号在前的订单池中。

示例性的，以共有4个订单池为例进行举例说明。此时，订单池最多可以储存的服务订单数量为10单，订单池的编号分别1，2，3，4的订单池中的服务订单数量分别为10单，7单，5单，0单，服务器共获取居民发送的2单服务订单。

服务器首先查看编号为1的订单池的剩余容量，该剩余容量为1单，则将1单服务订单存储在编号为1的订单池中。订单池的编号为1的订单池达到10单，服务器获取编号为2的订单池的剩余容量，该剩余容量为3单，由于服务器此时只剩余1单服务订单，因此服务器将1单服务订单存储至编号为2的订单池中，此时编号为2的订单池的剩余容量为1单。

进一步的，由于此时服务器未获取到新的服务订单，因此服务器查看编号为4的订单池中的订单数量。由于号为4的订单池中没有服务订单，则服务器继续查看编号为3的订单池中的订单数量，编号为3的订单池中的订单数量为5单，则拿取编号为3的订单池中的1单服务订单存储至编号为2的订单池中。

本申请实施例提供的服务订单的处理方法，服务器对多个订单池进行编号，之后根据每个订单池的编号，将获取到的服务订单分别存储至多个订单池。该方法能够不断将服务订单存储至多个订单池，通过设定存储服务订单的频率以及订单池最多可以储存的服务订单数量，使得订单池处于高负荷状态，满足服务器从订单池中获取服务订单的需求。

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

图8为本申请实施例提供的服务订单的处理装置实施例的结构示意图。

如图8所示，该服务订单的处理装置可以包括：

接收模块81，用于接收用户的终端设备发送的查询请求，查询请求包括用户信息以及页码参数，页码参数用于确定服务订单列表的页码。

在一种具体的实现方式中，该接收模块81可以用来实现图1B中接收模块12的功能。

处理模块82，用于根据用户信息，从活跃度列表中获取用户对应的抢单活跃度，活跃度列表中包括多个用户对应的抢单活跃度；

处理模块82，还用于根据抢单活跃度，页码参数以及订单池总数量，获取第一订单池编号，并从第一订单池编号对应的第一订单池中获取待处理的服务订单，每个订单池中存储的服务订单不同；

处理模块82，还于根据待处理的服务订单生成服务订单列表。

在一种具体的实现方式中，该处理模块82可以用来实现图1B中定时模块11，活跃度获取模块13，计算模块14，订单池控制模块15的功能。

发送模块83，用于将服务订单列表返回用户的终端设备。

示例性的，在本实施例的一种可能设计中，该处理模块82，还用于若获取的服务订单的数量小于服务订单列表可显示的订单数量，且递归次数未超过订单池总数量，则根据第一订单池编号，递归次数以及订单池总数量，计算第二订单池编号，并从第二订单池编号对应的第二订单池中继续获取待处理的服务订单，重复本步骤，直至获取到的待处理的服务订单数量达到服务订单列表可显示的订单数量，递归次数用于表示已获取服务订单的订单池的数量。

示例性的，在本实施例的另一种可能设计中，活跃度列表中的多个用户的抢单活跃度按照从大到小的顺序排列，处理模块82，具体用于：

根据用户信息，查询用户信息在活跃度列表中的排列位置；

根据排列位置，确定用户对应的抢单活跃度。

可选的，处理模块82，还用于：

用于将用户对应的抢单活跃度更新至活跃度列表的第一位。

示例性的，在本实施例的再一种可能设计中，接收装置81，还用于接收用户的终端设备发送的刷新请求，刷新请求用于指示重新获取服务订单列表；

处理模块82，还用于根据刷新请求，对查询请求中的页码参数进行更新，得到新的页码参数；

处理模块82，还用于根据抢单活跃度，新的页码参数以及订单池总数量，获取第三订单池编号，并从第三订单池编号对应的第三订单池中获取新的待处理的服务订单；

处理模块82，还用于根据新的待处理的服务订单生成新的服务订单列表；

发送模块83，还用于将新的服务订单列表返回用户的终端设备。

示例性的，在本实施例的又一种可能设计中，处理模块82，还用于：

对多个订单池进行编号；

根据每个订单池的编号，将获取到的服务订单分别存储至多个订单池。

可选的，处理模块82，具体用于：

根据每个订单池的剩余容量，按照订单池编号的顺序，依次将获取到的服务订单存储至订单池，每个订单池的剩余容量用于表示订单池中还可以存储的订单数量。

可选的，处理模块82，还用于：

若未获取到新的服务订单，则根据每个订单池的剩余容量，将订单池编号在后的订单池中的订单转存至订单池编号在前的订单池中。

本申请实施例提供的服务订单的处理装置，可用于执行上述实施例中的服务订单的处理方法，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。此外，这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

图9为本申请实施例提供的服务器的结构示意图。如图9所示，该服务器可以包括：处理器91、收发器92、存储器93及存储在所述存储器93上并可在处理器91上运行的计算机程序指令，所述处理器91执行所述计算机程序指令时实现前述任一实施例提供的服务订单的处理方法。

收发器92用于和其他计算机进行通信。可选的，在硬件实现上，上述图8所示实施例中的接收模块81和发送模块84对应于本实施例中的收发器92，该收发器92构成通信接口。

可选的，该服务器的上述各个器件之间可以通过系统总线连接。

存储器93可以是单独的存储单元，也可以是集成在处理器中的存储单元。处理器的数量为一个或者多个。

应理解，处理器91可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

系统总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。存储器可能包含随机存取存储器(randomaccess memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一可读取存储器中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储器(存储介质)包括：只读存储器(英文：read-only memory，简称：ROM)、RAM、快闪存储器、硬盘、固态硬盘、磁带(英文：magnetic tape)、软盘(英文：floppydisk)、光盘(英文：optical disc)及其任意组合。

本申请实施例提供的服务器，可用于执行上述任一方法实施例提供的服务订单的处理方法，其实现原理和技术效果类似，在此不再赘述。

本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述服务订单的处理方法。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

可选的，将可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

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

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。