本文內容
- 秒殺業務難點
- 秒殺架構理論
- 業務設計 & 總結
摘錄：生命輪回。事業、家庭乃至做的每件事都會有生命周期。與其想着何時 Ending，不如腳踏實地，思考未來，活在當下。
From 小弟泥瓦匠思考錄
一、前言
一提到秒殺，都會想到高性能、高並發、高可用、大流量...。在電商體系中，交易系統占據了環節中的半壁江山。比如里面特別迷人的秒殺系統，那秒殺涉及到什么架構設計？會涉及到什么業務？
泥瓦匠自言自語：秒殺這個東西，一篇文章也說不完。我這一篇起個頭，實踐系列還在后面，敬請期待。
二、秒殺業務難點
秒殺業務難點，總結為兩點
- 並發多讀
- 並發少寫
這不同於一些場景，優惠營銷系統，只會是一個用戶讀多個數據，但也會大流量的讀操作。但沒有啥寫操作。
並發多讀，多用戶並發讀一個數據。比如華為手機只有一個庫存，活動秒殺。那可能幾千萬的人一起搶這個庫存數據。還不包含很多肉機在狂刷。很多用戶都在讀一個商品 + 這個商品庫存的數據。
並發少寫，少用戶並發寫一個數據。比如一起搶，如何限流，因為只有少量寫請求操作數據層？只有一個人才能搶到，如何解決超賣問題？
例如，12306 搶票，搶紅包啥，瞬間流量更大。那這種系統更加難設計
三、秒殺架構理論
想起了架構一些定律：墨菲定律、康威定律等。任何的設計實踐肯定來自某些理論和定律。
秒殺的一些架構理論（我認為的）：
- 高並發原則
- 高可用原則
- 一致性設計
a、高並發原則
1、服務化
服務化老生常談，選型也有 Spring Cloud 、阿里開源的 Dubbo 等一整套服務化解決方案。考慮服務隔離、限流、超時、重試、補償等
2、緩存
層層考慮。常見的考慮三層：用戶層、應用層、數據層等。
用戶層：DNS 緩存、APP 緩存（圖片等）
應用層：靜態化頁面、MQ、Redis 等
數據層：NoSQL、MySQL 自帶 Query Cache
思考：緩存不是萬能的，肯定是優化各種請求數據、請求節點、請求依賴等
3、拆分
分久必合、合久必分。各種拆分：
- 系統維度：根據業務模塊。如電商系統中的交易系統、商品系統等
- 功能維度：根據功能模塊。如交易系統中的下單系統、退款系統等
- 讀寫維度：根據讀寫比例。如商品系統中的商品寫服務和商品讀服務等
- 模塊維度：根據代碼特征。如分庫分表、項目 moudle、代碼分三層架構等
思考：就想 MyCat 等分庫分表組件，天然支持了讀寫分離...
4、並發化
串行換並行。具體實踐，具體場景分析然后優化。
b、高可用原則
1、降級
用於服務依賴隔離、fallback降級，防止雪崩效應。具體選型：hystrix 等
另外，可以做配置化，開關服務降級。核心功能保證，次功能優化為異步或屏蔽。例如：雙十一的時候，會關閉某些評價等功能。
2、限流
防止請求攻擊或者超出系統峰值。具體可以參考一些限流算法 Guava 的 RateLimiter。還寫具體手段：惡意流量訪問到 Cache 等
3、可回滾
發布版本失敗或者有線上問題故障，第一時間會退到上一個穩定版本。思考：那一般運維團隊，會有整套的灰度發布、回滾機制。
四、業務設計 & 總結
秒殺業務涉及也得考慮以下幾點（重要的）：
- 冪等
- 防重
- 數據一致性
- 數據動靜分離
- 請求削峰
- 備份
這篇思路整理，起個頭。也就是大致幾個方向：
- 請求數據盡量少，網絡 IO 越少越好。包括請求數據 + 返回數據；壓縮；數據服務 RT 越少越好，數據連接次數。
- 訪問路徑盡量越短，節點越少，消耗越少
- 避免單點故障，要有備份
資料： 開濤《億量級流量網站架構設計》
（關注微信公眾號，領取 Java 精選干貨學習資料）