泥瓦匠：秒殺架構設計實踐思路（一）

摘要: 原創出處 https://www.bysocket.com 「公衆號：泥瓦匠BYSocket 」歡迎關注和轉載，保留摘要，謝謝！

本文內容
- 秒殺業務難點
- 秒殺架構理論
- 業務設計 & 總結

摘錄：生命輪迴。事業、家庭乃至作的每件事都會有生命週期。與其想着什麼時候 Ending，不如腳踏實地，思考將來，活在當下。

From 小弟泥瓦匠思考錄

1、前言

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

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

2、秒殺業務難點

秒殺業務難點，總結爲兩點
- 併發多讀
- 併發少寫

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

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

併發少寫，少用戶併發寫一個數據。好比一塊兒搶，如何限流，由於只有少許寫請求操做數據層？只有一我的才能搶到，如何解決超賣問題？

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

3、秒殺架構理論

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

秒殺的一些架構理論（我認爲的）：
- 高併發原則
- 高可用原則
- 一致性設計

a、高併發原則

一、服務化

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

二、緩存

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

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

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

三、拆分

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

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

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

四、併發化

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

b、高可用原則

一、降級

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

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

二、限流

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

三、可回滾

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

4、業務設計 & 總結

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

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

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

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

資料： 開濤《億量級流量網站架構設計》

  （關注微信公衆號，領取 Java 精選乾貨學習資料）