業務特點：
1、瞬時併發量大，秒殺時會有大量使用者在同一時間進行搶購，瞬時併發訪問量突增幾倍、甚至幾十倍以上
2、庫存量少，一般秒殺活動商品量很少，這就導致了只有極少量使用者能成功購買到。
3、業務和流程較為簡單，一般都是下訂單、扣庫存、支付訂單。

技術難點：
1、若秒殺活動若與其他營銷活動同時進行，可能會對其他活動造成衝擊，極端情況下可能導致整個服務宕機。
2、頁面流量突增，秒殺活動使用者訪問量會突增。需確保訪問量的突增不會對伺服器、資料庫、Redis等造成過大的壓力。
3、秒殺活動庫存量小，瞬時下單量大，易造成超賣現象

架構設計思想
1、限流：由於庫存量很少，對應的只有少部分使用者才能秒殺成功。所以要限制大部分使用者流量，只准少量使用者流量進入後端伺服器。
 
2、削峰：秒殺開始瞬間，大量使用者進來會有一個瞬間流量峰值。把瞬間峰值變得更平緩是設計好秒殺系統關鍵因素。一般的採用快取和MQ實現流量的削峰填谷。
3、非同步：秒殺可以當做高併發系統處理。即可以從業務上考慮，將同步的業務，設計成非同步處理的任務。
4、快取：秒殺瓶頸主要體現在下單、扣庫存的資料操作中。關係型資料庫寫入和讀取效率較低。若將部分操作放到快取中能極大提高併發效率(如使用Redis操作庫存)

整體架構

一、客戶端優化
1、秒殺頁面：
如果秒殺頁面的資源，如：CSS、JS、圖片、商品詳情等都經後端，服務肯定承受不住。如果將這個頁面進行靜態化，秒殺時肯定能起到壓力分散的作用。
2、防止提前下單：
使用JS控制提交訂單按鈕，如果秒殺時間，就不能點選該按鈕。

二、服務端優化
 
1、對查詢秒殺商品進行優化
將首次查詢到的商品資訊進行資料放入快取，後面再訪問時直接返回快取的資訊。
2、對庫存的優化
在設定秒殺活動時就將商品庫存放於Redis中，在下單扣庫存時，直接對Redis進行操作。
3、後端流量控制優化（參加使用者量過大時）
使用訊息佇列、非同步處理等方式解決。即超過系統水位線的請求直接拒絕掉。

核心思想：
1、層層過濾，逐漸遞減瞬時訪問，降低下游的壓力，減少最終對資料庫的衝擊
2、充分利用快取與訊息佇列，提高請求處理速度以及削峰填谷的作用