怎麼解決高併發的後臺秒殺問題

秒殺一般是電商或者網上一些活動的場景，這種秒殺一般存在著後臺擁擠，伺服器承受不了大量的客戶端導致奔潰是經常的事情，我們今天來介紹一下解決高併發的後臺秒殺問題。

操作方法

（01）我們遇到的秒殺一般是在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到，這些都給我們帶來了很多的苦惱，而對於電商網站中一些稀缺或者特價商品，電商網站一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。因為狼多肉少的原因，導致伺服器擁擠，大量的客戶無功而返。

（02）解決這個一般有五步，第一步限流： 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，只允許少部分流量進入服務後端。

（03）第二步削峰：對於秒殺系統瞬時會有大量使用者湧入，以外賣為例，大量的外賣會在中午產生，商家推出滿減活動更是火熱。所以在搶購一開始會有很高的瞬間峰值。高峰值流量是壓垮系統很重要的原因，所以如何把瞬間的高流量變成一段時間平穩的流量也是設計秒殺系統很重要的思路。實現削峰的常用的方法有利用快取和訊息中介軟體等技術。

（04）第三步非同步處理：秒殺系統是一個高併發系統，採用非同步處理模式可以極大地提高系統併發量，其實非同步處理就是削峰的一種實現方式。

（05）第四步記憶體快取：秒殺系統最大的瓶頸一般都是資料庫讀寫，由於資料庫讀寫屬於磁碟IO，效能很低，如果能夠把部分資料或業務邏輯轉移到記憶體快取，效率會有極大地提升。充分利用快取，利用快取可極大提高系統讀寫速度。

（06）最後一步可拓展：當然如果我們想支援更多使用者，更大的併發，最好就將系統設計成彈性可拓展的，如果流量來了，拓展機器就好了。像淘寶、京東等雙十一活動時會增加大量機器應對交易高峰。訊息佇列可以削峰，將攔截大量併發請求，這也是一個非同步處理過程，後臺業務根據自己的處理能力，從訊息佇列中主動的拉取請求訊息進行業務處理。

（07）可以採用Redis 最簡單的key-value資料結構，用一個原子型別的變數值(AtomicInteger)作為key，把使用者id作為value，庫存數量便是原子變數的最大值。對於每個使用者的秒殺，我們使用 RPUSH key value插入秒殺請求， 當插入的秒殺請求數達到上限時，停止所有後續插入。然後我們可以在臺啟動多個工作執行緒，使用 LPOP key 讀取秒殺成功者的使用者id，然後再操作資料庫做最終的下訂單減庫存操作。