一、什麼是高併發
高併發（High Concurrency）是互聯網分佈式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證
系統能夠同時並行處理很多請求。高併發相關常用的一些指標有響應時間（Response Time），吞吐量
（Throughput），每秒查詢率QPS（Query Per Second），併發用戶數等。
響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時
間。
吞吐量：單位時間內處理的請求數量。
QPS：每秒響應請求數。在互聯網領域，這個指標和吞吐量區分的沒有這麼明顯。
併發用戶數：同時承載正常使用系統功能的用戶數量。例如一個即時通訊系統，同時在線量一定程度上代表了系統
的併發用戶數。
二、什麼是秒殺
秒殺場景一般會在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到。對於電商網站中一些稀缺或者特
價商品，電商網站一般會在約定時間點對其進行限量銷售，因爲這些商品的特殊性，會吸引大量用戶前來搶購，並
且會在約定的時間點同時在秒殺頁面進行搶購。
此種場景就是非常有特點的高併發場景，如果不對流量進行合理管控，肆意放任大流量衝擊系統，那麼將導致一系
列的問題出現，比如一些可用的連接資源被耗盡、分佈式緩存的容量被撐爆、數據庫吞吐量降低，最終必然會導致
系統產生雪崩效應。
一般來說，大型互聯網站通常採用的做法是通過擴容、動靜分離、緩存、服務降級及限流五種常規手段來保護系統
的穩定運行。
三、如何解決秒殺的高併發
1. 限流
在討論爲什麼需要限流之前，我們先聊一聊生活中那些隨處可見的限流場景。
例如上下班高峯期，大量人羣湧入地鐵站，會造成嚴重擁堵，原本從站廳到站臺最多隻需花費5分鐘左右的時間，
卻在被限流管制下被迫花費30分鐘或更久才能順利進入站臺。
上面兩張圖片就展示了地鐵擁擠的場景，如果這所有的人全部湧入站臺，那麼會造成更多的人無法上車，所以採取
了管制之後，我們可以讓人們通過地面和站廳層的雙重排隊等待，減輕站臺的壓力，保證每一位乘客最終都能順利
的上車。
在電商系統的秒殺中，也會有大批量的用戶同時湧入，鑑於只有少部分用戶能夠秒殺成功，所以要限制大部分流
量，只允許少部分流量進入服務後端。
限流可以採用限制服務器的連接等待數量以及等待時間，每次只放行少量用戶，讓更多的用戶處於假排隊的狀態。
例如tomcat的配置：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"
maxThreads="800" acceptCount="1000"/>
其中最後兩個參數意義如下：
maxThreads：tomcat起動的最大線程數，即同時處理的任務個數，默認值爲200
acceptCount：當tomcat起動的線程數達到最大時，接受排隊的請求個數，默認值爲100
這兩個值如何起作用，請看下面三種情況
情況1：接受一個請求，此時tomcat起動的線程數沒有到達maxThreads，tomcat會起動一個線程來處理此請求。
情況2：接受一個請求，此時tomcat起動的線程數已經到達maxThreads，tomcat會把此請求放入等待隊列，等待
空閒線程。
情況3：接受一個請求，此時tomcat起動的線程數已經到達maxThreads，等待隊列中的請求個數也達到了
acceptCount，此時tomcat會直接拒絕此次請求，返回connection refused
2. 頁面靜態化
首先我們可以使用Freemarker對頁面進行靜態化，讓用戶減少跟後端服務器之間的交互。這樣就能降低服務器的
壓力，如果條件允許我們可以採用CDN加速。
Freemarker的原理如下圖，模板+數據通過Freemarker可以生成靜態頁面。
CDN是將源站內容分發至最接近用戶的節點，使用戶可就近取得所需內容，提高用戶訪問的響應速度和成功率。 例如下圖：北京網民會自動訪問到離自己最近並且速度最快的服務器的資源。
3. 引入Redis
限流和靜態化都是爲了減輕服務器後端的壓力，但是最終用戶的請求還是會落到服務器中，爲了增加用戶的體驗
度，我們也應加快相應速度。後端代碼和數據庫之間的交互會降低相應速度，所以我們可以採用Redis來進行數據
的高速讀取。
Redis是一款極其優秀的內存級別的NoSql數據庫，單線程下讀寫速度能達到5w/s。所以我們在很多情況下都能利
用Redis去解決高速讀取的問題。
特別是庫存量的超賣現象，我們可以在開始秒殺的時候，把總的庫存量存入Redis中，每當用戶來搶購時，利用
String類型的decr方法去減一，如果減一成功就視認爲搶夠成功，並把用戶和商品信息存入Redis的訂單條目中，
當最終搶購結束時，我們再一併把Redis的訂單信息存入到數據庫中。
代碼參考：
# 設置總的待搶購數量爲1000000
set amount 1000000；
# 搶購 數量減一
decr amount
# 把用戶信息存入到搶購成功的集合中，由商品ID命名來區分
lpush 用戶ID 商品ID
四、總結
通過上述3種方案可以解決大部分場景下的秒殺問題，當然高併發下也會出現更多的意外的狀況，那麼我們可以針 對自己的業務，資源的調度進行更多方位的嘗試，找到最適合自己的解決方案。
