（轉）PHP如何解決網站大流量和高併發

原文連接：https://chensenlin.cn/posts/16446/

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

高併發架構相關概念

併發，在操做系統中，是指一個時間段中有幾個程序都處於已啓動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一個時刻點上只有一個程序在處理機上運行

一般咱們所定義的高併發並不是上述解釋，簡單的來講就是在某個時間點、有多少個訪問同時到來。

高併發：一般若是一個日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服務器優化

負載均衡