Java 高併發解決方案（電商的秒殺和搶購）

電商的秒殺和搶購，對咱們來講，都不是一個陌生的東西。然而，從技術的角度來講，這對於Web系統是一個巨大的考驗。當一個Web系統，在一秒鐘內收到數以萬計甚至更多請求時，系統的優化和穩定相當重要。此次咱們會關注秒殺和搶購的技術實現和優化，同時，從技術層面揭開，爲何咱們老是不容易搶到火車票的緣由？ 

1、大規模併發帶來的挑戰 

在過去的工做中，我曾經面對過5w每秒的高併發秒殺功能，在這個過程當中，整個Web系統遇到了不少的問題和挑戰。若是Web系統不作針對性的優化，會垂手可得地陷入到異常狀態。咱們如今一塊兒來討論下，優化的思路和方法哈。 

1. 請求接口的合理設計

一個秒殺或者搶購頁面，一般分爲2個部分，一個是靜態的HTML等內容，另外一個就是參與秒殺的Web後臺請求接口。

一般靜態HTML等內容，是經過CDN的部署，通常壓力不大，核心瓶頸實際上在後臺請求接口上。這個後端接口，必須可以支持高併發請求，同時，很是重要的一點，必須儘量「快」，在最短的時間裏返回用戶的請求結果。爲了實現儘量快這一點，接口的後端存儲使用內存級別的操做會更好一點。仍然直接面向MySQL之類的存儲是不合適的，若是有這種複雜業務的需求，都建議採用異步寫入。

固然，也有一些秒殺和搶購採用「滯後反饋」，就是說秒殺當下不知道結果，一段時間後才能夠從頁面中看到用戶是否秒殺成功。可是，這種屬於「偷懶」行爲，同時給用戶的體驗也很差，容易被用戶認爲是「暗箱操做」。

2. 高併發的挑戰：必定要「快」

咱們一般衡量一個Web系統的吞吐率的指標是QPS（Query Per Second，每秒處理請求數），解決每秒數萬次的高併發場景，這個指標很是關鍵。舉個例子，咱們假設處理一個業務請求平均響應時間爲100ms，同時，系統內有20臺Apache的Web服務器，配置MaxClients爲500個（表示Apache的最大鏈接數目）。

那麼，咱們的Web系統的理論峯值QPS爲（理想化的計算方式）：

20*500/0.1 = 100000 （10萬QPS）

咦？咱們的系統彷佛很強大，1秒鐘能夠處理完10萬的請求，5w/s的秒殺彷佛是「紙老虎」哈。實際狀況，固然沒有這麼理想。在高併發的實際場景下，機器都處於高負載的狀態，在這個時候平均響應時間會被大大增長。

就Web服務器而言，Apache打開了越多的鏈接進程，CPU須要處理的上下文切換也越多，額外增長了CPU的消耗，而後就直接致使平均響應時間增長。所以上述的MaxClient數目，要根據CPU、內存等硬件因素綜合考慮，絕對不是越多越好。能夠經過Apache自帶的abench來測試一下，取一個合適的值。而後，咱們選擇內存操做級別的存儲的Redis，在高併發的狀態下，存儲的響應時間相當重要。網絡帶寬雖然也是一個因素，不過，這種請求數據包通常比較小，通常不多成爲請求的瓶頸。負載均衡成爲系統瓶頸的狀況比較少，在這裏不作討論哈。

那麼問題來了，假設咱們的系統，在5w/s的高併發狀態下，平均響應時間從100ms變爲250ms（實際狀況，甚至更多）：

20*500/0.25 = 40000 （4萬QPS）

因而，咱們的系統剩下了4w的QPS，面對5w每秒的請求，中間相差了1w。

而後，這纔是真正的惡夢開始。舉個例子，高速路口，1秒鐘來5部車，每秒經過5部車，高速路口運做正常。忽然，這個路口1秒鐘只能經過4部車，車流量仍然依舊，結果一定出現大塞車。（5條車道突然變成4條車道的感受）

同理，某一個秒內，20*500個可用鏈接進程都在滿負荷工做中，卻仍然有1萬個新來請求，沒有鏈接進程可用，系統陷入到異常狀態也是預期以內。

其實在正常的非高併發的業務場景中，也有相似的狀況出現，某個業務請求接口出現問題，響應時間極慢，將整個Web請求響應時間拉得很長，逐漸將Web服務器的可用鏈接數佔滿，其餘正常的業務請求，無鏈接進程可用。

更可怕的問題是，是用戶的行爲特色，系統越是不可用，用戶的點擊越頻繁，惡性循環最終致使「雪崩」（其中一臺Web機器掛了，致使流量分散到其餘正常工做的機器上，再致使正常的機器也掛，而後惡性循環），將整個Web系統拖垮。

3. 重啓與過載保護

若是系統發生「雪崩」，貿然重啓服務，是沒法解決問題的。最多見的現象是，啓動起來後，馬上掛掉。這個時候，最好在入口層將流量拒絕，而後再將重啓。若是是redis/memcache這種服務也掛了，重啓的時候須要注意「預熱」，而且極可能須要比較長的時間。

秒殺和搶購的場景，流量每每是超乎咱們系統的準備和想象的。這個時候，過載保護是必要的。若是檢測到系統滿負載狀態，拒絕請求也是一種保護措施。在前端設置過濾是最簡單的方式，可是，這種作法是被用戶「千夫所指」的行爲。更合適一點的是，將過載保護設置在CGI入口層，快速將客戶的直接請求返回。

2、做弊的手段：進攻與防守

秒殺和搶購收到了「海量」的請求，實際上裏面的水分是很大的。很多用戶，爲了「搶「到商品，會使用「刷票工具」等類型的輔助工具，幫助他們發送儘量多的請求到服務器。還有一部分高級用戶，製做強大的自動請求腳本。這種作法的理由也很簡單，就是在參與秒殺和搶購的請求中，本身的請求數目佔比越多，成功的機率越高。

這些都是屬於「做弊的手段」，不過，有「進攻」就有「防守」，這是一場沒有硝煙的戰鬥哈。

1. 同一個帳號，一次性發出多個請求

部分用戶經過瀏覽器的插件或者其餘工具，在秒殺開始的時間裏，以本身的帳號，一次發送上百甚至更多的請求。實際上，這樣的用戶破壞了秒殺和搶購的公平性。

這種請求在某些沒有作數據安全處理的系統裏，也可能形成另一種破壞，致使某些判斷條件被繞過。例如一個簡單的領取邏輯，先判斷用戶是否有參與記錄，若是沒有則領取成功，最後寫入到參與記錄中。這是個很是簡單的邏輯，可是，在高併發的場景下，存在深深的漏洞。多個併發請求經過負載均衡服務器，分配到內網的多臺Web服務器，它們首先向存儲發送查詢請求，而後，在某個請求成功寫入參與記錄的時間差內，其餘的請求獲查詢到的結果都是「沒有參與記錄」。這裏，就存在邏輯判斷被繞過的風險。

 

應對方案：

在程序入口處，一個帳號只容許接受1個請求，其餘請求過濾。不只解決了同一個帳號，發送N個請求的問題，還保證了後續的邏輯流程的安全。實現方案，能夠經過Redis這種內存緩存服務，寫入一個標誌位（只容許1個請求寫成功，結合watch的樂觀鎖的特性），成功寫入的則能夠繼續參加。

或者，本身實現一個服務，將同一個帳號的請求放入一個隊列中，處理完一個，再處理下一個。

2. 多個帳號，一次性發送多個請求

不少公司的帳號註冊功能，在發展早期幾乎是沒有限制的，很容易就能夠註冊不少個帳號。所以，也致使了出現了一些特殊的工做室，經過編寫自動註冊腳本，積累了一大批「殭屍帳號」，數量龐大，幾萬甚至幾十萬的帳號不等，專門作各類刷的行爲（這就是微博中的「殭屍粉「的來源）。舉個例子，例如微博中有轉發抽獎的活動，若是咱們使用幾萬個「殭屍號」去混進去轉發，這樣就能夠大大提高咱們中獎的機率。

這種帳號，使用在秒殺和搶購裏，也是同一個道理。例如，iPhone官網的搶購，火車票黃牛黨。

應對方案：

這種場景，能夠經過檢測指定機器IP請求頻率就能夠解決，若是發現某個IP請求頻率很高，能夠給它彈出一個驗證碼或者直接禁止它的請求：

1. 彈出驗證碼，最核心的追求，就是分辨出真實用戶。所以，你們可能常常發現，網站彈出的驗證碼，有些是「鬼神亂舞」的樣子，有時讓咱們根本沒法看清。他們這樣作的緣由，其實也是爲了讓驗證碼的圖片不被輕易識別，由於強大的「自動腳本」能夠經過圖片識別裏面的字符，而後讓腳本自動填寫驗證碼。實際上，有一些很是創新的驗證碼，效果會比較好，例如給你一個簡單問題讓你回答，或者讓你完成某些簡單操做（例如百度貼吧的驗證碼）。
2. 直接禁止IP，其實是有些粗暴的，由於有些真實用戶的網絡場景剛好是同一出口IP的，可能會有「誤傷「。可是這一個作法簡單高效，根據實際場景使用能夠得到很好的效果。

 

3. 多個帳號，不一樣IP發送不一樣請求

所謂道高一尺，魔高一丈。有進攻，就會有防守，永不休止。這些「工做室」，發現你對單機IP請求頻率有控制以後，他們也針對這種場景，想出了他們的「新進攻方案」，就是不斷改變IP。=

有同窗會好奇，這些隨機IP服務怎麼來的。有一些是某些機構本身佔據一批獨立IP，而後作成一個隨機代理IP的服務，有償提供給這些「工做室」使用。還有一些更爲黑暗一點的，就是經過木馬黑掉普通用戶的電腦，這個木馬也不破壞用戶電腦的正常運做，只作一件事情，就是轉發IP包，普通用戶的電腦被變成了IP代理出口。經過這種作法，黑客就拿到了大量的獨立IP，而後搭建爲隨機IP服務，就是爲了掙錢。

應對方案：

說實話，這種場景下的請求，和真實用戶的行爲，已經基本相同了，想作分辨很困難。再作進一步的限制很容易「誤傷「真實用戶，這個時候，一般只能經過設置業務門檻高來限制這種請求了，或者經過帳號行爲的」數據挖掘「來提早清理掉它們。

殭屍帳號也仍是有一些共同特徵的，例如帳號極可能屬於同一個號碼段甚至是連號的，活躍度不高，等級低，資料不全等等。根據這些特色，適當設置參與門檻，例如限制參與秒殺的帳號等級。經過這些業務手段，也是能夠過濾掉一些殭屍號。

4. 火車票的搶購

看到這裏，同窗們是否明白你爲何搶不到火車票？若是你只是老老實實地去搶票，真的很難。經過多帳號的方式，火車票的黃牛將不少車票的名額佔據，部分強大的黃牛，在處理驗證碼方面，更是「技高一籌「。

高級的黃牛刷票時，在識別驗證碼的時候使用真實的人，中間搭建一個展現驗證碼圖片的中轉軟件服務，真人瀏覽圖片並填寫下真實驗證碼，返回給中轉軟件。對於這種方式，驗證碼的保護限制做用被廢除了，目前也沒有很好的解決方案。

由於火車票是根據身份證明名制的，這裏還有一個火車票的轉讓操做方式。大體的操做方式，是先用買家的身份證開啓一個搶票工具，持續發送請求，黃牛帳號選擇退票，而後黃牛買家成功經過本身的身份證購票成功。當一列車箱沒有票了的時候，是沒有不少人盯着看的，何況黃牛們的搶票工具也很強大，即便讓咱們看見有退票，咱們也不必定能搶得過他們哈。 

最終，黃牛順利將火車票轉移到買家的身份證下。

解決方案：

並無很好的解決方案，惟一能夠動心思的也許是對帳號數據進行「數據挖掘」，這些黃牛帳號也是有一些共同特徵的，例如常常搶票和退票，節假日異常活躍等等。將它們分析出來，再作進一步處理和甄別。

3、高併發下的數據安全

咱們知道在多線程寫入同一個文件的時候，會存現「線程安全」的問題（多個線程同時運行同一段代碼，若是每次運行結果和單線程運行的結果是同樣的，結果和預期相同，就是線程安全的）。若是是MySQL數據庫，可使用它自帶的鎖機制很好的解決問題，可是，在大規模併發的場景中，是不推薦使用MySQL的。秒殺和搶購的場景中，還有另一個問題，就是「超發」，若是在這方面控制不慎，會產生髮送過多的狀況。咱們也曾經據說過，某些電商搞搶購活動，買家成功拍下後，商家卻不認可訂單有效，拒絕發貨。這裏的問題，也許並不必定是商家奸詐，而是系統技術層面存在超發風險致使的。

1. 超發的緣由

假設某個搶購場景中，咱們一共只有100個商品，在最後一刻，咱們已經消耗了99個商品，僅剩最後一個。這個時候，系統發來多個併發請求，這批請求讀取到的商品餘量都是99個，而後都經過了這一個餘量判斷，最終致使超發。（同文章前面說的場景）

在上面的這個圖中，就致使了併發用戶B也「搶購成功」，多讓一我的得到了商品。這種場景，在高併發的狀況下很是容易出現。

2. 悲觀鎖思路

解決線程安全的思路不少，能夠從「悲觀鎖」的方向開始討論。

悲觀鎖，也就是在修改數據的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。

雖然上述的方案的確解決了線程安全的問題，可是，別忘記，咱們的場景是「高併發」。也就是說，會不少這樣的修改請求，每一個請求都須要等待「鎖」，某些線程可能永遠都沒有機會搶到這個「鎖」，這種請求就會死在那裏。同時，這種請求會不少，瞬間增大系統的平均響應時間，結果是可用鏈接數被耗盡，系統陷入異常。

3. FIFO隊列思路

那好，那麼咱們稍微修改一下上面的場景，咱們直接將請求放入隊列中的，採用FIFO（First Input First Output，先進先出），這樣的話，咱們就不會致使某些請求永遠獲取不到鎖。看到這裏，是否是有點強行將多線程變成單線程的感受哈。

而後，咱們如今解決了鎖的問題，所有請求採用「先進先出」的隊列方式來處理。那麼新的問題來了，高併發的場景下，由於請求不少，極可能一瞬間將隊列內存「撐爆」，而後系統又陷入到了異常狀態。或者設計一個極大的內存隊列，也是一種方案，可是，系統處理完一個隊列內請求的速度根本沒法和瘋狂涌入隊列中的數目相比。也就是說，隊列內的請求會越積累越多，最終Web系統平均響應時候仍是會大幅降低，系統仍是陷入異常。

4. 樂觀鎖思路

這個時候，咱們就能夠討論一下「樂觀鎖」的思路了。樂觀鎖，是相對於「悲觀鎖」採用更爲寬鬆的加鎖機制，大都是採用帶版本號（Version）更新。實現就是，這個數據全部請求都有資格去修改，但會得到一個該數據的版本號，只有版本號符合的才能更新成功，其餘的返回搶購失敗。這樣的話，咱們就不須要考慮隊列的問題，不過，它會增大CPU的計算開銷。可是，綜合來講，這是一個比較好的解決方案。

5. 緩存服務器 

Redis分佈式要保證數據都能可以平均的緩存到每一臺機器，首先想到的作法是對數據進行分片，由於Redis是key-value存儲的，首先想到的是Hash分片，可能的作法是對key進行哈希運算，獲得一個long值對分佈式的數量取模會獲得一個一個對應數據庫的一個映射，沒有讀取就能夠定位到這臺數據庫

有不少軟件和服務都「樂觀鎖」功能的支持，例如Redis中的watch就是其中之一。經過這個實現，咱們保證了數據的安全。

4、小結

互聯網正在高速發展，使用互聯網服務的用戶越多，高併發的場景也變得愈來愈多。電商秒殺和搶購，是兩個比較典型的互聯網高併發場景。雖然咱們解決問題的具體技術方案可能千差萬別，可是遇到的挑戰倒是類似的，所以解決問題的思路也殊途同歸。

我的整理併發解決方案。

     a.應用層面：讀寫分離、緩存、隊列、集羣、令牌、系統拆分、隔離、系統升級（可水平擴容方向）。

     b.時間換空間：下降單次請求時間，這樣在單位時間內系統併發就會提高。

     c.空間換時間：拉長總體處理業務時間，換取後臺系統容量空間。