分布式秒殺系統的設計
前言
不知道你在面試的程序中有沒有被問到如何設計一個分布式秒殺系統?本篇博客根據大神們的梳理的體系并結合自己實際的專案經驗，大致描述我們在設計分布式秒殺系統需要關注的核心內容——分布式鎖、分布式限流、訊息佇列等等，希望可以幫助同學們可以在面試中更加從容地回答這個問題，
正文
分布式秒殺系統的設計
秒殺系統的核心的問題
- 并發讀：核心的優化理念是減少用戶到服務端來“讀”資料，或者讓他們讀更少的資料；
- 并發寫：要求在資料庫層面獨立出一個庫，做特殊處理，可以理解為為秒殺設計專門的表，精簡表欄位，
秒殺系統的的基本要求：
- 高性能:涉及大量并發讀寫，可以從快取、訊息佇列、 請求削峰等角度進行設計
- 一致性:保證秒殺減庫存中的資料一致性，
- 高可用:保證系統的高可用和正確性，設計
PlanB進行兜底，
架構原則（4要1不要）：
- 資料要盡量少：用戶請求與回應的資料盡可能得少，可以減少資料序列化與反序列化的性能損耗；
- 請求數要盡量少：減少或者合并
css/java script、圖片，以及Ajax請求等，TCP三次握手，DNS決議等都會有資源消耗； - 路徑要盡量短：用戶發出請求到回傳資料這個程序中，需求經過的中間的節點數盡可能少，盡可能使用
RPC呼叫，提升系統性能； - 依賴要盡量少：依賴，指的是要完成一次用戶請求必須依賴的系統或者服務；
- 不要有單點：無論是系統資源還是資料資源在設計的時候一定要考慮冗余，
根據上述的，可以設計如下：
秒殺系統的實作：
- 分布式限流：采用
sentinel的方式進行分布式限流，諸如warm up（預熱）、拒絕、勻速排隊等手段； - 負載均衡：對系統進行微服務化，拆分成商品中心、用戶中心、訂單中心；
- 快取的使用：對熱點資料（遵循二八原則）并且對實時性要求不高的資料進行快取處理，如商品的基本資訊；
- 訊息佇列的使用：針對可以異步處理的操作，如下單，采用訊息佇列的方式進行處理， 實行流量削峰；
- 分布式鎖：進行搶購時采用分布式鎖的方式保證不會出現“超賣現象”；
如何防止“超賣”現象
秒殺系統防止的“超賣”的關鍵在于減庫存的方式，通常有三種：
- 下單減庫存：一定不會出現超賣情況，但是有些人下單完不付款會影響其他人，
- 付款減庫款：付款減庫存，可能會因為并發高導致付款時已經賣光，付不了款，
- 預扣庫存：最常用，如下單后扣庫存，保留十分鐘，在十分鐘內未付款就不保留，如果付款時發現庫存不足則不允許付款，
預扣庫存，存在“黃牛搶單”惡意搶單的情況，可以通過信譽積分、設定最大購買數、已有未支付訂單不允許再次下單等方式進行控制，預扣庫存通常使用分布式鎖來實作的，
關于系統的設計中涉及的技術可移步：
-
分布式鎖可參考我的博客：從悲觀鎖、樂觀鎖到分布式鎖
-
負載均衡等分布式知識可參考我的博客：溪源的Java筆記—分布式
-
訊息佇列可參考我的博客：溪源的Java筆記—訊息佇列
-
分布式限流可參考我的博客：高并發之限流演算法
-
springboot實作商品秒殺功能可參考我的博客：springboot實作商品秒殺功能
溪源的奇思妙想
CSDN認證博客專家
Java
Redis
架構
CSDN認證博客專家
Java
Redis
架構
微信公眾號：溪源的奇思妙想 溪源，一個在IT技術圈和經濟學之間的求知者——既對人工智能、物聯網等前沿技術興致勃勃，又對機會成本、邊際收益等經濟學理論流連忘返，人生是一場孤獨的旅行，只是我還是僥幸期待有同路人，我希望認識同樣熱愛技術、迷戀經濟學的你，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/255883.html
標籤：其他