一种高并发秒杀系统的制作方法

1.本发明涉及云计算技术领域，尤其涉及一种高并发秒杀系统。


背景技术：

2.在云计算时代，越来越多的商品交易在线上进行，因此现在线上出现越来越多的平台。这些平台为了吸引用户，往往会选择一些产品进行秒杀促销，此时有可能因为价格便宜，导致用户量增多，并发量大，也有可能是黄牛在大量刷单。
3.申请号为cn201310616248.6，名称为一种互联网高并发秒杀系统的中国发明专利公开了一种互联网高并发秒杀系统，该秒杀系统是通过添加队列锁的方式来实现。该专利虽然能保证秒杀系统的稳定性，但没有验证用户的请求，判断是正常用户还是存在刷单的行为，无法保证用户良好的秒杀体验。因此，急需一种保证系统稳定，防止商品超卖，保证不被刷单，保证客户体验的秒杀系统。


技术实现要素：

4.为了克服现有技术的不足，本发明的目的在于提供一种高并发秒杀系统，解决了秒杀系统在短时间并发量大的情况下，能正常访问以及秒杀产品，不会超卖并且防刷单的问题。
5.本发明提供一种高并发秒杀系统，包括前端页面层、服务器、服务层、数据库、系统防刷层；其中，
6.所述前端页面层用于将秒杀系统的页面静态化，将秒杀按钮的触发状态根据秒杀开始时间和用户点击次数进行设置；
7.所述服务器利用web服务器做负载，限制总的并发数以及控制每个ip的访问频率；
8.所述服务层用于将秒杀的库存数量设置到缓存服务器，当接收到用户的秒杀请求时，进行库存扣减；若下单失败，则库存数量加1；将下单请求设置到消息队列中再进行下单；
9.所述数据库用于通过当前库存的字段减1再赋值直接对库存进行更新；
10.所述系统防刷层用于将用户的参与记录写入缓存服务器，通过缓存服务器锁住用户账号，根据用户账号的状态进行防刷操作；在所述服务器中限制每个ip的访问频率；在服务层根据ip的请求频率进行防刷操作；根据用户账号是否连号进行防刷操作。
11.进一步地，所述前端页面层将商品的图片、描述、评价以及成交数信息写入静态页面，将所述静态页面存放至内容分发网络，加速用户的访问；在秒杀页面中，在秒杀还未开始时，将秒杀按钮设置为不可点击状态；在秒杀开始时，将秒杀按钮设置为可点击状态，响应过用户点击秒杀按钮的请求后，将秒杀按钮重新设置为不可点击状态。
12.进一步地，所述前端页面层中秒杀按钮的触发通过javascript脚本进行控制。
13.进一步地，所述服务器利用nginx做负载，判断并发数是否超过并发数阈值，是则丢弃请求，否则判断ip的访问频率是否超过ip的访问频率阈值，是则丢弃请求，否则分发至
应用服务。
14.进一步地，所述服务层将秒杀的库存数量设置到redis中，当接收到用户的秒杀请求时，采用redis的decr命令进行库存扣减，若返回值大于等于0，则扣减库存成功，继续后续操作，若返回值小于0，则扣减库存失败，返回已售磐。
15.进一步地，所述服务层将下单请求设置到rocketmq中再进行下单，若下单成功，则通过短信的方式通知用户秒杀成功，若下单失败，则通过补偿机制重试。
16.进一步地，所述数据库采用乐观锁机制，判断库存是否还有剩余数量，否则返回，是则获取数据库版本号，更新库存数量，判断数据库更新的版本号与当前的版本号加1是否符合，是则更新库存数量，否则回滚操作。
17.进一步地，所述系统防刷层用于将用户的参与记录写入redis，通过redis实现分布式锁，将分布式锁按用户账号锁住，判断所述用户账号是否已持有分布式锁，是则丢弃请求，否则判断所述用户账号是否有参与记录，是则丢弃请求，否则进行后续操作。
18.进一步地，所述系统防刷层在nginx中限制每个ip的访问频率；在服务层判断ip的请求频率是否达到阈值，是则弹出验证码验证输入页面，或直接禁止该请求ip。
19.进一步地，所述系统防刷层还用于设置验证码或者回答问题进行防刷操作。
20.相比现有技术，本发明的有益效果在于：
21.本发明使用了分布式架构，将各个服务进行拆分，分别进行调用，也采用了mq异步下单的原理，削峰，解耦，支撑高并发；不止在服务层使用了redis对库存进行原子性校验，也在数据库层，使用乐观锁的机制，保证最终库存不会被超卖；分别利用了技术手段以及业务手段，解决了单一账号多次请求、多账号单一ip的多次请求，和多账号多ip多次请求的刷单行为。
22.上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。本发明的具体实施方式由以下实施例及其附图详细给出。
附图说明
23.此处所说明的附图用来提供对本发明的进一步理解，构成本技术的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
24.图1为本发明的秒杀业务流程设计图；
25.图2为本发明的前端静态化页面流程图；
26.图3为本发明的秒杀流程图；
27.图4为本发明的高并发秒杀系统架构图。
具体实施方式
28.下面，结合附图以及具体实施方式，对本发明做进一步描述，需要说明的是，在不相冲突的前提下，以下描述的各实施例之间或各技术特征之间可以任意组合形成新的实施例。
29.一种高并发秒杀系统，如图1、图3、图4所示，包括前端页面层、服务器、服务层、数据库、系统防刷层；其中，
30.如图2所示，前端页面层将一些请求控制在前端完成或者做第一层限制，减少服务器压力。主要用于将秒杀系统的页面静态化，即将商品的图片、描述、评价以及成交数等信息写入静态页面，将静态页面存放至内容分发网络cdn，可以加速用户的访问，不用每次都通过请求从数据库读数据，最大可能的减少服务器的压力。
31.前端页面层将秒杀按钮的触发状态根据秒杀开始时间和用户点击次数进行设置。具体地，在秒杀页面中，在秒杀还未开始时，将秒杀按钮设置为不可点击状态，如控制秒杀页面的秒杀按钮为灰色的不可点击状态；在秒杀开始时，将秒杀按钮设置为可点击状态，如控制秒杀页面的秒杀按钮为高亮可点击状态。由于上一步已将秒杀页面生成静态页面，因此不能从服务端获得响应，只能通过javascript脚本进行控制。
32.前端页面层响应过用户点击秒杀按钮的请求后，将秒杀按钮重新设置为不可点击状态。即在秒杀开始时，用户点击完秒杀按钮后，重新将秒杀按钮置设置为灰色的不可点击状态，防止用户重复提交请求，限制用户在预设时间内只能提交一次请求。
33.服务器利用web服务器做负载，限制总的并发数以及控制每个ip的访问频率。因为nginx的并发能力能达到几万，tomcat(应用服务器)只有几百，远远比tomcat高，因此服务器利用高性能的web服务器nginx做负载，在nginx也可以做服务器层的限流，限制总的并发数以及控制每个ip的访问频率。具体地，判断并发数是否超过并发数阈值，是则丢弃请求，否则判断ip的访问频率是否超过ip的访问频率阈值，是则丢弃请求，否则分发至应用服务。
34.将秒杀的相关逻辑都在服务层实现。服务层主要用于将秒杀的库存数量设置到缓存服务器redis，从内存中读取数据，响应快。当接收到用户的秒杀请求时，通过了上一步的访问限制，采用redis的decr命令进行库存扣减，因为decr是原子性操作，可以避免分布式环境的并发问题，最后判断返回值，若返回值大于等于0，则说明扣减库存成功，继续后续操作，若返回值小于0，则扣减库存失败，返回已售磐。此时要注意，若下单失败，则redis库存数量加1，保证redis的库存数量与数据库的库存数量一致。
35.经过上述一系列的限制以及请求后，留下来的请求都是有效请求，此时可以进行下单，下单时不是直接操作库表进行下单，而是采用rocketmq队列进行异步下单。将下单请求设置到消息队列中再进行下单，若下单成功，则通过短信的方式通知用户秒杀成功，若下单失败，则通过补偿机制重试。
36.最终的下单数据存储在数据库，因此除了在服务层进行控制，为了防止超卖，还需要在数据库层面做控制。通常在进行库存扣减时，都是先查询出库存，再对库存进行减1的更新操作。本实施例在更新时抛弃传统的做法，直接对库存进行更新，对库存的设置是用当前库存的字段减1再赋值。
37.数据库采用乐观锁机制，判断库存是否还有剩余数量，否则返回，是则获取数据库版本号，更新库存数量，判断数据库更新的版本号与当前的版本号加1是否符合，是则更新库存数量，否则回滚操作。
38.秒杀时会收到海量的请求，但这其中可能存在很大一部分请求是黄牛党觉得有利可图，使用“刷票工具”等将他们的请求尽可能多的发送到服务器。此时防刷显得极为重要。
39.同一个账号多次请求：使用自己的账号，发送多次请求。这种情况，在向服务器请求查询用户是否参与过时，在某个请求成功写入的时间差内，可能返回的结果是未参与过的，从而绕过了是否参与过的校验。本实施例将用户的参与记录写入redis，通过redis实现
分布式锁，将分布式锁按用户账号锁住，判断用户账号是否已持有分布式锁，是则丢弃请求，否则判断用户账号是否有参与记录，是则丢弃请求，否则进行后续操作。
40.多个账号相同ip的多次请求：请购者可能采用一堆“僵尸号”，发送多次请求。本实施例中，在nginx中限制每个ip的访问频率，也可以在服务层判断ip的请求频率，当ip的请求频率达到阈值时，直接弹出验证码验证输入，也可以直接禁止该请求ip。
41.多个账号不同ip发送的多次请求：有些用户会使用多个账号，利用代理多个ip或者控制其他电脑来发送多次请求。这种情况不太好分辨，只能通过判断用户账号是否连号来过滤掉一部分“僵尸号”，以及通过验证码或者回答问题来设置相应的门槛，提高安全级别。
42.以上，仅为本发明的较佳实施例而已，并非对本发明作任何形式上的限制；凡本行业的普通技术人员均可按说明书附图所示和以上而顺畅地实施本发明；但是,凡熟悉本专业的技术人员在不脱离本发明技术方案范围内，利用以上所揭示的技术内容而做出的些许更动、修饰与演变的等同变化，均为本发明的等效实施例；同时,凡依据本发明的实质技术对以上实施例所作的任何等同变化的更动、修饰与演变等，均仍属于本发明的技术方案的保护范围之内。