1. 程式人生 > >轉:基礎篇|PHP如何解決網站大流量和高併發

轉:基礎篇|PHP如何解決網站大流量和高併發

基礎篇

高併發架構基礎概念和優化思路

高併發架構相關概念

併發,在作業系統中,是指一個時間段中有幾個程式都處於已啟動執行到執行完畢之間,且這幾個程式都是在同一個處理機上執行,但任一個時刻點上只有一個程式在處理機上執行

通常我們所定義的高併發並非上述解釋,簡單的來說就是在某個時間點、有多少個訪問同時到來

高併發:通常如果一個日PV在千萬以上,就有可能是一個高併發的系統

QPS:每秒鐘請求或查詢的數量,在網際網路領域,指每秒響應請求數(HTTP請求)

吞吐量:單位時間內處理的請求數量(通常由QPS和併發數決定)

響應時間:從請求發出到收到響應花費的時間。例如系統處理一個HTTP請求需要10s,這個10s就是響應時間

PV:綜合瀏覽量(Page View),即頁面瀏覽量或者點選量,一個訪客在24小時內訪問的頁面數量

UV:獨立訪客(UniQue Visitor),即一定時間範圍內相同訪客多次訪問網站,只計算為1個獨立訪客

頻寬:計算頻寬大小需關注兩個指標,峰值流量和頁面的平均大小

日網站頻寬 = PV / 統計時間(秒)x 平均頁面大小(KB) x 8

峰值是平均值的倍數,根據實際情況來定

QPS VS 併發連線數

QPS 不等於併發連線數

QPS 是每秒 HTTP 請求數量,併發連線數是系統同時處理的請求數量

(總 PV 數 x 80%)1 (6 小時秒數 x 20%) = 峰值每秒請求數(QPS)

80%的訪問量主要集中在20%的時間

壓力測試

目的:測試能承受的最大併發 和 測試最大承受的QPS

常用效能測試工具

ab、wrk、http_ load. Web Bench、Siege、Apache JMeter

Ab

全稱是 apache benchmark,是 apache 官方推出的工具

建立多個併發訪問執行緒,模擬多個訪問者同時對某一 URL 地址進行訪問。它的測試目標是基於 URL 的,因此,它既可以用來測試 apache 的負載壓力,也可以測試 nginx、lighthttp、 Tomcat、IIS 等其它 Web 伺服器的壓力。

Ab的使用

模擬併發請求 100 次,總共請求 5000 次 ;Ab-c 100 -n 5000 待測試網站

注意事項

測試機器與被測試機器分開; 不要對線上服務做壓力測試; 觀察(top)測試工具 ab 所在機器以及被測試的前端機的 CPU,記憶體,網路等都不超過最高限度的75%。

QPS 達到極限的解決方案

隨著 QPS 的增長,每個階段需要根據實際情況來進行優化,優化的方案也與硬體條件、網路頻寬息息相關。

QPS達到50

基本不需要優化。

QPS 達到 100

假設關係型資料庫的每次請求在 0.01 秒完成

假設單頁面只有一個 SQL 查詢,那麼 100 QPS 意味著 1 秒鐘完成 100 次請求,但是此時我們並不能保證資料庫查詢能完成 100 次。

方案:資料庫快取層、資料庫的負載均衡

QPS 達到 800

假設我們使用百兆頻寬,意味著網站出口的實際頻寬是 8 M 左右

假設每個頁面只有 10 K,在這個併發條件下,百兆頻寬已經吃完方案:CDN 加速、負載均衡

QPS 達到 1000

假設使用 Memcache 綬存資料庫查詢資料,每個頁面對 Memcache 的請求遠大於直接對 DB 的請求

Memcache 的悲觀併發數在 2 w 左右,但有可能在之前內網頻寬已經吃光,表現出不穩定

方案:靜態 HTML 快取

QPS 達到 2000

這個級別下,檔案系統訪向鎖都成為了災難

方案:做業務分離,分散式儲存

高併發解決方案案例

流量優化

防盜鏈處理

前端優化

減少HTTP請求;例如合併CSS js,圖片 新增非同步請求;延遲載入暫時不需要的內容 啟用瀏覽器快取和檔案壓縮; CDN加速; 建立獨立的圖片伺服器;

服務端優化

頁面靜態化;併發處理;佇列處理

資料庫優化

資料庫快取;分庫分表、分割槽操作;讀寫分離;負載均衡

Web伺服器優化

負載均衡