简单的网购秒杀活动

以前看了《大型网站技术架构·核心原理与案例分析》一书,其中介绍了一些关于网购秒杀系统架构设计相关的知识,碰巧在imooc上也看到了有关的课程。在参考了各方资料以后,我的感受对如何设计一个秒杀系统有了基本的了解,因而打算本身也试着实现一个简单的秒杀系统。本文的秒杀系统虽然是基于Spring MVC+Spring+Mybatis框架实现,可是其中的架构思想以及处理问题的方法是语言无关的。因此使用其余编程语言作开发的同窗也能够看一看。
  本文主要是对秒杀系统架构设计、系统功能等进行介绍,另外提一下编码过程当中遇到的一些坑,具体的编码不过多赘述,代码中都写了详细的注释。建议直接把项目down下来本身边运行边探究。
   项目github地址: https://github.com/eakonzhao/Spike-system ( 喜欢的话记得给个star哦 o(^▽^)o ) 
  怎么把项目运行起来?

  
         

  • git clone https://github.com/eakonzhao/Spike-system   
  • 打开 IDEA --> File --> New --> Open   
  • 打开pom.xml,而后让Maven将所需依赖都加载进来   
  • 将jdbc.properties中的数据库url、用户名和密码改为你本身的   
  • 运行Tomcat   
  • 在浏览器输入 http://localhost:8080/seckill/list  
  秒杀系统架构设计

  1、秒杀活动技术挑战
  
         

  • 对现有业务形成冲击:  
  秒杀活动通常是网站营销的附加活动。秒杀活动的特色是持续时间短、瞬时访问量大的特色,所以在秒杀活动进行期间确定要占用大量的网络带宽以及服务器资源等,若是和网站平常的应用部署在一块儿必然会对现有业务形成冲击,甚至可能会致使宕机时间的发生。在实际生产中,咱们有两种选择:一个是进行适当地服务降级,在秒杀活动进行的过程当中关闭一些相对来讲没有那么重要的服务。例如淘宝最初在应对双11的时候,就会把确认收货以及商品评价等功能关闭,以争取给予秒杀活动尽量多的可用资源;另外一个选择是秒杀系统和现有业务系统分开部署,其实也就是业务分割部署的思想。
  
         

  • 高并发下的应用、数据库负载  
  用户在秒杀开始前经过不断刷新浏览器页面以保证不会错过秒杀,这些请求若是按照通常的网站应用架构,访问服务器、链接数据库、会对应用服务器和数据库服务器形成极大的负载压力。
  
         

  • 忽然增长的网络及服务器带宽  
  秒杀活动时所需的带宽会超过网站平时使用的带宽
  
         

  • 用户未到秒杀时间直接下单  
  秒杀的流程应该是到了秒杀时间才能开始对商品下单购买,在此时间点以前,只能浏览商品信息而不能下单。而下单页面也是能够经过一个普通的URL获取,若是获得这个URL,那么不用等到秒杀开始就能够进行下单了。
  2、秒杀系统的应对策略
  
         

  • 秒杀系统独立部署
       
  • 秒杀商品页面静态化
    从新设计秒杀商品页面,不使用网站原来的商品详情页面,页面内容静态化:将商品描述、商品参数、成交记录和用户评价所有写入一个静态页面,用户请求不须要通过应用服务器的业务逻辑处理,也不须要访问数据库。因此秒杀商品服务不须要部署动态的Web服务器和数据库服务器。
       
  • 租借秒杀网络带宽
       
  • 动态生成随即下单页面URL
    为了不用户直接访问下单页面URL,须要将该URL动态化,即便秒杀系统的开发者也没法在秒杀开始以前访问下单页面的URL。解决办法是在下单页面URL加入由服务器生成的随机数做为参数,在秒杀开始的时候获得。
      
  3、需求分析与系统架构
  下面是秒杀系统的一个基本流程图:
     
<ignore_js_op>
   秒杀系统业务流程
    可是在本系统中,并无实现得那么完善,而是针对一部分方面进行了实践:
     
<ignore_js_op>
   本系统实现的功能
    前端主要流程图
     
<ignore_js_op>
   秒杀系统前端流程图
    后端简化流程图(由于还会涉及到访问Redis缓存等操做)
     
<ignore_js_op>
   后端简化流程图
    在这里特别把其中的事务拿出来讲一下。咱们的事务由两个操做组成,分别是操做两张表,一个操做是更新某张表的数据,另外一个操做是往某张表里面插入数据。其实这里有一个优化的点,就是在业务代码中将插入操做放在更新操做以前。假如插入失败就直接回滚。可是若是把更新操做(即扣库存)放在前面,在并发的环境下可能会涉及高频率的行级锁竞争问题,致使系统性能急剧降低。(由数据库的三级封锁协议可知这样确实起到了必定的优化做用)
     
<ignore_js_op>
   从用户角度针对库存业务进行分析
      
<ignore_js_op>
   事务详情
      
<ignore_js_op>
   两张主要的数据表(Github已经放了建表的sql语句)
    系统功能介绍

  因为上面已经给出了系统的详细流程图,因此在这里就只展现几张系统的截图
     
<ignore_js_op>
   秒杀商品列表页
      
<ignore_js_op>
   秒杀待开启
      
<ignore_js_op>
   进入秒杀页面,能够开始秒杀
      
<ignore_js_op>
   因为库存为零,点击以后显示秒杀结束
      
<ignore_js_op>
   重复秒杀
    实现

  项目整体描述

  本项目是基于
  项目中应用到的技术与工具

  
         

  • IDEA   
  • MySQL   
  • Spring MVC   
  • Spring   
  • Mybatis   
  • Redis(用户缓存部分商品信息)   
  • Maven   
  • protostuff(用于序列化对象,性能会比jdk自带的序列化好) 
    ........ 
    其实还用到了一些技术,这里就不一一给出了。因为本项目采用Maven进行管理,因此在pom.xml文件里面都给出了所需的依赖。  
  项目骨架展现

     
<ignore_js_op>
   项目骨架展现
    遇到的一些坑

  
         

  • Spring MVC配置出错 
             
    <ignore_js_op>
         通配符很全面,但没法找到元素...
                
    <ignore_js_op>
         ApplicationContext.xml的头要配置正确
       
  • Spring MVC参数绑定错误 
    调试的时候打开浏览器控制台看到报了个400错误,后来检查以后发现原来是Spring MVC的参数绑定出错了,使用@pathVariable的时候要注意  
     
<ignore_js_op>
   控制台出现400错误
      
<ignore_js_op>
   400 Bad Request]D@`NG8JS2.png
      
<ignore_js_op>
   正确的@PathVariable语法 @PathVariable("parameter")
   
         

  • logback和slf4j整合出错致使没法正常打印日志信息
             
    <ignore_js_op>
         logback报错信息
         在查看了官方手册以后发现原来logback和slf4j在整合的过程当中应该注意版本的问题
             
    <ignore_js_op>
         Logback-classic version 1.1.4 and later require slf4j-api version 1.7.15 or later.
      
     
<ignore_js_op>
   在pom.xml引入slf4j和logback的依赖时应该注意版本问题
相关文章
相关标签/搜索