一、前言
一提到秒殺，都會想到高效能、高併發、高可用、大流量…。在電商體系中，交易系統佔據了環節中的半壁江山。比如裡面特別迷人的秒殺系統，那秒殺涉及到什麼架構設計？會涉及到什麼業務？
泥瓦匠自言自語：秒殺這個東西，一篇文章也說不完。我這一篇起個頭，實踐系列還在後面，敬請期待。
二、秒殺業務難點
秒殺業務難點，總結為兩點- 併發多讀
- 併發少寫
這不同於一些場景，優惠營銷系統，只會是一個使用者讀多個資料，但也會大流量的讀操作。但沒有啥寫操作。
併發多讀，多使用者併發讀一個資料。比如華為手機只有一個庫存，活動秒殺。那可能幾千萬的人一起搶這個庫存資料。還不包含很多肉機在狂刷。很多使用者都在讀一個商品 + 這個商品庫存的資料。
併發少寫，少使用者併發寫一個資料。比如一起搶，如何限流，因為只有少量寫請求運算元據層？只有一個人才能搶到，如何解決超賣問題？
例如，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、可回滾
釋出版本失敗或者有線上問題故障，第一時間會退到上一個穩定版本。思考：那一般運維團隊，會有整套的灰度釋出、回滾機制。
四、業務設計 & 總結
秒殺業務涉及也得考慮以下幾點（重要的）：
- 冪等
- 防重
- 資料一致性
- 資料動靜分離
- 請求削峰
- 備份
這篇思路整理，起個頭。也就是大致幾個方向：
- 請求資料儘量少，網路 IO 越少越好。包括請求資料 + 返回資料；壓縮；資料服務 RT 越少越好，資料連線次數。
- 訪問路徑儘量越短，節點越少，消耗越少
- 避免單點故障，要有備份
寫在最後：
針對Java架構設計，我這邊給大家整理了一些學習資料和視訊，省的大家再去網上找資料，希望能夠幫助到大家！
資料領取方式：加入粉絲群963944895，點選加入群聊，私信管理員即可
