本文將從宏觀的角度上全方位剖析高并發(fā)和大流量解決方案
? ?從一個(gè)面試題開(kāi)始講解:PHP如何解決網(wǎng)站大流量與高并發(fā)的問(wèn)題？
? ?其實(shí)這個(gè)問(wèn)題不光考察php的方向，更多的是考察你對(duì)高并發(fā)架構(gòu)優(yōu)化的方式和能力。
? ?主要考察點(diǎn)如下:
? ? ? ? ?一、高并發(fā)架構(gòu)相關(guān)概念
互聯(lián)網(wǎng)中的高并發(fā)通常指的是并發(fā)訪問(wèn)，也就是在某個(gè)時(shí)間點(diǎn)，有多少個(gè)請(qǐng)求來(lái)同時(shí)訪問(wèn)；
通常如果一個(gè)系統(tǒng)的日PV在千萬(wàn)以上，就有可能是一個(gè)高并發(fā)的系統(tǒng)，但是如果有些公司完全不走技術(shù)路線，全靠機(jī)器堆，那么這個(gè)不在我們所說(shuō)的高并發(fā)的討論范圍、純屬人傻錢(qián)多的?
1、對(duì)于高并發(fā)的問(wèn)題，我們具體應(yīng)該關(guān)心什么?
? ? ?QPS:每秒鐘請(qǐng)求或者查詢的數(shù)量，在互聯(lián)網(wǎng)領(lǐng)域，指的是每秒響應(yīng)的請(qǐng)求數(shù)（通常指的是HTTP請(qǐng)求）；?這是一個(gè)非常重要的指標(biāo)，通常在進(jìn)行理解并發(fā)數(shù)在哪個(gè)點(diǎn)該做什么的優(yōu)化可以根據(jù)QPS的量進(jìn)行操作；
? ? ?吞吐量:單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)量（通常由QPS和并發(fā)數(shù)來(lái)決定的）
? ? ?響應(yīng)時(shí)間:從請(qǐng)求發(fā)出到收到響應(yīng)花費(fèi)的時(shí)間。例如系統(tǒng)處理一個(gè)HTTP請(qǐng)求需要100ms，那么這100ms就是系統(tǒng)的響應(yīng)時(shí)間；
? ? ?每個(gè)資源的響應(yīng)時(shí)間如下圖所示，
?PV：綜合瀏覽量（Page?View），即頁(yè)面瀏覽量或者點(diǎn)擊量，一個(gè)訪客在多長(zhǎng)時(shí)間內(nèi)訪問(wèn)的的頁(yè)面數(shù)量；用戶每1次對(duì)網(wǎng)站中的每個(gè)網(wǎng)頁(yè)訪問(wèn)均被記錄1次。用戶對(duì)同一頁(yè)面的多次訪問(wèn)，訪問(wèn)量累計(jì)。
UV：獨(dú)立訪客（?UniQue?Visitor），即一定時(shí)間范圍內(nèi)相同訪客多次訪問(wèn)網(wǎng)站，只能算為1個(gè)獨(dú)立訪客；其實(shí)跟IP類似；
帶寬：計(jì)算帶寬大小需要關(guān)注兩個(gè)指標(biāo) ，峰值流量和頁(yè)面的平均大小;
【日網(wǎng)站帶寬 = PV / 統(tǒng)計(jì)時(shí)間（換算成秒）*?平均頁(yè)面大?。▎挝籏B）* 8】
此處澄清一個(gè)概念QPS并不等于并發(fā)鏈接數(shù)
QPS是每秒HTTP請(qǐng)求數(shù)量，并發(fā)鏈接數(shù)是系統(tǒng)同時(shí)能夠處理的請(qǐng)求數(shù)量
【峰值（每秒請(qǐng)求數(shù)）QPS? = （總PV數(shù) * 80%）/ (8小時(shí)秒數(shù)? * 20% )】
? ?解釋:通常80%的訪問(wèn)量都集中在20%的時(shí)間內(nèi)；俗稱二八定律 8小時(shí)是做了簡(jiǎn)單的估計(jì)
? 2、 那么對(duì)于QPS來(lái)說(shuō)?我們要做一個(gè)壓力測(cè)試??
? ? ?為什么要做壓力測(cè)試：
? （1）測(cè)試能承受的最大并發(fā)數(shù)
? （2）測(cè)試最大承受的QPS的值
? ? ? ? ? ? ?比如說(shuō)我們?nèi)誕PS為20000 單機(jī)峰值QPS能承受500 那么最少得40臺(tái)才能撐住
? ? 常用的性能測(cè)試工具如下:ab、wrk、http_load、Web?Bench、Apache?JMeter?
? ? ?性能測(cè)試工具非常多?我們通過(guò)ab來(lái)講解:
? ? ab?全稱(apache?benchmark)：是apache官方推出的工具，可以創(chuàng)建多個(gè)并發(fā)訪問(wèn)線程，摸你多個(gè)訪問(wèn)者同時(shí)對(duì)某一URL地址進(jìn)行訪問(wèn)。它的測(cè)試目標(biāo)是基于URL的，因此，它既可以用來(lái)測(cè)試apache的訪問(wèn)壓力，也可以來(lái)測(cè)試?nginx、lighthttp、tomcat、IIS等其他的web服務(wù)器的壓力。
? ? ab的使用:模擬并發(fā)請(qǐng)求100次,總共請(qǐng)求5000次
? ? 注意事項(xiàng):
? ? ?1）測(cè)試機(jī)器與被測(cè)試機(jī)器要分開(kāi)?
? ? ?2）切記不要對(duì)線上服務(wù)做壓力測(cè)試
? ? 3）觀察測(cè)試工具ab所在的機(jī)器，以及被測(cè)試的前端機(jī)的 CPU、內(nèi)存、網(wǎng)絡(luò)等都不能超過(guò)最高限度的75%? 可以通過(guò)top、htop、glances命令來(lái)觀察
測(cè)試：ab -c 50? -n 1000? http://192.168.56.10:82/index.html
QPS達(dá)到極限我們?cè)撛趺醋觯?/b>
? 隨著QPS的增長(zhǎng)，每個(gè)階段需要根據(jù)實(shí)際情況來(lái)進(jìn)行優(yōu)化，優(yōu)化的方案也與硬件條件，網(wǎng)絡(luò)帶寬息息相關(guān)。通常在對(duì)QPS進(jìn)行優(yōu)化的時(shí)候階段也是不一樣的
1、QPS達(dá)到50?
? ? ?可以稱為小型網(wǎng)站、一般的服務(wù)器都可以輕松應(yīng)付
2、QPS達(dá)到100
? ? ? 假設(shè)關(guān)系型數(shù)據(jù)庫(kù)的每次請(qǐng)求需要在0.01秒完成，如果單個(gè)頁(yè)面只有一個(gè)SQL查詢，那么100QPS意味著1秒要完成100次請(qǐng)求，但是此時(shí)我們并不能保證數(shù)據(jù)庫(kù)查詢能完成100次
? ? ? 優(yōu)化方案:數(shù)據(jù)庫(kù)緩存層（redis、memcache）、數(shù)據(jù)庫(kù)的負(fù)載均衡流量進(jìn)行分散
3、QPS達(dá)到800
? ? ? 假設(shè)我們使用的是百兆帶寬、意味著網(wǎng)站出口的實(shí)際帶寬是8M左右，假設(shè)每個(gè)頁(yè)面只有大小10KB，在這個(gè)條件下，百兆帶寬已經(jīng)被吃完、對(duì)于帶寬來(lái)說(shuō)已經(jīng)是極限
? ? ? 優(yōu)化方案:CDN加速訪問(wèn)、負(fù)載均衡
4、QPS達(dá)到1000
? ? ? 假設(shè)使用Redis緩存數(shù)據(jù)庫(kù)查詢，每個(gè)頁(yè)面對(duì)Redis的請(qǐng)求遠(yuǎn)大于直接對(duì)DB?的請(qǐng)求 ，那么Redis的悲觀并發(fā)數(shù)大于在4w左右，但有可能在之前內(nèi)網(wǎng)帶寬已經(jīng)唄吃光，表現(xiàn)出不穩(wěn)定
? ? ?優(yōu)化方案:靜態(tài)HTML緩存
5、QPS達(dá)到2000
? ? ?在這個(gè)級(jí)別下、文件系統(tǒng)訪問(wèn)鎖都成了災(zāi)難
? ? ?優(yōu)化方案:做業(yè)務(wù)分離、分布式存儲(chǔ)
? ? ? ? ?二、高并發(fā)架構(gòu)解決方案案例
? ? 1、流量?jī)?yōu)化：防盜鏈處理?
? ? 2、前端優(yōu)化：減少http請(qǐng)求、添加異步請(qǐng)求 、啟用瀏覽器緩存（添加緩存過(guò)期時(shí)間）和文件壓縮（圖片壓縮、文件壓縮、nginx gzip）、CDN加速、建立獨(dú)立的圖片服務(wù)器（減少IO消耗、集群處理優(yōu)化cpu、IO方面）
? ? 3、服務(wù)端優(yōu)化：頁(yè)面靜態(tài)化、并發(fā)處理、隊(duì)列處理
? ? 4、數(shù)據(jù)庫(kù)優(yōu)化：數(shù)據(jù)庫(kù)緩存（Redis、MongoDB）、分庫(kù)分表（水平、垂直拆分）、分區(qū)操作、讀寫(xiě)分離、負(fù)載均衡
? ? 5、web服務(wù)器優(yōu)化: 負(fù)載均衡（7層Nginx Proxy、 4層LVS）
本文就到此結(jié)束、下篇開(kāi)始會(huì)對(duì)上述方案逐一來(lái)詳細(xì)的進(jìn)行解答、請(qǐng)耐心等待。。。
? ? ? ? ? ?
