一、什麼是高并發
高并發（High Concurrency）是網際網路分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時并行處理很多請求。高并發相關常用的一些名額有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），并發使用者數等。
響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時 間。
吞吐量：機關時間内處理的請求數量。
QPS：每秒響應請求數。在網際網路領域，這個名額和吞吐量區分的沒有這麼明顯。
并發使用者數：同時承載正常使用系統功能的使用者數量。例如一個即時通訊系統，同時線上量一定程度上代表了系統 的并發使用者數。
二、什麼是秒殺
秒殺場景一般會在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到。對于電商網站中一些稀缺或者特 價商品，電商網站一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，并 且會在約定的時間點同時在秒殺頁面進行搶購。
此種場景就是非常有特點的高并發場景，如果不對流量進行合理管控，肆意放任大流量沖擊系統，那麼将導緻一系 列的問題出現，比如一些可用的連接配接資源被耗盡、分布式緩存的容量被撐爆、資料庫吞吐量降低，最終必然會導緻 系統産生雪崩效應。
一般來說，大型網際網路站通常采用的做法是通過擴容、動靜分離、緩存、服務降級及限流五種正常手段來保護系統 的穩定運作。
三、如何解決秒殺的高并發
1. 限流
在讨論為什麼需要限流之前，我們先聊一聊生活中那些随處可見的限流場景。
例如上下班高峰期，大量人群湧入地鐵站，會造成嚴重擁堵，原本從站廳到站台最多隻需花費5分鐘左右的時間， 卻在被限流管制下被迫花費30分鐘或更久才能順利進入站台。
上面兩張圖檔就展示了地鐵擁擠的場景，如果這所有的人全部湧入站台，那麼會造成更多的人無法上車，是以采取 了管制之後，我們可以讓人們通過地面和站廳層的雙重排隊等待，減輕站台的壓力，保證每一位乘客最終都能順利 的上車。
在電商系統的秒殺中，也會有大批量的使用者同時湧入，鑒于隻有少部分使用者能夠秒殺成功，是以要限制大部分流 量，隻允許少部分流量進入服務後端。
限流可以采用限制伺服器的連接配接等待數量以及等待時間，每次隻放行少量使用者，讓更多的使用者處于假排隊的狀态。 例如tomcat的配置：
1<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的訂單資訊存入到資料庫中。
代碼參考：
1 # 設定總的待搶購數量為1000000
2 set amount 1000000；
3 # 搶購 數量減一
4 decr amount 5
6 # 把使用者資訊存入到搶購成功的集合中，由商品ID命名來區分
7 lpush 使用者ID 商品ID
四、總結
通過上述3種方案可以解決大部分場景下的秒殺問題，當然高并發下也會出現更多的意外的狀況，那麼我們可以針 對自己的業務，資源的排程進行更多方位的嘗試，找到最适合自己的解決方案。