一种基于服务端的订单批量统计方法、计算机设备和存储介质

摘要

本发明公开了一种基于服务端的订单批量统计方法、计算机设备和存储介质，该方法应用于服务端中，包括：采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；基于第一笔订单的统计日期，得到第一天的统计开始时刻；将第一天的统计开始时刻加一天的时间得到第一天的统计结束时刻；基于第一天的统计开始时刻和第一天的统计结束时刻，统计第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入订单统计表中，直到当前的所有订单统计完成。服务端不需要依赖大数据技术便可完成订单批量统计，丰富了订单批量统计的实现方式。

说明书

技术领域

本发明属于互联网技术领域，尤其涉及一种基于服务端的订单批量统计方法、计算机设备和存储介质。

背景技术

目前互联网直播平台对于用户充值量来讲，其每日订单流水已经达到较大量，通常情况下需要大数据技术进行支撑来进行统计，由大数据技术统计后的数据再发送给服务端使用。

可见，现有技术中，服务端必须强依赖于大数据技术，订单批量统计的实现方式单一。

发明内容

本申请实施例通过提供一种基于服务端的订单批量统计方法、计算机设备和存储介质，解决了现有技术中服务端对大数据技术的强依赖问题。

第一方面，本申请提供了一种基于服务端的订单批量统计方法，其特征在于，所述方法应用于服务端设备中，包括：

采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

可选的，在所述当前的所有订单统计完成之后，所述方法还包括：

采用函数getMonthStatCacheTime()获取最后一笔订单的统计日期，所述最后一笔订单包含于所述当前的所有订单中；

基于所述最后一笔订单的统计日期，得到前一天的统计结束时刻；

将所述前一天的统计结束时刻减一天的时间得到所述前一天的统计开始时刻；

基于所述前一天的统计开始时刻和所述前一天的统计结束时刻，由定时任务系统按照预置的时间间隔和预置的统计次数调用函数currentDataRun()来重新统计所述前一天的订单数量，并将重新统计的订单数量更新到所述订单统计表中。

可选的，所述基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中包括：

基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，按照不同的支付方式统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中。

可选的，所述支付方式包括微信支付，支付宝支付或银联支付。

本申请还提供了一种基于服务端的订单批量统计装置，其特征在于，所述装置包括：

获取单元，用于采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

所述获取单元还用于基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

所述获取单元还用于将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

统计单元，用于基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

所述统计单元还用于将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

可选的，所述获取单元还用于采用函数getMonthStatCacheTime()获取最后一笔订单的统计日期，所述最后一笔订单包含于所述当前的所有订单中；

所述获取单元还用于基于所述最后一笔订单的统计日期，得到前一天的统计结束时刻；

所述获取单元还用于将所述前一天的统计结束时刻减一天的时间得到所述前一天的统计开始时刻；

所述统计单元还用于基于所述前一天的统计开始时刻和所述前一天的统计结束时刻，由定时任务系统按照预置的时间间隔和预置的统计次数调用函数currentDataRun()来重新统计所述前一天的订单数量，并将重新统计的订单数量更新到所述订单统计表中。

可选的，所述统计单元具体用于基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，按照不同的支付方式统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中。

可选的，所述支付方式包括微信支付，支付宝支付或银联支付。

第三方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现以下步骤：

采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

第四方面，本申请提供了一种计算机设备，包括处理器、存储器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：

采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

本申请实施例应用于服务端设备中，通过采用函数getFirstOrderByType(type)获取第一笔订单的统计日期，得到第一天的统计开始时刻，将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻，从而统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中，将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。可见，服务端不需要依赖大数据技术便可完成订单批量统计，丰富了订单批量统计的实现方式。

附图说明

图1为本申请实施例中提供的基于服务端的订单批量统计方法的流程图；

图2为本申请实施例中提供的基于服务端的订单批量统计装置的结构示意图；

图3为本申请实施例中提供的计算机可读存储介质的结构示意图；

图4为本申请实施例中提供的计算机设备的结构示意图。

具体实施方式

本申请实施例提供了一种基于服务端的订单批量统计方法、计算机设备和存储介质，解决了现有技术中服务端对大数据技术的强依赖问题。可以使服务端不再依赖于大数据技术便可完成订单批量统计，丰富了订单批量统计的实现方式。

本申请实施例的技术方案为解决上述技术问题，总体思路如下：

采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

本申请实施例应用于服务端设备中，通过采用函数getFirstOrderByType(type)获取第一笔订单的统计日期，得到第一天的统计开始时刻，将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻，从而统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中，将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。服务端不需要依赖大数据技术便可完成订单批量统计，丰富了订单批量统计的实现方式。

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

本申请实施例可以基于但不限于Redis(Remote Dictionary Server，远程字典服务器)、MySQL(Structured Query Language，结构化查询语言)和定时任务系统技术来实现，本申请实施例仅以上述技术作为基础进行介绍，并不用于限定本申请。可以理解的是，在一些其他的实现方式中，也可以采用类似的其他存储系统、数据库管理系统和定时任务系统。

上述技术的相关介绍如下：

Redis：是一个key-value存储系统。Redis提供了一些丰富的数据结构，包括lists(链表)，sets(集合)，ordered sets(有序集合)以及hashes(哈希类型)，当然还有和Memcached一样的strings(字符串)结构。Redis作为一个高效的网络的缓存数据功能，性能极高，Redis能支持超过100K+每秒的读写频率。

Mysql：是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性，目前是WEB管理较为常用的数据管理系统。

定时任务系统：可定时执行某些任务的系统，可设定参数定时请求设定的接口。

为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。

实施例一：

请参阅图1，本实施例提供的基于服务端的订单批量统计方法包括以下步骤：

S101、采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

具体的，可以通过采用函数getFirstOrderByType(type)查询MySql订单表来获取第一笔订单的统计日期。函数getFirstOrderByType(type)具体实现过程包括但不限于通过链接数据库，查询SELECT o.id，o.notify_time，FROM_UNIXTIME(o.notify_time，'％Y-％m-％d')as time FROM`order`as o INNER JOIN$joinTable as g WHERE o.id＝g.idAND o.state IN(1，2)AND o.notify_time>0ORDER BY o.id ASC limit 1语句即得到第一笔订单数据，其中notify_time为第一笔订单的统计日期。可以理解的是，该方法仅为实现步骤S101的其中一种方式，并不用于限定本申请。

此外，可以通过set()方法将第一笔订单的统计日期存入Redis缓存中，供下一次统计时使用。

S102、基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

优选的，可以使用第一笔订单的统计日期的起始时刻，即零时零分零秒作为第一天的统计开始时刻，当然，也可以使用其他时刻，只要确保该时刻在第一笔订单的统计时刻之前，此处不做太多限定。

S103、将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

其中，通过按天统计的方式是为了更符合实际的统计习惯，根据设备的能力和实际情况，也可以选择按其他的时间间隔进行统计，此处不做太多限定。

S104、基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

其中，订单统计表可以是新建的统计表，可以把第一天的订单数量封装到data中，然后采用函数addStaticData(data)写入到订单统计表中。

S105、将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

其中，时间间隔可以是一分钟，30秒或其他时间，具体可以根据设备的能力和实际需要，设置合理的时间间隔，当时间间隔设置得越短，就能越快完成统计。

可以理解的是，第一天的统计开始时刻已经通过步骤S102得到，所以每一天不包括第一天，第一天是指第一天之后到当前时刻的每一天。

具体的，可以将统计一天的订单数量的执行过程封装成函数historyDataRun()，再由定时任务系统按照预置的时间间隔调用该函数，则可以短时间内把当前的所有订单，即把历史订单全部统计完成。

可见，本实施例中，服务端不需要依赖于大数据技术便可完成订单批量统计，丰富了订单批量统计的实现方式。

在历史订单统计完成的前提下，后续可以只维护每天的订单数量，当需要查询当前的订单数量时，只要将当天当前的订单数量加上历史订单数量即可。但考虑到在一些具体实现的情况中，支付订单可能存在有效性的问题，例如前一天的订单，在当天才支付，则可以在每一天再对昨天的订单数量进行更新。

所以，进一步的，在当前的所有订单统计完成后，即完成历史订单的统计基础上，还可以包括以下步骤：

a.采用函数getMonthStatCacheTime()获取最后一笔订单的统计日期；

其中，最后一笔订单为步骤S105中当前所有订单中的最后一笔订单，即历史订单中的最后一笔订单。

其中，可以将最后一笔订单的统计日期采用函数setMonthStatTime(time)，其中采用set(time)方法存入Redis缓存中，供下一次统计时使用。

b.基于所述最后一笔订单的统计日期，得到前一天的统计结束时刻；

具体的，可以将最后一笔订单的统计日期的开始时刻，即零时零分零秒作为前一天的统计结束时刻。可以理解的是，前一天指的是该最后一笔订单的统计日期对应的前一天，也就是最后一笔订单的统计日期的昨天。

c.将所述前一天的统计结束时刻减一天的时间得到所述前一天的统计开始时刻；

d.基于所述前一天的统计开始时刻和所述前一天的统计结束时刻，由定时任务系统按照预置的时间间隔和预置的统计次数调用函数currentDataRun()来重新统计所述前一天的订单数量，并将重新统计的订单数量更新到所述订单统计表中。

其中，可以根据设备的能力和实际需要，设置合理的时间间隔和统计次数，统计次数。明显的，当时间间隔设置得越小，统计次数设置得越多，数据越准确。

具体的，采用函数getMonthStatCacheTime()方法，查询到历史订单统计到当天的时间time，作为最后一笔订单的统计结束时间，time-86400作为最后一笔订单的统计开始时间，再采用orderStat(time-86400,time)方法统计到前一天的订单数量。然后再将上述方法封装到函数currentDataRun()，通过定时任务系统按照预置的时间间隔和预置的统计次数调用函数currentDataRun()来循环统计。

可见，通过更新前一天的订单数量，可以提高订单数量的精确度。在后续的每日订单统计中，由于历史订单已完成统计，每一天可以只对昨天和今天的订单进行统计，实现了实时查询订单统计的效果，解决了由大数据统计而造成的订单统计的延时的问题。

还需要说明的是，本实施例还可以按照不同的支付方式统计订单数量。以便于得到各类不同的统计数据进行数据分析。其中，支付方式包括但不限于微信支付，支付宝支付或银联支付，此处不做太多限定。

还需要说明的是，本实施例的实现基于服务端设备，服务端设备包括但不限于直播平台中用到的web服务器。

更进一步的，本实施例还可以包括订单查询的步骤，具体为采用函数getData(param)，查询到统计完成的订单数据，其中param为查询的参数，其中，Param参数中包含查询的开始时间、结束时间、类型等。以便管理人员可以按照开始时间、结束时间和类型等条件实时查询订单数量。

为了便于理解，以下再从应用场景的角度对本实施进行解释说明。

用户A出于成本和时间的考虑，希望通过基于服务端实现直播平台的订单批量统计，从而可以实时查询订单数量。首先，得到直播平台的第一笔订单的统计日期2018-1-1，则将第一天的开始时刻设置为2018-1-1 00:00:00，将第一天的开始时刻加上一天的时间，得到第一天的结束时刻为2018-1-2 00:00:00，获取第一天的开始时刻到结束时刻的订单数量，即为第一天的订单数量，并存入订单统计表中，再将第一天的结束时刻作为第二天的开始时刻，用同样的方法得到第二天的订单数量，以此类推，一直计算到当前日期2018-2-15的订单数量，至此，历史订单统计完成。在后续的时间里，每天只需要再统计昨天和今天的订单数量来维护订单统计表。昨天的订单统计方式为，获取最后一笔订单的统计结束日期，在2018-2-15当天，最后一笔订单的统计结束日期即为2018-2-15，则昨天的统计结束时刻为2018-2-15 00:00:00，减去一天的时间，得到昨天的统计开始时刻2018-2-14 00:00:00，按照每两小时一次，每天统计6次的方式，重新计算昨天的订单数量，并更新到订单统计表中。后来到了2018-2-20这天，用户A希望得到直播平台的订单总数，则通过计算2018-2-20当天的订单数量加上历史订单数量即可快速获取到用户A所需要的数据。

基于同一发明构思，本申请提供了一种基于服务端的订单批量统计装置，详见图2，下面将结合图2对实施例二进行介绍。

实施例二：

请参阅图2，本实施例提供的基于服务端的订单批量统计装置包括：

获取单元201，用于采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

所述获取单元201，还用于基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

所述获取单元201还用于将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

统计单元202，用于基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

所述统计单元202还用于将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

本申请实施例二提供的基于服务端的订单批量统计装置及本申请实施例一提供的基于服务端的订单批量统计方法属于同一构思，其具体实现过程详见说明书全文，此处不再赘述。

基于同一发明构思，本申请提供了一种计算机可读存储介质，详见图3，下面将结合图3对实施例三进行介绍。

实施例三：

本实施例提供了一种计算机可读存储介质300，所述计算机可读存储介质300存储有计算机程序311，所述计算机程序311被处理器执行时实现以下步骤：

采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

在具体实施过程中，该计算机程序311被处理器执行时，可以实现实施例一中任一实施方式，此处不再赘述。

基于同一发明构思，本申请提供了一种计算机设备，详见图4，下面将结合图4对实施例四进行介绍。

实施例四：

本申请提供了一种计算机设备400，包括处理器420、存储器410以及存储在存储器410上并可在处理器420上运行的计算机程序411，所述处理器420执行所述计算机程序411时实现以下步骤：

采用函数getFirstOrderByType(type)获取第一笔订单的统计日期；

基于所述第一笔订单的统计日期，得到第一天的统计开始时刻；

将所述第一天的统计开始时刻加一天的时间得到所述第一天的统计结束时刻；

基于所述第一天的统计开始时刻和所述第一天的统计结束时刻，统计所述第一天的订单数量，并采用函数addStaticData(data)写入订单统计表中；

将上一次的统计结束时刻作为下一次的统计开始时刻，由定时任务系统按照预置的时间间隔调用函数historyDataRun()来依次统计每一天的订单数量，并写入所述订单统计表中，直到当前的所有订单统计完成。

由于本实施例所介绍的计算机设备为实施本申请实施例一中一种基于服务端的订单批量统计方法所采用的设备，故而基于本申请实施例一中所介绍的方法，本领域所属技术人员能够了解本实施例的计算机设备的具体实施方式以及其各种变化形式，所以在此对于该计算机设备如何实现本申请实施例中的方法不再详细介绍。只要本领域所属技术人员实施本申请实施例中的方法所采用的设备，都属于本申请所欲保护的范围，此处不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。