1. 程式人生 > >描述一個高效能高可靠的伺服器架構---------如何設計一個秒殺系統

描述一個高效能高可靠的伺服器架構---------如何設計一個秒殺系統

一、秒殺的應用場景

電商網站的搶購活動、12306網站的搶票、搶紅包。

二、秒殺的特點

1、秒殺時大量使用者會在同一時間同時進行搶購,網站瞬時訪問流量激增。
2、資料庫的併發讀寫衝突以及資源的鎖請求衝突非常嚴重。
3、秒殺一般是訪問請求數量遠遠大於庫存數量,只有少部分使用者能夠秒殺成功。

三、秒殺架構的原則

1、將請求攔截在系統上游,降低下游壓力:秒殺系統特點是併發量極大,請求都壓倒了後端資料層,但實際秒殺成功的請求數量卻很少。所以如果不在前端攔截很可能造成資料庫讀寫鎖衝突嚴重,併發高響應慢,甚至導致死鎖,最終請求超時。流量雖大,下單成功的有效流量甚小。
2、利用快取:利用快取可極大提高系統讀寫速度。
3、訊息佇列:訊息佇列可以削峰,將攔截大量併發請求,後臺業務根據自己的處理能力從訊息佇列中主動拉取請求訊息進行業務處理。

四、秒殺的系統架構

瀏覽器端(秒殺頁面)→ 站點層(閘道器)→ 服務層 → 資料庫層

這裡寫圖片描述

五、秒殺架構的設計

秒殺系統基於如下原則進行資料分層校驗:
這裡寫圖片描述
1、先做資料的動靜分離;
2、將90%的資料快取在客戶端瀏覽器;
3、將動態請求的讀資料Cache在Web端;
4、對讀資料不做強一致性校驗;
5、對寫資料進行基於時間的合理分片;
6、對寫請求做限流保護;
7、對寫資料進行強一致性校驗。
也就是:
1、把大量靜態不需要檢驗的資料放在離使用者最近的地方;
2、在前端讀系統中檢驗一些基本資訊,如使用者是否具有秒殺資格、商品狀態是否正常秒殺是否已經結束等;
3、在寫資料系統中再校驗一些如是否是非法請求,營銷等價物是否充足(淘金幣等),寫的資料一致性如檢查庫存是否還有等;
4、最後在資料庫層保證資料最終準確性,如庫存不能減為負數。

六、優化細節

1、秒殺系統獨立部署
將秒殺系統獨立部署為叢集模式,可以避免短時間內的大訪問量對現有網站業務造成的衝擊,如果需要還可以使用獨立域名,使其與網站完全隔離。這樣即使秒殺系統崩潰了,也不會對網站造成影響。
2、資料預處理
1)活動頁面,有很多視訊和圖片資源,這些靜態資源提前部署在CDN上。
2)將商品本身的屬性資訊(商品描述、引數、秒殺規則等)這些資料事先儲存到資料庫中,在容器載入服務啟動時,直接載入到本地快取中當作只讀資料,這樣可以加速使用者訪問速度。
3)增加頻寬。
3、前端
1)瀏覽器端
① 禁止重複提交:使用者提交之後按鈕置灰,禁止重複提交;
② 頁面靜態化:將活動頁面上的所有可以靜態的元素(商品描述、引數、詳情等)全部寫到一個靜態頁面,不用進行程式的邏輯處理,不需要訪問資料庫,並儘量減少動態元素。
③ 減少HTTP請求數:主要是合併CSS、JavaScript、圖片等。
④ 使用者限流:在某一時間段內只允許使用者提交一次請求,比如可以採取IP限流。
⑤ 動態生成隨機下單頁面的URL,避免直接下單:秒殺的遊戲規則是到了秒殺才能開始對商品下單購買,在此時間點之前,只能瀏覽資訊不可下單。而下單頁面也是一個普通的URL,如果得到這個URL,不用等到秒殺開始就可以下單了。為了避免使用者直接訪問下單URL,需要將URL動態化,用隨機數作為引數,只能秒殺開始的時候才生成。
2)CDN加速
3)反向代理
4、後端


1)站點層(閘道器層)
針對同一個訪問uid,限制訪問頻率,做頁面快取,幾秒內到達站點層的請求,均返回同一頁面。
2)服務層
利用快取應對讀、寫請求:
大部分請求是查詢請求,可以利用快取分擔資料庫壓力。
對於寫請求,可以把資料庫中的庫存資料轉移到Redis快取中,所有減庫存操作都在Redis中進行,然後再通過後臺程序把redis中的使用者秒殺請求同步到資料庫中。可以採用Redis的list資料結構,把每個商品作為key,把使用者id作為value,佇列的長度就是庫存數量。對於每個使用者的秒殺,使用 RPUSH key value插入秒殺請求, 當插入的秒殺請求數達到上限時,停止所有後續插入。然後根據先進先出,使用 LPOP key zhuge讀取秒殺成功者的使用者id,再操作資料庫做最終的下訂單減庫存操作。
② 非同步操作,使用訊息佇列:把請求寫到訊息佇列中,資料庫層訂閱訊息減庫存,減庫存成功的請求返回秒殺成功,失敗的返回秒殺結束。
③ 使用叢集:在網站高併發訪問的情況下,使用負載均衡技術為一個應用構建一個由多臺伺服器組成的叢集,將併發訪問請求分發到多臺伺服器上處理。
3)資料庫層
mysql批量入庫提高insert效率。

七、關於超賣

秒殺帶來的問題一個是高併發,另一個就是超賣,售出數量多於庫存數量。解決超賣問題的方案有兩種:
1、採用樂觀鎖,也就是採用帶版本號(Version)更新。
實現的流程為:這個資料所有請求都有資格去修改,但會獲得一個該資料的版本號,只有版本號符合的才能更新成功,其他的返回搶購失敗。
2、嘗試扣減庫存,扣減庫存成功才會進行下單邏輯。
UPDATE table_name SET n=n-1 WHERE n>1;
扣減庫存後進行檢查,保證減完不能等於負數。

八、總結

1、將秒殺系統獨立部署為叢集模式,包括伺服器、資料庫、快取等。
2、頁面內容靜態化,把一些不需要變化的內容寫到靜態頁面,這樣不用請求伺服器、訪問資料庫,減輕伺服器、資料庫的壓力。
3、將一些資料事先儲存到資料庫中,在容器載入服務啟動時,直接載入到本地快取中當作只讀資料,加速使用者訪問速度。
4、增加頻寬,將所有靜態資源部署在CDN上,減輕網站伺服器的壓力。
5、使用redis,提高讀寫速度,分擔資料庫壓力,緩解網站壓力。
6、使用訊息佇列,攔截大量併發請求,後臺非同步處理,減輕伺服器壓力。

[參考資料]
秒殺架構分析與實戰
關於秒殺的系統架構優化思路
秒殺系統優化方案之快取、佇列、鎖設計思路
淘寶大秒系統設計詳解
秒殺核心設計(減庫存部分)-防超賣與高併發
轉自:http://www.cnblogs.com/sunshineliulu/p/7598969.html

相關推薦

描述一個高效能可靠伺服器架構---------如何設計一個系統

一、秒殺的應用場景 電商網站的搶購活動、12306網站的搶票、搶紅包。 二、秒殺的特點 1、秒殺時大量使用者會在同一時間同時進行搶購,網站瞬時訪問流量激增。 2、資料庫的併發讀寫衝突以及資源的鎖請求衝突非常嚴重。 3、秒殺一般是訪問請求數量遠遠大於

高效能併發伺服器架構淺析--多執行緒模式

談到高效能高併發伺服器的設計與開發,很關鍵的一模組就是高效的I/O處理了。 那麼如何高效的處理I/O呢?當然是首推epoll來實現I/O複用了! 首先我們來簡單的瞭解下epoll,有經驗的工程師都知道的。epoll是目前linux作業系統上最強大的事件管理機制,也是linu

一種可用性、高效能實時性的伺服器架構設計

【主要從期貨市場的需求獲取靈感】 一、需求 (一)、高可用性 1、持續執行無間斷 2、單點故障不影響 3、執行期間可監控 4、故障可跟蹤排查 5、失敗恢復無間隔 (二)、高效能 6、負載均衡高並行 (三)、高實時性 7、請求響應低時延 8、變化可主動通知 二、關鍵點分析

一文詳解高效能伺服器架構設計

引言 本文從一個簡單的伺服器架構,通過討論出現的問題,進行一步一步優化,最後進化成高效能分散式伺服器架構。 初始情況:一個典型的伺服器結構 新增資料訪問層DAL,解決超出連線次數的問題 新增快取,減少與資料庫建立連線 即使添加了DAL,但是資料

一個媲美淘寶大系統高效能架構設計思路

小編有話說:本文為純乾貨技術文章,建議先轉發、收藏再觀看。 導論 曾經被問過好多次怎樣實現秒殺系統的問題。昨天

伺服器架構設計,常見問題分析

MMORPG伺服器架構 轉自:http://www.blogjava.net/landon/archive/2012/07/14/383092.html 分析總結的很好,分享下。 一.摘要 1.網路遊戲 MMORPG 整體伺服器框架,包括早期,中

淺談高效能併發應用的架構設計

國人人口基數註定了面向2C架構設計逃不開高效能併發的需求,作為技術負責人(架構師)在這方面的考量是決定應用成功運營的關鍵因素。高效能併發的需求根源在於資料/資料的相關關聯性和集中性,這裡所描述的資源/資料包括但不侷限於: 寬頻資源 靜態資源(圖片、Html、CSS等) 資料庫靜

分散式系統-REDIS(併發、高效能、庫存資料一致、不限語言-設計思路一致)

一、秒殺系統準備 1、首先需要能夠抗住基本請求流量的伺服器環境 2、高可用的redis環境(叢集、主從、資料持久化) ps:如果你的每秒請求只有幾百幾千一個REDIS完全夠用不需要額外操心,另外秒殺功能產品往往會加一個小梗,那就是開始秒殺時使用者需要填寫兌換的賬號才能發起秒殺,這裡根據使用者

專題訓練-視訊點播伺服器架構設計

1.系統設計決策 1.1需求概述 某公司因業務需要,需建設一套視訊監控系統,經過架構設計,視訊監控系統包括視訊收集伺服器、視訊檔案伺服器、視訊點播伺服器、監控客戶端、點播客戶端、播放器、採集伺服器(DVR、DVS)、視訊採集節點(雲臺、攝像頭)。 視訊點播伺服器負責提供點播服務,監控客戶

併發系統架構設計 · 搶購、微信紅包、一元奪寶

秒殺業務在各業務中已然非常流行,這裡我將網際網路行業中的秒殺定義為:在非常短的時間內,將一件商品分成多份進行購買的行為。微信搶紅包、一元奪寶、雙11大促搶購等業務本質上都可視作秒殺業務。而最近大熱的搶紅包的難度在於這是和錢打交道的秒殺場景,對於事務的要求性更高。秒殺業務的

網路遊戲伺服器架構設計

入手 假如,我現在接手一個新專案,我的身份還是主程式。在下屬人員一一到位之前,在和製作人以及主策劃充分溝通後,我需要先獨自思考以下問題: 1、伺服器跑在什麼樣的作業系統環境下? 2、採用哪幾種語言開發?主要是什麼? 3、伺服器和客戶端以什麼樣的介面通訊? 4、採用哪些第三方的類庫? 除了技術背景之外,考慮

大型多人線上遊戲伺服器架構設計

由於大型多人線上遊戲伺服器理論上需要支援無限多的玩家,所以對伺服器端是一個非常大的考驗。伺服器必須是安全的,可維護性高的,可伸縮性高的,可負載均衡的,支援高併發請求的。面對這些需求,我們在設計伺服器的時候就需要慎重考慮,特別是架構的設計,如果前期設計不好,最後面臨的很可能是重

棋牌遊戲伺服器架構設計

一,棋牌類伺服器的特點 1,棋牌類不分割槽不分服 一般來說,棋牌遊戲都是不分割槽不分服的。所以棋牌類伺服器要滿足隨著使用者量的增加而擴充套件的需要。 2,房間模式 即在同一局遊戲中就是在同一個房間中,同一個房間中的人可以接收到其他人的訊息。 3,每個房間的操作必須是

如何設計一個系統——系統架構設計有哪些關鍵點?(持續更新)

最近在閱讀許令波的極客專欄“如何設計一個秒殺系統”,我希望通過做筆記的方式督促自己認真閱讀學到東西,在此同時也能分享一些我從中得到的一些東西。 話說雙11,秒殺系統的知識也能應用到裡面,在平時架構設計中也可運用這篇專欄的知識,這裡有些知識點也是面試的高頻詞,也可以完善對於整

IOCP 實現一個簡單併發伺服器程式

 前言:原始碼使用比較高階的IOCP技術,它能夠有效的為多個客戶端服務,利用IOCP程式設計API,它也提供了一些實際問題的解決辦法,並且提供了一個簡單的帶回復的檔案傳輸的客戶端/伺服器。 1.1 要求: l 文章要求讀者熟悉C++, TCP/IP, 套接字(sock

MMORPG無縫大地圖伺服器架構設計總結

地圖分程序架構和無縫大地圖單程序架構 有的遊戲伺服器,一個程序處理一張或多張地圖上的邏輯,進入到不同程序的地圖,資料須要一個程序間同步的過程。簡單合理的同步做法是,先將資料同步到一個公共伺服器;進入到目標程序後,再從公共伺服器拉取本角色的最新資料。可以參考 http://b

ceph儲存 打造高效能可靠塊儲存系統

塊儲存系統 分散式儲存有出色的效能,可以扛很多故障,能夠輕鬆擴充套件,所以我們使用Ceph構建了高效能、高可靠的塊儲存系統,並使用它支撐公有云和託管雲的雲主機、雲硬碟服務。 由於使用分散式塊儲存系統,避免了複製映象的過程,所以雲主機的建立時間可以縮短到10秒以內,而且雲主機

如何做可用的架構設計

本篇的題目其實比較大,所以在寫的時候,我其實是有些“惶恐”的,怕這篇完成後有標題檔的嫌疑。不過為了將自己過去多年的經歷和最近1年改造架構的想法,做一個階段性總結,還是有必要好好寫一寫的,所以如果寫得不好,大家多包涵,歡迎大家補充。 定義目標 既然我們的目標是做到高可用,那麼我們就有必要先明確清楚高可用的含

《新飛飛》網遊伺服器架構設計

韓服網路拓撲圖:   國服網路拓撲圖:   韓服與國服對比: 韓版架構:一組七類程序,玩家三線連線 韓版優劣:架構複雜,難以查證、跟蹤與除錯,難以上手、維護與培訓,不穩定,效能差,邏輯易混亂,最高僅1500人;優點是同內容下玩家數量可擴充單服最高僅1500人;優點是同

百萬使用者級遊戲伺服器架構設計(二)

登入服的設計 -- 功能需求   正如我們在前面曾討論過的,登入服要實現的功能相當簡單,就是帳號驗證。為了便於描述,我們暫不引入那些討論過的優化手段,先以最簡單的方式實現,另外也將基本以mangos的程式碼作為參考來進行描述。   想象一下帳號驗證的實現方法,最容易