本发明属于高并发场景处理技术领域，尤其涉及一种基于redis与kafka的线上抢购系统高并发场景处理方法及装置。
背景技术：
随着互联网的普及，越来越多的用户选择利用网络购买商品、参与购房和摇号。商家为了吸引用户，经常会举办秒杀、限时抢购等优惠活动，即在有限时间里提供限量的优惠商品，由于价格低廉，往往一秒钟就被抢购一空。由于这种僧多粥少的情况，大量用户在活动开始前后频繁访问服务器，流量会比平时激增几倍甚至几十倍，给服务器带来巨大的压力，超过一定压力容量之后甚至会造成数据不能正常保存、服务无法响应的情况。并且由于有利可图，往往会有用户花高价向工作室购买作弊工具，在短时间内用作弊工具大量访问服务器，不仅破坏了活动的公平性，也给服务器带来更大的负载压力。
目前，大多数站点使用验证码来阻止用户作弊。但对于有经验的工作室来说，验证码可以用提前访问、图形识别等多种手段破解，只能增加普通用户的成本，而让作弊者得利。
因此，如何有效的对高并发场景的海量请求进行处理是一项亟待解决的问题。
技术实现要素：
有鉴于此，本发明提供了一种基于redis与kafka的线上抢购系统高并发场景处理方法，从前端开始对各层级模块进行限流处理，限制单个用户的请求频率，使用持久化缓存技术，利用kafka消息队列对模块异步解耦，将请求的逻辑判断与数据的写操作分离，解决了现有技术中数据库负载过重的问题，并有利于请求的快速响应和反馈；同时通过前后端数据校验的方法来代替旧有的验证码机制，使得用户作弊的成本大大增加，有效地阻止了用户作弊行为。
为了实现上述目的，本发明提供如下技术方案：
一种基于redis与kafka的线上抢购系统高并发场景处理方法，包括：
基于用户登录请求生成登录令牌；
将所述登录令牌写入前端cookie和后端redis缓存中；
校验前端登录令牌与后端登录令牌是否匹配，若否，则返回操作失败结果，若是，则：
判断所述用户登录令牌是否有效，若否，则返回操作失败结果，若是，则：
判断是否获取到对应商品的商品锁，若否，则返回操作失败结果，若是，则：
将抢购成功的请求数据推送给kafka消息队列。
优选地，所述基于用户登录请求生成登录令牌包括：
记录所述用户登录的时间戳；
将所述时间戳与所述用户id拼接字符串；
通过hash运算生成所述令牌。
优选地，所述将抢购成功的请求数据推送给kafka消息队列后，还包括：
消费所述kafka消息队列中的记录，将所述抢购成功的请求数据写入数据库；
发送通知短信给用户；
通过websocket传递成交记录给前端前台。
优选地，所述将所述登录令牌写入前端cookie和后端redis缓存中后，还包括：
记录所述用户的访问次数；
判断基于所述访问次数做hash生成的防作弊校验码是否合法，若否，则：
返回操作失败结果。
优选地，所述方法还包括：
获取用户频率锁；
基于所述频率锁判断所述用户的访问频率是否超过预设阈值，若是，则：
返回操作失败结果。
一种基于redis与kafka的线上抢购系统高并发场景处理装置，包括：
生成模块，用于基于用户登录请求生成登录令牌；
第一写入模块，用于将所述登录令牌写入前端cookie和后端redis缓存中；
校验模块，用于校验前端登录令牌与后端登录令牌是否匹配；
返回模块，用于当前端登录令牌与后端登录令牌不匹配时，返回操作失败结果；
第一判断模块，用于当前端登录令牌与后端登录令牌匹配时，判断所述用户登录令牌是否有效；
所述返回模块，还用于当所述用户登录令牌无效时，返回操作失败结果；
第二判断模块，用于当所述用户登录令牌有效时，判断是否获取到对应商品的商品锁；
所述返回模块，还用于当未获取到对应商品的商品锁时，返回操作失败结果；
推送模块，用于当获取到对应商品的商品锁时，将抢购成功的请求数据推送给kafka消息队列。
优选地，所述生成模块具体用于：
记录所述用户登录的时间戳；
将所述时间戳与所述用户id拼接字符串；
通过hash运算生成所述令牌。
优选地，所述装置还包括：
第二写入模块，用于消费所述kafka消息队列中的记录，将所述抢购成功的请求数据写入数据库；
发送模块，用于发送通知短信给用户；
传递模块，用于通过websocket传递成交记录给前端前台。
优选地，所述装置还包括：
记录模块，用于记录所述用户的访问次数；
第三判断模块，用于判断基于所述访问次数做hash生成的防作弊校验码是否合法；
所述返回模块，还用于当基于所述访问次数做hash生成的防作弊校验码不合法时，返回操作失败结果。
优选地，所述装置还包括：
获取模块，用于获取用户频率锁；
第四判断模块，用于基于所述频率锁判断所述用户的访问频率是否超过预设阈值；
所述返回模块，还用于当基于所述频率锁判断所述用户的访问频率超过预设阈值时，返回操作失败结果。
从上述技术方案可以看出，本发明提供了一种基于redis与kafka的线上抢购系统高并发场景处理方法，当需要对高并发场景的海量请求进行处理时，首先基于用户登录请求生成登录令牌，然后将登录令牌写入前端cookie和后端redis缓存中，校验前端登录令牌与后端登录令牌是否匹配，若否，则返回登录失败结果，若是，则：判断用户登录令牌是否有效，若否，则返回操作失败结果，若是，则：判断是否获取到对应商品的商品锁，若否，则返回操作失败结果，若是，则：将抢购成功的请求数据推送给kafka消息队列。从前端开始对各层级模块进行限流处理，限制单个用户的请求频率，使用持久化缓存技术，利用kafka消息队列对模块异步解耦，将请求的逻辑判断与数据的写操作分离，解决了现有技术中数据库负载过重的问题，并有利于请求的快速响应和反馈；同时通过前后端数据校验的方法来代替旧有的验证码机制，使得用户作弊的成本大大增加，有效地阻止了用户作弊行为。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理方法实施例1的方法流程图；
图2为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理方法实施例2的方法流程图；
图3为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理装置实施例1的结构示意图；
图4为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理装置实施例2的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理方法实施例1的流程图，所述方法包括：
s101、基于用户登录请求生成登录令牌；
当在线上抢购系统中需要对高并发场景的海量请求进行处理时，首先根据用户对线上抢购系统的登录请求生成相应的登录令牌。
s102、将登录令牌写入前端cookie和后端redis缓存中；
当生成登录令牌后，将登录令牌写入前端cookie和后端redis缓存中，便于后续对登录令牌进行校验。
s103、校验前端登录令牌与后端登录令牌是否匹配，若否，则进入s104，若是，则进入s105：
该登录令牌作为用户的登录凭证，每次发起抢购请求时，后端都会对该令牌做校验，判断前后端令牌是否匹配，若不匹配则直接返回失败结果，并提示用户重新登录。需要说明的是，若用户从另一设备登录时，会根据最新的时间戳生成新令牌覆盖旧令牌，使得原设备的前端cookie中存储的令牌失效，这样保证每个用户只能在一台终端设备上登录。
s104、返回操作失败结果；
s105、判断用户登录令牌是否有效，若否，则进入s104，若是，则进入s106：
对发送到服务器的请求做合法性校验，判断用户登录令牌和校验码是否正确，判断活动是否正在进行，判断该用户是否具有抢购资格，对没通过校验的请求全部返回失败结果。
s106、判断是否获取到对应商品的商品锁，若否，则进入s104，若是，则进入s107：
获取对应商品的商品锁，若获取失败，则认为该商品库存已经不足，返回失败结果；若获取商品锁成功，则认为本次抢购成功，返回成功结果。
s107、将抢购成功的请求数据推送给kafka消息队列。
需要说明的是，商品锁通过redis分布式非阻塞锁实现，只尝试一次，不阻塞等待。对于后端所常用的热数据，如活动描述等数据，存储在本地缓存方便多次读取；对于前端所用到的静态资源文件，通过cdn进行服务分发，减轻服务器的负载压力。将逻辑判断与数据写入操作分离，当用户获取商品锁成功就直接返回成功结果，后续操作通过kafka异步处理，提高了响应速度，减轻了数据库压力。
综上所述，在上述实施例中，当需要对高并发场景的海量请求进行处理时，首先基于用户登录请求生成登录令牌，然后将登录令牌写入前端cookie和后端redis缓存中，校验前端登录令牌与后端登录令牌是否匹配，若否，则返回登录失败结果，若是，则：判断用户登录令牌是否有效，若否，则返回操作失败结果，若是，则：判断是否获取到对应商品的商品锁，若否，则返回操作失败结果，若是，则：将抢购成功的请求数据推送给kafka消息队列。从前端开始对各层级模块进行限流处理，限制单个用户的请求频率，使用持久化缓存技术，利用kafka消息队列对模块异步解耦，将请求的逻辑判断与数据的写操作分离，解决了现有技术中数据库负载过重的问题，并有利于请求的快速响应和反馈；同时通过前后端数据校验的方法来代替旧有的验证码机制，使得用户作弊的成本大大增加，有效地阻止了用户作弊行为。
如图2所示，为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理方法实施例2的流程图，所述方法包括：
s201、基于用户登录请求生成登录令牌；
当在线上抢购系统中需要对高并发场景的海量请求进行处理时，首先根据用户对线上抢购系统的登录请求生成相应的登录令牌。在生成登录令牌时，基于用户的登录请求，记录用户登录的时间戳，与用户id拼接字符串，然后做hash运算生成登录令牌。
s202、将登录令牌写入前端cookie和后端redis缓存中；
当生成登录令牌后，将登录令牌写入前端cookie和后端redis缓存中，便于后续对登录令牌进行校验。
s203、记录用户的访问次数；
s204、判断基于访问次数做hash生成的防作弊校验码是否合法，若否，则进入s205，若是，则进入s206：
s205、返回操作失败结果。
前端模块通过后端页面直出数据获取用户初始访问次数，用户每次抢购时，将用户id、商品id和访问次数拼接成字符串，再进行hash运算后作为校验码传递给后端接口，并记录访问次数加一；后端模块接收到请求后，记录增加后的访问次数数值，再利用增加前的访问次数数值以同样算法加密，判断是否匹配。通过前后端共同记录用户访问次数的方式，保证了用户每次发起请求时的校验码都不相同，即使用户模拟前端点击提前获取了一次后端请求接口样例，也无法判断下一次的请求校验码，从而杜绝了用户绕过前端直接用作弊工具频繁调用后端接口的可能。
s206、校验前端登录令牌与后端登录令牌是否匹配，若否，则进入s205，若是，则进入s207：
该登录令牌作为用户的登录凭证，每次发起抢购请求时，后端都会对该令牌做校验，判断前后端令牌是否匹配，若不匹配则直接返回失败结果，并提示用户重新登录。需要说明的是，若用户从另一设备登录时，会根据最新的时间戳生成新令牌覆盖旧令牌，使得原设备的前端cookie中存储的令牌失效，这样保证每个用户只能在一台终端设备上登录。
s207、判断用户登录令牌是否有效，若否，则进入s205，若是，则进入s208：
对发送到服务器的请求做合法性校验，判断用户登录令牌和校验码是否正确，判断活动是否正在进行，判断该用户是否具有抢购资格，对没通过校验的请求全部返回失败结果。
s208、获取用户频率锁；
s209、基于频率锁判断用户的访问频率是否超过预设阈值，若是，则进入s205，若否，则进入s210：
获取用户频率锁，若获取失败，则判断用户访问频率超过了限制，将服务器存储的用户登录令牌置为失效，返回失败结果。
s210、判断是否获取到对应商品的商品锁，若否，则进入s205，若是，则进入s211：
获取对应商品的商品锁，若获取失败，则认为该商品库存已经不足，返回失败结果；若获取商品锁成功，则认为本次抢购成功，返回成功结果。
需要说明的是，频率锁和商品锁都是通过redis分布式非阻塞锁实现，只尝试一次，不阻塞等待。对于后端所常用的热数据，如活动描述等数据，存储在本地缓存方便多次读取；对于前端所用到的静态资源文件，通过cdn进行服务分发，减轻服务器的负载压力。将逻辑判断与数据写入操作分离，当用户获取商品锁成功就直接返回成功结果，后续操作通过kafka异步处理，提高了响应速度，减轻了数据库压力。
s211、将抢购成功的请求数据推送给kafka消息队列；
s212、消费kafka消息队列中的记录，将抢购成功的请求数据写入数据库；
s213、发送通知短信给用户；
s214、通过websocket传递成交记录给前端前台。
综上所述，在上述实施例中，用户从前端登录时，记录最新的登录时间戳，覆盖之前的登录时间戳，存储在前端cookie和后端缓存中；每次判断用户登录状态时，对比前后端时间戳，若不匹配则让用户重新登录；这样保证每个用户只能在一台终端设备上登录，每次登录会覆盖之前的登录，降低用户通过多台设备同时参与抢购的可能性；
前端抢购页面设定一个抢购等待时间，用户每次抢购之后必须等待一定时间才能再次发起请求，避免用户利用按键精灵等工具频繁点击按钮；
后端抢购接口对单个用户的访问频率做限制，若超过一定频次则删除服务器端的用户登录记录，需要用户重新登录才能再次发起抢购；
利用redis分布式锁来保证数据的一致性，代替传统的事务控制，以减少数据库链接的浪费；对单个商品的抢购事件加乐观锁，每次抢购商品都需要先获取锁，若获取失败则直接返回结果给用户；
某用户抢购某商品成功后，直接返回成功结果，再通过kafka消息队列异步进行后续的数据写入和短信通知处理，将逻辑判断与数据写入模块解耦；
对于常用且不常更新的热资源，如活动介绍等数据，存储在服务器本地缓存；对图片、样式文件等静态资源，使用cdn进行服务分发，避免对业务服务器的直接访问。
如图3所示，为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理装置实施例1的结构示意图，所述装置包括：
生成模块301，用于基于用户登录请求生成登录令牌；
当在线上抢购系统中需要对高并发场景的海量请求进行处理时，首先根据用户对线上抢购系统的登录请求生成相应的登录令牌。
第一写入模块302，用于将登录令牌写入前端cookie和后端redis缓存中；
当生成登录令牌后，将登录令牌写入前端cookie和后端redis缓存中，便于后续对登录令牌进行校验。
校验模块303，用于校验前端登录令牌与后端登录令牌是否匹配；
该登录令牌作为用户的登录凭证，每次发起抢购请求时，后端都会对该令牌做校验，判断前后端令牌是否匹配，若不匹配则直接返回失败结果，并提示用户重新登录。需要说明的是，若用户从另一设备登录时，会根据最新的时间戳生成新令牌覆盖旧令牌，使得原设备的前端cookie中存储的令牌失效，这样保证每个用户只能在一台终端设备上登录。
返回模块304，用于当前端登录令牌与后端登录令牌不匹配时，返回操作失败结果；
第一判断模块305，用于当前端登录令牌与后端登录令牌匹配时，判断用户登录令牌是否有效；
对发送到服务器的请求做合法性校验，判断用户登录令牌和校验码是否正确，判断活动是否正在进行，判断该用户是否具有抢购资格，对没通过校验的请求全部返回失败结果。
返回模块304，还用于当所述用户登录令牌无效时，返回操作失败结果；
第二判断模块306，用于当所述用户登录令牌有效时，判断是否获取到对应商品的商品锁；
获取对应商品的商品锁，若获取失败，则认为该商品库存已经不足，返回失败结果；若获取商品锁成功，则认为本次抢购成功，返回成功结果。
返回模块304，还用于当未获取到对应商品的商品锁时，返回操作失败结果；
推送模块307，用于当获取到对应商品的商品锁时，将抢购成功的请求数据推送给kafka消息队列。
需要说明的是，商品锁通过redis分布式非阻塞锁实现，只尝试一次，不阻塞等待。对于后端所常用的热数据，如活动描述等数据，存储在本地缓存方便多次读取；对于前端所用到的静态资源文件，通过cdn进行服务分发，减轻服务器的负载压力。将逻辑判断与数据写入操作分离，当用户获取商品锁成功就直接返回成功结果，后续操作通过kafka异步处理，提高了响应速度，减轻了数据库压力。
综上所述，在上述实施例中，当需要对高并发场景的海量请求进行处理时，首先基于用户登录请求生成登录令牌，然后将登录令牌写入前端cookie和后端redis缓存中，校验前端登录令牌与后端登录令牌是否匹配，若否，则返回登录失败结果，若是，则：判断用户登录令牌是否有效，若否，则返回操作失败结果，若是，则：判断是否获取到对应商品的商品锁，若否，则返回操作失败结果，若是，则：将抢购成功的请求数据推送给kafka消息队列。从前端开始对各层级模块进行限流处理，限制单个用户的请求频率，使用持久化缓存技术，利用kafka消息队列对模块异步解耦，将请求的逻辑判断与数据的写操作分离，解决了现有技术中数据库负载过重的问题，并有利于请求的快速响应和反馈；同时通过前后端数据校验的方法来代替旧有的验证码机制，使得用户作弊的成本大大增加，有效地阻止了用户作弊行为。
如图4所示，为本发明公开的一种基于redis与kafka的线上抢购系统高并发场景处理装置实施例2的结构示意图，所述装置包括：
生成模块401，用于基于用户登录请求生成登录令牌；
当在线上抢购系统中需要对高并发场景的海量请求进行处理时，首先根据用户对线上抢购系统的登录请求生成相应的登录令牌。在生成登录令牌时，基于用户的登录请求，记录用户登录的时间戳，与用户id拼接字符串，然后做hash运算生成登录令牌。
第一写入模块402，用于将登录令牌写入前端cookie和后端redis缓存中；
当生成登录令牌后，将登录令牌写入前端cookie和后端redis缓存中，便于后续对登录令牌进行校验。
记录模块403，用于记录用户的访问次数；
第三判断模块404，用于基于所述访问次数做hash生成的防作弊校验码是否合法；
返回模块405，还用于当基于所述访问次数做hash生成的防作弊校验码不合法时，返回操作失败结果。
前端模块通过后端页面直出数据获取用户初始访问次数，用户每次抢购时，将用户id、商品id和访问次数拼接成字符串，再进行hash运算后作为校验码传递给后端接口，并记录访问次数加一；后端模块接收到请求后，记录增加后的访问次数数值，再利用增加前的访问次数数值以同样算法加密，判断是否匹配。通过前后端共同记录用户访问次数的方式，保证了用户每次发起请求时的校验码都不相同，即使用户模拟前端点击提前获取了一次后端请求接口样例，也无法判断下一次的请求校验码，从而杜绝了用户绕过前端直接用作弊工具频繁调用后端接口的可能。
校验模块406，用于校验前端登录令牌与后端登录令牌是否匹配；
该登录令牌作为用户的登录凭证，每次发起抢购请求时，后端都会对该令牌做校验，判断前后端令牌是否匹配，若不匹配则直接返回失败结果，并提示用户重新登录。需要说明的是，若用户从另一设备登录时，会根据最新的时间戳生成新令牌覆盖旧令牌，使得原设备的前端cookie中存储的令牌失效，这样保证每个用户只能在一台终端设备上登录。
返回模块405，用于当前端登录令牌与后端登录令牌不匹配时，返回操作失败结果；
第一判断模块407，用于当前端登录令牌与后端登录令牌匹配时，判断用户登录令牌是否有效；
对发送到服务器的请求做合法性校验，判断用户登录令牌和校验码是否正确，判断活动是否正在进行，判断该用户是否具有抢购资格，对没通过校验的请求全部返回失败结果。
返回模块405，还用于当所述用户登录令牌无效时，返回操作失败结果；
获取模块408，用于获取用户频率锁；
第四判断模块409，用于基于频率锁判断所述用户的访问频率是否超过预设阈值；
返回模块405，还用于当基于所述频率锁判断所述用户的访问频率超过预设阈值时，返回操作失败结果。
获取用户频率锁，若获取失败，则判断用户访问频率超过了限制，将服务器存储的用户登录令牌置为失效，返回失败结果。
第二判断模块410，用于当所述用户登录令牌有效时，判断是否获取到对应商品的商品锁；
获取对应商品的商品锁，若获取失败，则认为该商品库存已经不足，返回失败结果；若获取商品锁成功，则认为本次抢购成功，返回成功结果。
需要说明的是，频率锁和商品锁都是通过redis分布式非阻塞锁实现，只尝试一次，不阻塞等待。对于后端所常用的热数据，如活动描述等数据，存储在本地缓存方便多次读取；对于前端所用到的静态资源文件，通过cdn进行服务分发，减轻服务器的负载压力。将逻辑判断与数据写入操作分离，当用户获取商品锁成功就直接返回成功结果，后续操作通过kafka异步处理，提高了响应速度，减轻了数据库压力。
返回模块405，还用于当未获取到对应商品的商品锁时，返回操作失败结果；
推送模块411，用于当获取到对应商品的商品锁时，将抢购成功的请求数据推送给kafka消息队列；
第二写入模块412，用于消费kafka消息队列中的记录，将抢购成功的请求数据写入数据库；
发送模块413，用于发送通知短信给用户；
传递模块414，用于通过websocket传递成交记录给前端前台。
综上所述，在上述实施例中，用户从前端登录时，记录最新的登录时间戳，覆盖之前的登录时间戳，存储在前端cookie和后端缓存中；每次判断用户登录状态时，对比前后端时间戳，若不匹配则让用户重新登录；这样保证每个用户只能在一台终端设备上登录，每次登录会覆盖之前的登录，降低用户通过多台设备同时参与抢购的可能性；
前端抢购页面设定一个抢购等待时间，用户每次抢购之后必须等待一定时间才能再次发起请求，避免用户利用按键精灵等工具频繁点击按钮；
后端抢购接口对单个用户的访问频率做限制，若超过一定频次则删除服务器端的用户登录记录，需要用户重新登录才能再次发起抢购；
利用redis分布式锁来保证数据的一致性，代替传统的事务控制，以减少数据库链接的浪费；对单个商品的抢购事件加乐观锁，每次抢购商品都需要先获取锁，若获取失败则直接返回结果给用户；
某用户抢购某商品成功后，直接返回成功结果，再通过kafka消息队列异步进行后续的数据写入和短信通知处理，将逻辑判断与数据写入模块解耦；
对于常用且不常更新的热资源，如活动介绍等数据，存储在服务器本地缓存；对图片、样式文件等静态资源，使用cdn进行服务分发，避免对业务服务器的直接访问。
为了更加特定地强调实施的独立性，本说明书涉及许多模块或单元。举例而言，模块或单元可由硬件电路实现，该硬件电路包括特制vlsi电路或门阵列，比如逻辑芯片、晶体管，或其它组件。模块或单元也可在可编程的硬设备中实现，比如场效可编程门阵列、可编程阵列逻辑、可编程逻辑设备等等。
模块或单元也可在藉由各种形式的处理器所执行的软件中实现。比如说，一可执行码模块可包括一个或多个实体的或逻辑的计算机指令区块，该区块可能形成为，比如说，对象、程序或函数。然而，鉴别模块或单元的可执行部分不需要物理上放置在一起，但可由存于不同位置的不同指令所组成，当逻辑上组合在一起时，形成模块或单元且达到该模块或单元所要求的目的。
实际上，可执行码模块或单元可以是一单一指令或多个指令，甚至可以分布在位于不同的程序的数个不同的码区段，并且横跨数个存储设备。同样地，操作数据可被辨识及显示于此模块或单元中，并且可以以任何合适的形式实施且在任何合适的数据结构形式内组织。操作数据可以集合成单一数据集，或可分布在具有不同的存储设备的不同的位置，且至少部分地只以电子信号方式存在于一系统或网络。
本说明书所提及的“实施例”或类似用语表示与实施例有关的特性、结构或特征，包括在本发明的至少一实施例中。因此，本说明书所出现的用语“在一实施例中”、“在实施例中”以及类似用语可能但不必然都指向相同实施例。
再者，本发明所述特性、结构或特征可以以任何方式结合在一个或多个实施例中。以下说明将提供许多特定的细节，比如编程序、软件模块、用户选择、网络交易、数据库查询、数据库结构、硬件模块、硬件电路、硬件芯片等例子，以提供对本发明实施例的了解。然而相关领域的普通技术人员将看出本发明，即使没有利用其中一个或多个特定细节，或利用其它方法、组件、材料等亦可实施。另一方面，为避免混淆本发明，公知的结构、材料或操作并没有详细描述。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。