一提到秒殺，都會想到高性能、高並發、高可用、大流量…。在電商體系中，交易系統占據了環節中的半壁江山。比如裏面特別迷人的秒殺系統，那秒殺涉及到什麽架構設計？會涉及到什麽業務？

泥瓦匠自言自語：秒殺這個東西，一篇文章也說不完。我這一篇起個頭，實踐系列還在後面，敬請期待。

二、秒殺業務難點

秒殺業務難點，總結為兩點

• 並發多讀
• 並發少寫

這不同於一些場景，優惠營銷系統，只會是一個用戶讀多個數據，但也會大流量的讀操作。但沒有啥寫操作。

並發多讀，多用戶並發讀一個數據。比如華為手機只有一個庫存，活動秒殺。那可能幾千萬的人一起搶這個庫存數據。還不包含很多肉機在狂刷。很多用戶都在讀一個商品 + 這個商品庫存的數據。

並發少寫，少用戶並發寫一個數據。比如一起搶，如何限流，因為只有少量寫請求操作數據層？只有一個人才能搶到，如何解決超賣問題？

例如，12306 搶票，搶紅包啥，瞬間流量更大。那這種系統更加難設計

三、秒殺架構理論

想起了架構一些定律：墨菲定律、康威定律等。任何的設計實踐肯定來自某些理論和定律。

秒殺的一些架構理論（我認為的）：

• 高並發原則
  • 高可用原則
  • 一致性設計

a、高並發原則

1、服務化

服務化老生常談，選型也有 Spring Cloud 、阿裏開源的 Dubbo 等一整套服務化解決方案。考慮服務隔離、限流、超時、重試、補償等

2、緩存

層層考慮。常見的考慮三層：用戶層、應用層、數據層等。

用戶層：DNS 緩存、APP 緩存（圖片等）
應用層：靜態化頁面、MQ、Redis 等
數據層：NoSQL、MySQL 自帶 Query Cache

思考：緩存不是萬能的，肯定是優化各種請求數據、請求節點、請求依賴等

3、拆分

分久必合、合久必分。各種拆分：

• 系統維度：根據業務模塊。如電商系統中的交易系統、商品系統等
• 功能維度：根據功能模塊。如交易系統中的下單系統、退款系統等
• 讀寫維度：根據讀寫比例。如商品系統中的商品寫服務和商品讀服務等
• 模塊維度：根據代碼特征。如分庫分表、項目 moudle、代碼分三層架構等

思考：就想 MyCat 等分庫分表組件，天然支持了讀寫分離…

file
4、並發化

串行換並行。具體實踐，具體場景分析然後優化。

b、高可用原則

1、降級

用於服務依賴隔離、fallback降級，防止雪崩效應。具體選型：hystrix 等

另外，可以做配置化，開關服務降級。核心功能保證，次功能優化為異步或屏蔽。例如：雙十一的時候，會關閉某些評價等功能。

2、限流

防止請求***或者超出系統峰值。具體可以參考一些限流算法 Guava 的 RateLimiter。還寫具體手段：惡意流量訪問到 Cache 等

3、可回滾

發布版本失敗或者有線上問題故障，第一時間會退到上一個穩定版本。思考：那一般運維團隊，會有整套的灰度發布、回滾機制。

四、業務設計 & 總結

秒殺業務涉及也得考慮以下幾點（重要的）：

• 冪等
• 防重
• 數據一致性
• 數據動靜分離
• 請求削峰
• 備份

這篇思路整理，起個頭。也就是大致幾個方向：

1. 請求數據盡量少，網絡 IO 越少越好。包括請求數據 + 返回數據；壓縮；數據服務 RT 越少越好，數據連接次數。
2. 訪問路徑盡量越短，節點越少，消耗越少
3. 避免單點故障，要有備份

寫在最後：

既然看到這裏了，覺得筆者寫的還不錯的就點個贊，加個關註唄！點關註，不迷路，持續更新！！！

阿裏P8級架構師淺析秒殺架構設計實踐思路