一种数据处理方法、服务器和***
技术领域
本发明涉及网络技术领域,特别是涉及一种数据处理法、一种服务器和一种数据处理***。
背景技术
随着网络技术的发展,越来越多的用户在网络中执行各种操作,如看电影、玩游戏、购物等。
虽然网络为用户提供的各种各样的资源,但是并不是所有的用户都能获取到请求的资源。并且当大量用户在同一段时间内请求同一资源时,服务器要处理的数据量过大,就很可能导致服务器崩溃。
发明内容
鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的数据处理方法和相应的服务器以及数据处理***。
依据本发明的一个方面,提供了一种数据处理方法,包括:在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求;针对每个获取请求,对所述获取请求中的请求参数进行验证,若验证通过则请求成功;对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储;将所述预置目标分配给所述用户。
可选的,对所述获取请求中的请求参数进行验证,包括:检测所述请求参数中用户提供的价值数据是否大于获取价值,其中,将每次请求成功的用户提供的价值数据更新为获取价值;当所述价值数据大于所述获取数据时,所述请求参数的验证通过。
可选的,对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储,包括:获取所述请求参数对应的版本标识,采用上一次请求成功的用户对应版本标识对所述版本标识进行检测;当所述版本标识检测通过后,将预置目标的当前获取人更新为所述用户,并将获取价值更新为所述价值数据。
可选的,将所述预置目标分配给所述用户,包括:在所述分配时间段结束时,将所述预置目标分配给当前获取人对应记录的用户。
可选的,还包括:在分配时间段开始前对请求参与的用户进行鉴权;当鉴权通过后对所述参与的用户返回目标获取页面,以允许所述用户发送获取请求。
可选的,还包括:在所述用户的账户中扣除对应积分数据,并将上一次请求成功的用户扣除的积分数据返还。
可选的,还包括:当积分数据扣除失败或积分数据返回失败时,尝试重新执行积分数据的扣除或返还操作,并将对应的失败事件记录在***日志中。
可选的,还包括:在接收到用户发送的查询请求或所述获取请求时,获取记录的当前获取人和获取价值,将所述当前获取人和获取价值反馈给所述用户。
根据本发明的另一个方面,还公开了一种服务器,包括:接收模块,用于在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求;参数验证模块,用于针对每个获取请求,对所述获取请求中的请求参数进行验证,若验证通过则请求成功;版本验证模块,用于对所述请求参数对应的版本标识进行验证;数据存储模块,用于在所述版本标识验证通过后对所述请求参数进行存储;分配模块,用于将所述预置目标分配给所述用户。
可选的,所述参数验证模块,用于检测所述请求参数中用户提供的价值数据是否大于获取价值,其中,将每次请求成功的用户提供的价值数据更新为获取价值;当所述价值数据大于所述获取数据时,所述请求参数的验证通过。
可选的,所述版本验证模块,用于获取所述请求参数对应的版本标识,采用上一次请求成功的用户对应版本标识对所述版本标识进行检测;所述数据存储模块,用于当所述版本标识检测通过后,将预置目标的当前获取人更新为所述用户,并将获取价值更新为所述价值数据。
可选的,所述分配模块,用于在所述分配时间段结束时,将所述预置目标分配给当前获取人对应记录的用户。
可选的,还包括:鉴权模块,用于在分配时间段开始前对请求参与的用户进行鉴权;当鉴权通过后对所述参与的用户返回目标获取页面,以允许所述用户发送获取请求。
可选的,还包括:积分处理模块,用于在所述用户的账户中扣除对应积分数据,并将上一次请求成功的用户扣除的积分数据返还。
可选的,所述积分处理模块,还用于当积分数据扣除失败或积分数据返回失败时,尝试重新执行积分数据的扣除或返还操作,并将对应的失败事件记录在***日志中。
可选的,还包括:查询模块,用于在接收到用户发送的查询请求或所述获取请求时,获取记录的当前获取人和获取价值,将所述当前获取人和获取价值反馈给所述用户。
根据本发明的另一个方面,还公开了一种数据处理***,包括:客户端、数据库和如本发明实施例所述的服务器。
在分配时间段内通过至少两个进程接收各用户发送的获取请求,针对每个获取请求对其中的请求参数进行验证,若验证通过则请求成功,对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储,将所述预置目标分配给所述用户。从而通过多进程并发处理多个请求,防止由于数据量过大而导致***崩溃,且能够提高数据效率。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了根据本发明一个实施例的一种数据处理方法实施例的步骤流程图;
图2示出了根据本发明另一个实施例的一种数据处理方法实施例的步骤流程图;
图3示出了根据本发明另一个实施例的一种数据处理方法优选实施例的步骤流程图;
图4示出了根据本发明一个实施例的一种服务器实施例的结构框图;
图5示出了根据本发明另一个实施例的一种服务器实施例的结构框图;
图6示出了根据本发明一个实施例的一种数据处理***实施例的结构框图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
实施例一
参照图1,示出了根据本发明一个实施例的一种数据处理方法实施例的步骤流程图,具体可以包括如下步骤:
步骤102,在分配预置目标的分配时间段内,通过至少两个进程获取各用户发送的获取请求。
服务器在对预置目标进行分配时,为防止数据量过大引起服务器的崩溃等问题,可以设置多于一个进程并发处理用户的请求,提高数据的处理性能。其中,对于预置目标的分配可以是在一段时间内执行的,即设置分配时间段,在该分配时间段外无法请求获取该预置目标。
在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求,因此可以并发处理多个用户的请求,保证请求处理的时效性。
步骤104,针对每个获取请求,对所述获取请求中的请求参数进行验证,若验证通过则请求成功。
针对每个获取请求,从所述获取请求中获取请求参数,然后对所述请求参数进行验证,例如验证该用户是否为合法用户,用户的积分等数据是否足够执行本次操作,用户的获取请求是否合法等。若对请求参数的验证成功,则对于预置目标的请求成功。若请求参数验证失败,则本次获取失败,可以反馈用户相应的提示信息,以提示其获取失败,重新获取等。
步骤106,对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储。
由于预置目标是有限的,因此为防止多用户并发请求时分配出错,在请求成功后还要对请求参数对应的版本标识进行检验,例如对每次请求成功的版本标识+1,或者配置相应的成功标识等,然后通过数据库中存储的数据进行验证。若对版本标识的验证通过,则表征用户当前获取预置目标成功,可以在数据库中存储相应的请求参数,例如用户标识等;若对版本标识的验证失败,则同样可以提示用户获取失败等信息。
步骤108,将所述预置目标分配给所述用户。
对于获取预置目标成功的用户可以分配相应的预置目标。其中,本实施例预置目标可以是实体产品,也可以是数字产品,上述方法可以应用于可用到秒杀、限时购等短时间高并发场景中,则对于请求成功的用户即分配预置目标,也可以应用于竞拍等场景中,例如游戏平台提供的竞拍***,则最终出价成功的用户才会被分配预置目标。
综上,在分配时间段内通过至少两个进程接收各用户发送的获取请求,针对每个获取请求对其中的请求参数进行验证,若验证通过则请求成功,对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储,将所述预置目标分配给所述用户。从而通过多进程并发处理多个请求,防止由于数据量过大而导致***崩溃,且能够提高数据效率。
实施例二
在上述实施例的基础上,本实施例详细论述针对预置目标进行分配的处理步骤。示出了根据本发明另一个实施例的一种数据处理方法实施例的步骤流程图
参照图2,,具体可以包括如下步骤:
步骤202,在分配时间段开始前对请求参与的用户进行鉴权,检测鉴权是否通过。
在用户进入目标获取页面之前,要先发送参与请求给服务器,服务器依据该参与请求对用户进行鉴权,即检测用户是否具有参与权限,例如检测用户是否以登录,是否符合参与条件等。
若对用户的鉴权不通过,则执行步骤204;若对用户的鉴权通过则执行步骤206。
步骤204,反馈鉴权失败提示。
当用户鉴权未通过时,反馈鉴权失败提示,其中可以标识出失败原因,如用户未登录,则直接反馈登录页面,又如用户不符合登录条件,则反馈哪些条件不符合等。
步骤206,对所述参与的用户返回目标获取页面,以允许所述用户发送获取请求。
在用户鉴权通过后,对该用户反馈目标获取页面,即直接进入对该预置目标进行分配的页面,如抢购或秒杀页面等,从而用户可以在该页面内触发发送相应的获取请求来请求获取预置目标。
步骤208,在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求。
步骤210,针对每个获取请求,对所述获取请求中的请求参数进行验证,确认验证是否通过。
若验证通过,执行步骤212;若验证失败,执行步骤218。
步骤212,对所述请求参数对应的版本标识进行验证,确定是否通过验证。
若验证通过,执行步骤214;若验证失败,执行步骤218。
步骤214,在所述版本标识验证通过后对所述请求参数进行存储。
步骤216,将所述预置目标分配给所述用户。
步骤218,反馈失败提示。
用户在鉴权通过进入目标获取页面后,在分配预置目标的分配时间段内点击触发获取请求的发送,服务器可以通过至少两个进程接收各用户发送的获取请求,针对每个获取请求,从所述获取请求中获取请求参数,然后对所述请求参数进行验证,在参数验证通过后,由于预置目标是有限的,因此为防止分配错误,例如确认能够获取的用户多于预置目标的数量,因此还要对该请求参数对应版本标识进行检测,在版本标识验证成功后,该用户才可能被分配预置目标,将该请求参数存储到数据库中,而后将预置目标分配给相应的用户。
上述论述了对预置目标分配的数据处理步骤,例如应用于秒杀、抢购等场景中。实际处理中还存在竞拍等场景,举例论述针对竞拍场景下预置目标的分配处理步骤。
其中,竞拍基本按照设定的规则执行,例如按照“英式拍卖”规则来执行,即在一定时间内谁出价最高,预置目标(如奖品等)最终归谁获得。且为了提高参与门槛,让用户有参与感和紧迫感,还可以设置用户入场券的限制,从而对用户进行筛选,同时也能够在一定程度上减少服务器的负担。
参照图3,示出了根据本发明另一个实施例的一种数据处理方法优选实施例的步骤流程图,具体可以包括如下步骤:
步骤302,在分配时间段开始前对请求参与的用户进行鉴权,检测鉴权是否通过。
在用户进入目标获取页面之前,要先发送参与请求给服务器,服务器依据该参与请求对用户进行鉴权,即检测用户是否具有参与权限,例如检测用户是否以登录,是否符合参与条件等。
若对用户的鉴权不通过,则执行步骤304;若对用户的鉴权通过则执行步骤306。
步骤304,反馈鉴权失败提示。
当用户鉴权未通过时,反馈鉴权失败提示,其中可以标识出失败原因,如用户未登录,则直接反馈登录页面,又如用户不符合登录条件,则反馈哪些条件不符合等。
步骤306,对所述参与的用户返回目标获取页面,以允许所述用户发送获取请求。
在用户鉴权通过后,对该用户反馈目标获取页面,即直接进入对该预置目标进行分配的页面,如抢购或秒杀页面等,从而用户可以在该页面内触发发送相应的获取请求来请求获取预置目标。
步骤308,在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求。
步骤310,针对每个获取请求,检测所述请求参数中用户提供的价值数据是否大于获取价值。
用户在鉴权通过进入目标获取页面后,在分配预置目标的分配时间段内点击触发获取请求的发送,服务器可以通过至少两个进程接收各用户发送的获取请求,针对每个获取请求,对请求参数进行验证。
针对竞拍***,预置目标由提供价值较高的用户获取,因此会获取请求参数中用户提供的价值数据,检测该价值数据是否大于获取价值,其中,将每次请求成功的用户提供的价值数据更新为获取价值,即将当前出价竞拍成功的用户所提供的价值数据作为获取价值,只有高于该获取价值的价值数据才有可能成功。
若用户提供的价值数据大于获取价值,则出价成功即请求成功,后续执行步骤312;若用户提供的价值数据不大于获取价值,则出价失败即请求失败,后续执行步骤320。
本发明实施例中,请求参数中还可以包括其他参数分配进行请求参数的验证,例如验证场次状态、上次出价是否为自己、是否付过入场费、查询个人积分是否足够。
如通过验证场次状态确定该次竞拍是否开始、正在进行或已结束等,从而确定当前是否能够出价。通过上次出价是否为自己确定当前出价是否成功,若上次出价为自己,则此次出价失败,即验证失败。检测是否付过入场费,若未付入场费则后续可以扣除相应的入场费等数据。另外,每次竞拍时还会扣除一定的积分数据,则还可以检测用户的积分数据是否足够等。
步骤312,在所述用户的账户中扣除对应积分数据,并将上一次请求成功的用户扣除的积分数据返还。
在用户的请求参数验证成功后,当前用户提供的价值数据超过上一次请求成功(即出价成功)的用户,则认为该用户请求成功也即出价成功。此时要从该用户的账户中扣除对应的积分数据。本实施例可以为对每次出价成功的用户均扣除相应的积分数据。
由于是多个用户竞拍有限数量的预置目标,因此还可以仅对当前出价成功的用户扣除积分数据,而对上一次出价成功的用户返回响应的积分数据,避免用户积分的损失。另外,针对上一步骤中检测未提供出场费的用户,也可以在此时扣除相应的出场费。
本发明一个可选实施例中,当积分数据扣除失败或积分数据返回失败时,尝试重新执行积分数据的扣除或返还操作,并将对应的失败事件记录在***日志中。
若用户的积分数据扣除失败,或者上一次请求成功的用户的积分数据返回失败,则可以尝试重新执行积分数据的扣除或返还操作,并在***日志中记录扣除失败或返回失败的事件。
本发明实施例中,还基于原子性原理,其中,事务的原子性指的是,事务中包含的程序作为数据库的逻辑工作单位,它所做的对数据修改操作要么全部执行,要么完全不执行。因此在需要数据库中扣除积分数据以及返还积分数据时,上述两个操作需要均执行完毕,或者均不执行,若任一操作执行失败,则可以回滚回上述均未执行的状态,即仍然为上一次请求成功时的状态,然后重新执行上述操作。
步骤314,获取所述请求参数对应的版本标识,采用上一次请求成功的用户对应版本标识对所述版本标识进行检测,确定检测是否通过。
在用户请求成功并且对积分数据的处理完成后,可以获取该请求参数对应的版本标识,然后对该版本标识进行检测。即基于一次请求成功的用户对应版本标识对所述版本标识进行检测,例如两者相同,或者符合一定的规律等。
其中,本实施例可以依据乐观锁的原理执行上述操作。乐观锁(OptimisticLocking)相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。
例如***初始化是数据版本(Version)标识为0,则首次出价成功的用户的版本标识为0+1即1,每次出价成功的用户的版本标识均为前一次版本标识X+1,从而在并发处理大量请求防止出现错误,例如在当前的版本标识通过检测过程中,确定另一用户也相对于上一次出价成功,则此后已经版本标识+1,而另一用户的请求验证版本标识时与该版本标识相同,表征未通过验证,即该用户当前出价是不成功的。从而通过乐观锁原理保证数据的合理性,将合理的数据存入数据库中。
因此,若版本标识验证成功,则执行步骤316;若版本标识验证失败,则执行步骤320。
步骤316,将预置目标的当前获取人更新为所述用户,并将获取价值更新为所述价值数据。
在用户的版本标识通过验证后,确认该当前获取预置目标成功,即该用户为当前出价最高的用户,则将预置目标的当前获取人更新为所述用户,并将获取价值更新为所述价值数据。此后以该价值数据为基准进行竞拍。
步骤318,在所述分配时间段结束时,将所述预置目标分配给当前获取人对应记录的用户。
在分配时间段结束表征此次竞拍结束,则此时记录为当前获取人的用户即为最终竞拍成功的用户,将预置目标分配给该用户。
步骤320,反馈失败提示。
在用户的请求参数验证失败,如价值数据不大于获取价值,或者场次状体为未开始或已结束,或者积分不足等情况下,向用户反馈出价失败的提示,并且可以提示出相应的失败原因。
若积分数据扣除失败或返还失败,且重复执行次数超过阈值,则通过可以反馈失败提示。另外,在对用户的版本标识验证失败时,也可以反馈相应的失败提示。
本发明一个可选实施例中,在接收到用户发送的查询请求或所述获取请求时,获取记录的当前获取人和获取价值,将所述当前获取人和获取价值反馈给所述用户。
本实施例中,可以通过短轮询的方式更新用户侧的数据。即在接收到用户发送的查询请求,例如通过触发目标获取页面的刷新按钮发送,或者在用户发送获取请求时,获取在数据库中记录的当前获取人和获取价值,将当前获取人和获取价值反馈给所述用户,以便用户获知当前最近的竞价数据。通过使用短轮询的方式使得逻辑结构更加的简单化,同时不依赖其它外部服务使得整体项目风险可控。
本实施例中,上述数据处理方法可以应用于数据处理***中,该***包括在客户端、服务器、数据库等设备。客户端:用户端,使之与服务器对应,为客户提供本地服务的程序。服务器:也称伺服器,是提供计算机服务的设备。由于服务器需要相应服务请求并进行处理,因此服务器通常具备承担服务并且保障服务的能力。数据库放弃了读写速度较慢的关系型数据库,转而使用了速度更快的非关系型数据库redis,redis同时是内存级别的存储,相比一般的数据库性能更高。
上述竞拍的数据处理***可以应用于各种场景中,处理对于实体产品的竞拍之外,还可以对电子产品进行竞拍,例如对于游戏***提供的奖励产品如装备等进行竞拍,从而通过竞拍为用户提供各种所需的产品。
本实施例中,在竞拍开始之前即分配时间段开始前,就提前验证竞拍者(用户)的相关信息,从而能够有效过滤大量请求对后端的压力。且上述过程的代码逻辑尽可能的简洁,能减少代码解析产生的开销。
本实施例还引入了乐观锁原理和原子性原理使用lua+redis的组合,从而在数据存取过程高效的同时还避免了并发产生的相关错误,保证对数据的高效、稳定处理。
本实施例中,部分数据提取接口使用能嵌在nginx进程内部的脚本,这样就避免了多套进程相互切换带来的额外开销,而脚本语言相对php、java等语言更小巧轻量,解析也更容易,性能也具有较大的提升。并且,后端启动进程整理归纳数据,减少用户访问时因需要及时准备数据的开销。
对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明实施例并不受所描述的动作顺序的限制,因为依据本发明实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本发明实施例所必须的。
实施例三
在上述实施例的基础上,本实施例还公开了一种服务器。
参照图4,示出了根据本发明一个实施例的一种服务器实施例的结构框图,具体可以包括如下模块:
接收模块402,用于在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求。
参数验证模块404,用于针对每个获取请求,对所述获取请求中的请求参数进行验证,若验证通过则请求成功。
版本验证模块406,用于对所述请求参数对应的版本标识进行验证。
数据存储模块408,用于在所述版本标识验证通过后对所述请求参数进行存储。
分配模块410,用于将所述预置目标分配给所述用户。
综上,在分配时间段内通过至少两个进程接收各用户发送的获取请求,针对每个获取请求对其中的请求参数进行验证,若验证通过则请求成功,对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储,将所述预置目标分配给所述用户。从而通过多进程并发处理多个请求,防止由于数据量过大而导致***崩溃,且能够提高数据效率。
参照图5,示出了根据本发明另一个实施例的一种服务器实施例的结构框图,具体可以包括如下模块:
鉴权模块512,用于在分配时间段开始前对请求参与的用户进行鉴权;当鉴权通过后对所述参与的用户返回目标获取页面,以允许所述用户发送获取请求。
接收模块502,用于在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求。
参数验证模块504,用于针对每个获取请求,对所述获取请求中的请求参数进行验证,若验证通过则请求成功。
积分处理模块514,用于在所述用户的账户中扣除对应积分数据,并将上一次请求成功的用户扣除的积分数据返还。
版本验证模块506,用于对所述请求参数对应的版本标识进行验证。
数据存储模块508,用于在所述版本标识验证通过后对所述请求参数进行存储。
查询模块516,用于在接收到用户发送的查询请求或所述获取请求时,获取记录的当前获取人和获取价值,将所述当前获取人和获取价值反馈给所述用户。
分配模块510,用于将所述预置目标分配给所述用户。
本发明一个可选实施例中,所述参数验证模块504,用于检测所述请求参数中用户提供的价值数据是否大于获取价值,其中,将每次请求成功的用户提供的价值数据更新为获取价值;当所述价值数据大于所述获取数据时,所述请求参数的验证通过。
所述版本验证模块506,用于获取所述请求参数对应的版本标识,采用上一次请求成功的用户对应版本标识对所述版本标识进行检测;所述数据存储模块508,用于当所述版本标识检测通过后,将预置目标的当前获取人更新为所述用户,并将获取价值更新为所述价值数据。
所述分配模块510,用于在所述分配时间段结束时,将所述预置目标分配给当前获取人对应记录的用户。
所述积分处理模块514,还用于当积分数据扣除失败或积分数据返回失败时,尝试重新执行积分数据的扣除或返还操作,并将对应的失败事件记录在***日志中。
本发明实施例还公开了一种数据处理***,如图6所示,包括:客户端62、数据库64和服务器66,该服务器与上述实施例所述的服务器基本一致,因此不再赘述。
本实施例中,上述数据处理方法可以应用于数据处理***中,该***包括在客户端、服务器、数据库等设备。客户端:用户端,使之与服务器对应,为客户提供本地服务的程序。服务器:也称伺服器,是提供计算机服务的设备。由于服务器需要相应服务请求并进行处理,因此服务器通常具备承担服务并且保障服务的能力。数据库放弃了读写速度较慢的关系型数据库,转而使用了速度更快的非关系型数据库redis,redis同时是内存级别的存储,相比一般的数据库性能更高。
上述竞拍的数据处理***可以应用于各种场景中,处理对于实体产品的竞拍之外,还可以对电子产品进行竞拍,例如对于游戏***提供的奖励产品如装备等进行竞拍,从而通过竞拍为用户提供各种所需的产品。
本实施例中,在竞拍开始之前即分配时间段开始前,就提前验证竞拍者(用户)的相关信息,从而能够有效过滤大量请求对后端的压力。且上述过程的代码逻辑尽可能的简洁,能减少代码解析产生的开销。
本实施例还引入了乐观锁原理和原子性原理使用lua+redis的组合,从而在数据存取过程高效的同时还避免了并发产生的相关错误,保证对数据的高效、稳定处理。
本实施例中,部分数据提取接口使用能嵌在nginx进程内部的脚本,这样就避免了多套进程相互切换带来的额外开销,而脚本语言相对php、java等语言更小巧轻量,解析也更容易,性能也具有较大的提升。并且,后端启动进程整理归纳数据,减少用户访问时因需要及时准备数据的开销。
对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述,构造这类***所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的数据处理方法、服务器和***设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
本发明公开了A1、一种数据处理方法,包括:在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求;针对每个获取请求,对所述获取请求中的请求参数进行验证,若验证通过则请求成功;对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储;将所述预置目标分配给所述用户。
A2、如A1所述的方法,对所述获取请求中的请求参数进行验证,包括:检测所述请求参数中用户提供的价值数据是否大于获取价值,其中,将每次请求成功的用户提供的价值数据更新为获取价值;当所述价值数据大于所述获取数据时,所述请求参数的验证通过。
A3、如A2所述的方法,对所述请求参数对应的版本标识进行验证,并在所述版本标识验证通过后对所述请求参数进行存储,包括:获取所述请求参数对应的版本标识,采用上一次请求成功的用户对应版本标识对所述版本标识进行检测;当所述版本标识检测通过后,将预置目标的当前获取人更新为所述用户,并将获取价值更新为所述价值数据。
A4、如A3所述的方法,将所述预置目标分配给所述用户,包括:在所述分配时间段结束时,将所述预置目标分配给当前获取人对应记录的用户。
A5、如A1所述的方法,还包括:在分配时间段开始前对请求参与的用户进行鉴权;当鉴权通过后对所述参与的用户返回目标获取页面,以允许所述用户发送获取请求。
A6、如A2所述的方法,还包括:在所述用户的账户中扣除对应积分数据,并将上一次请求成功的用户扣除的积分数据返还。
A7、如A6所述的方法,还包括:当积分数据扣除失败或积分数据返回失败时,尝试重新执行积分数据的扣除或返还操作,并将对应的失败事件记录在***日志中。
A8、如A3所述的方法,还包括:在接收到用户发送的查询请求或所述获取请求时,获取记录的当前获取人和获取价值,将所述当前获取人和获取价值反馈给所述用户。
本发明还公开了B9、一种服务器,包括:接收模块,用于在分配预置目标的分配时间段内,通过至少两个进程接收各用户发送的获取请求;参数验证模块,用于针对每个获取请求,对所述获取请求中的请求参数进行验证,若验证通过则请求成功;版本验证模块,用于对所述请求参数对应的版本标识进行验证;数据存储模块,用于在所述版本标识验证通过后对所述请求参数进行存储;分配模块,用于将所述预置目标分配给所述用户。
B10、如B9所述的服务器,所述参数验证模块,用于检测所述请求参数中用户提供的价值数据是否大于获取价值,其中,将每次请求成功的用户提供的价值数据更新为获取价值;当所述价值数据大于所述获取数据时,所述请求参数的验证通过。
B11、如B10所述的服务器,所述版本验证模块,用于获取所述请求参数对应的版本标识,采用上一次请求成功的用户对应版本标识对所述版本标识进行检测;所述数据存储模块,用于当所述版本标识检测通过后,将预置目标的当前获取人更新为所述用户,并将获取价值更新为所述价值数据。
B12、如B11所述的服务器,所述分配模块,用于在所述分配时间段结束时,将所述预置目标分配给当前获取人对应记录的用户。
B13、如B9所述的服务器,还包括:鉴权模块,用于在分配时间段开始前对请求参与的用户进行鉴权;当鉴权通过后对所述参与的用户返回目标获取页面,以允许所述用户发送获取请求。
B14、如B10所述的服务器,还包括:积分处理模块,用于在所述用户的账户中扣除对应积分数据,并将上一次请求成功的用户扣除的积分数据返还。
B15、如B14所述的服务器,所述积分处理模块,还用于当积分数据扣除失败或积分数据返回失败时,尝试重新执行积分数据的扣除或返还操作,并将对应的失败事件记录在***日志中。
B16、如B11所述的服务器,还包括:查询模块,用于在接收到用户发送的查询请求或所述获取请求时,获取记录的当前获取人和获取价值,将所述当前获取人和获取价值反馈给所述用户。
B17、一种数据处理***,包括:客户端、数据库和如上述B9-B16任一所述的服务器。