更新時間:2021-07-12 來源:黑馬程序員 瀏覽量:
高并發是互聯網應用的一大特色,也是互聯網應用不可避免的問題;比如淘寶雙11、京東618、12306春節火車票,促銷、秒殺等等。
高并發(High Concurrency)是互聯網分布式系統架構設計中必須考慮的因素之一,它通常是指,通過設計保證系統能夠同時并行處理很多請求。高并發相關常用的一些指標有響應時間(Response Time),吞吐量(Throughput),每秒查詢率QPS(Query Per Second),并發用戶數等。
響應時間:系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms,這個200ms就是系統的響應時間。
吞吐量:單位時間內處理的請求數量。
QPS:每秒響應請求數。在互聯網領域,這個指標和吞吐量區分的沒有這么明顯。
并發用戶數:同時承載正常使用系統功能的用戶數量。例如一個即時通訊系統,同時在線量一定程度上代表了系統的并發用戶數。
秒殺場景一般會在電商網站舉行一些活動或者節假日在12306網站上搶票時遇到。對于電商網站中一些稀缺或者特價商品,電商網站一般會在約定時間點對其進行限量銷售,因為這些商品的特殊性,會吸引大量用戶前來搶購,并且會在約定的時間點同時在秒殺頁面進行搶購。
此種場景就是非常有特點的高并發場景,如果不對流量進行合理管控,肆意放任大流量沖擊系統,那么將導致一系列的問題出現,比如一些可用的連接資源被耗盡、分布式緩存的容量被撐爆、數據庫吞吐量降低,最終必然會導致系統產生雪崩效應。
一般來說,大型互聯網站通常采用的做法是通過擴容、動靜分離、緩存、服務降級及限流五種常規手段來保護系統的穩定運行。
1. 限流
在討論為什么需要限流之前,我們先聊一聊生活中那些隨處可見的限流場景。
例如上下班高峰期,大量人群涌入地鐵站,會造成嚴重擁堵,原本從站廳到站臺最多只需花費5分鐘左右的時間,卻在被限流管制下被迫花費30分鐘或更久才能順利進入站臺。
上面兩張圖片就展示了地鐵擁擠的場景,如果這所有的人全部涌入站臺,那么會造成更多的人無法上車,所以采取了管制之后,我們可以讓人們通過地面和站廳層的雙重排隊等待,減輕站臺的壓力,保證每一位乘客最終都能順利的上車。
在電商系統的秒殺中,也會有大批量的用戶同時涌入,鑒于只有少部分用戶能夠秒殺成功,所以要限制大部分流量,只允許少部分流量進入服務后端。
限流可以采用限制服務器的連接等待數量以及等待時間,每次只放行少量用戶,讓更多的用戶處于假排隊的狀態。
例如tomcat的配置:
其中最后兩個參數意義如下:
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種方案可以解決大部分場景下的秒殺問題,當然高并發下也會出現更多的意外的狀況,那么我們可以針對自己的業務,資源的調度進行更多方位的嘗試,找到最適合自己的解決方案。
猜你喜歡: