在線搶購系統需求分析報告

1、搶購業務分析前端

1. 搶購業務的特性

(1) 低廉的價格mysql

(2) 大幅推廣react

(3) 瞬間售空nginx

(4) 定時上架,定時結束redis

(5) 併發量高sql

2. 技術挑戰

(1) 對現有業務的衝擊數據庫

(2) 高併發的環境下,數據庫負擔後端

(3) 高併發狀況下網絡的波動緩存

(4) 前端對數據顯示的處理服務器

(5) 產品定時上架的處理

(6) 庫存的「超賣」現象

(7) 秒殺器的應對

2、搶購業務架構原則

1. 儘可能將請求攔截在系統上游

減輕後端數據層,數據讀取的壓力,防止服務器輕易掛掉

2. 讀多寫少,多使用緩存

減小數據庫的讀取次數

3、搶購業務架構設計

1. 總體架構

採用先後端分離的模式,後端只提供數據的操做,不負責前端頁面的處理。採用RESTful API爲前端提供數據,或者修改數據。前端採用react技術開發SPA單頁應用,分離先後端,解耦系統,提升系統的穩定性和健壯性。採用nginx做爲前端也後端交接的中轉站,實現代理和負載均衡,減輕後臺的請求靜態資源,提升系統總體的穩定性。

2. 前端層架構

(1) 採用nginx和CDN作反向代理,快速響應來自於全國各地的請求,從而解決網絡帶寬的瓶頸。

(2) 倒計時的問題,因爲客服端時間和服務器時間不一致,會致使搶購失敗或者提早搶購。因此採用每隔一段時間,進行先後端時鐘的同步。

(3) 當時間未到的時候,前端進行請求的攔截,採用節流的方式禁止前端在未開始時發送無效的請求。

3. 後端架構

(1) 在請購的API接口,實現一個搶購隊列,放在「插隊」行爲。

(2) 採用mysql進行數據的存儲,採用redis進行數據的緩存,在搶購開始的時,從mysql數據庫中讀取一次數據,把讀取到的商品信息保存在redis緩存中,當每次執行搶購的時,從redis中讀取商品信息,並修改相應庫存,減輕mysql數據庫的頻繁讀寫。

(3) 在搶購成功過之後,若是用戶在20分鐘以內爲付款則,商品從新進入搶購隊列中進行搶購。

4、業務邏輯

 

  1. 流程圖Step1:先通過Nginx負載均衡和分流
  2. 進入jseckill程序處理。 Google guava RateLimiter限流。 併發量大的時候,直接捨棄掉部分用戶的請求
  3. Redis判斷是否秒殺過。避免重複秒殺。若是沒有秒殺過 
    把用戶名(這裏是手機號)和seckillId封裝成一條消息發送到RabbitMQ,請求變成被順序串行處理 
    當即返回狀態「排隊中」到客戶端上,客戶端上回顯示「排隊中...」
  4. 後臺監聽RabbitMQ裏消息,每次取一條消息,並解析後,請求Redis作庫存減1操做(decr命令) 
    並手動ACK隊列 若是減庫存成功,則在Redis裏記錄下庫存成功的用戶手機號userPhone.
  5. 流程圖Step2:客戶端排隊成功後,定時請求後臺查詢是否秒殺成功,後面會去查詢Redis是否秒殺成功
    若是搶購成功,或者搶購失敗則中止定時查詢, 若是是排隊中,則繼續定時查詢。

 

5、ER圖

 

 

6、用例圖

添加搶購商品流程:

 

 

前端搶購流程

 

 

後端處理數據流程

 

 

7、架構圖

 

相關文章
相關標籤/搜索