秒殺系統架構設計-第一章

秒殺系統架構設計

如何更好地理解秒殺系統

從高維度出發，從總體上思考問題。秒殺其實主要解決兩個問題，一個是併發讀，一個是併發寫。

併發讀的核心優化理念是儘可能減小用戶到服務端來讀數據，或者讓他們讀更少的數據；

併發寫的處理原則頁同樣，它要求咱們在數據庫層面獨立出來一個庫，作特殊的處理。

咱們還要針對秒殺系統作一些保護，針對意料以外的狀況設計兜底方案，以防止最壞的狀況發生。

要打造並維護一個超大流量併發讀寫、高性能、高可用的系統，在整個用戶請求路徑上從瀏覽器到服務端咱們要遵循幾個原則，就是要保證用戶請求的數據儘可能少，請求數儘可能少，路徑儘可能端，依賴儘可能少，而且不要有單點。

秒殺的總體架構能夠歸納爲"穩、準、快"幾個關鍵字。

• 穩，就是整個系統架構要知足高可用，流量符合預期時確定要穩定，就是超出預期時也一樣不能掉鏈子，你要保證秒殺活動順利完成，即秒殺商品順利地賣出去，這個時最基本地前提
• 準，就是秒殺10臺iPhone，那就只能成交10臺，多一臺少一臺都不行。保證數據一致性。
• 快，就是說系統地性能要足夠高。不光是服務端要作極致地性能優化，並且在整個請求鏈路上都要作協同地優化，每一個地方快一點，整個系統就完美了。

技術角度地看"穩、準、快"，就對應了咱們架構上地高可用、一致性和高性能地要求。

• 高性能。秒殺涉及大量地併發讀和併發寫，所以支持高併發訪問這個很是關鍵。從設計數據地動靜分離方案、熱點的發現與隔離、請求的削峯與分層過濾、服務端的極致優化這4各方面重點介紹。
• 一致性。如何設計秒殺減庫存方案
• 高可用。從哪些環節來設計兜底方案

架構原則："4要 1不要"

1. 數據要儘可能少

   首先是指用戶請求的數據能少就少。由於這些數據傳輸需喲啊事件，服務器在寫網絡時要作壓縮和字符編碼，很是消耗CPU。其次，系統依賴的數據能少就少，包括系統完成某些業務邏輯須要讀取和保存的數據，調用其餘服務會設計數據的序列化和反序列化，會很是消耗cpu，與數據庫打交道越少越好，數據越簡單，越小則越好。

2. 請求數要儘可能少
3. 路徑要儘可能短

   所謂"路徑"，就是用戶發出請求到返回數據這個過程當中，需求通過的中間節點數。一般，這些節點能夠表示爲一個系統或者一個新的socket連接。每通過一個幾點，通常都會產生一個新的Socket連接。每增長一個連接都會增長新的不肯定性。縮短請求路徑不只能夠增長可用性，一樣能夠有效提高性能（減小數據的序列化與反序列化），並減小延時（能夠減小網絡傳輸耗時）。

   縮短訪問路徑有一種辦法，就是多個相互強依賴的應用合併部署在一塊兒，把遠程過程調用變成JVM內部之間的方法調用。

4. 依賴要儘可能少

   所謂依賴，指的是要完成一次用戶請求必須依賴的系統或者服務，這裏的依賴指的是強依賴。

   舉個例子，好比說你要是展現秒殺頁面，而這個頁面必須強依賴商品信息、用戶信息，還有其餘如優惠券、成交列表等這些對秒殺不是非要不可的信息（弱依賴），這些弱依賴在緊急狀況下就能夠去掉。

   要減小依賴，咱們能夠給系統進行分級，好比0級系統、1級系統、2級系統、3級系統，0級系統若是是最重要的系統，那麼0級系統強依賴的系統也一樣是最重要的系統，以此類推。

   注意，0級系統要儘可能減小對1級系統的強依賴，防止重要的系統被不重要的系統拖垮。例如支付系統是0級系統，而優惠券是1級系統的話，在極端狀況下能夠把優惠券降級，防止支付系統被優惠券這個1級系統給拖垮。

5. 不要有單點

   設計分佈式系統最重要的原則就是"消除單點"。

   如何避免單點，我認爲關鍵點是避免將服務的狀態和機器綁定，即把服務無狀態化，這樣服務就能夠在機器中隨意移動。

不一樣場景下的不一樣架構案例

快速搭建簡單的秒殺系統

商品購買頁面增長一個"定時上架"功能，僅在秒殺開始時才讓用戶看到購買按鈕，當商品的庫存賣完了就結束了。

隨着請求量的加大，這個簡單的架構很快就遇到瓶頸。須要架構改造，包括：

1. 把秒殺系統獨立出來單獨打造一個系統，這樣能夠有針對性地作優化。
2. 系統部署上頁獨立作一個機器集羣，這樣秒殺大流量就不會影響到正常的商品購買集羣的機器負載
3. 將熱點數據（如庫存數據）單獨放到一個緩存系統中，以提升"讀性能"
4. 增長秒殺答題，防止有秒殺器搶單。

改造後的系統架構

當訪問量超百萬的併發，須要進一步提高秒殺系統的性能，進一步升級，好比：

1. 對頁面進行完全的動靜分離，使得用戶秒殺時不須要刷新整個頁面，而只須要點擊秒殺按鈕，藉此把頁面刷新的數據降到最少；
2. 在服務端對秒殺商品進行本地緩存，不須要再調用依賴系統的後臺服務獲取數據，甚至不須要去公共的緩存集羣中查詢數據，這樣不只能夠減小系統調用，並且可以避免壓垮公共緩存集羣。
3. 增長系統限流保護，防止最壞狀況發生。

在這裏，咱們對頁面進行了進一步的靜態化，秒殺過程當中不須要刷新整個頁面，而只須要服務端請求不多的動態數據。並且，最關鍵的詳情和交易系統都增長了本地緩存，來提早緩存秒殺商品的信息，熱點數據庫也作了獨立部署，等等。

每次升級都須要定製不少地方，也就是越"不通用"。例如，秒殺商品緩存在每臺機器的內存中，這種方式顯然不太適合太多商品同時進行秒殺的狀況，由於單機的內存始終有限。因此要取得極致的性能，就要在其餘地方（好比，通用性、易用性、成本等方面）有所犧牲。