簡單的網購秒殺活動

以前看了《大型網站技術架構·核心原理與案例分析》一書,其中介紹了一些關於網購秒殺系統架構設計相關的知識,碰巧在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的依賴時應該注意版本問題
相關文章
相關標籤/搜索