高並發大流量專題---1、高並發大流量解決方案總結

一、總結

一句話總結：

可以根據 前后端數據庫順序 及 QPS數量來 決定優化方法

 

1、PHP如何解決網站大流量與高並發的問題？

流量優化+前端優化：比如防盜鏈處理、減少HTTP請求、添加異步請求、CDN加速、建立獨立圖片服務器、啟用瀏覽器緩存和文件壓縮等等

服務端優化+Web服務器優化：比如頁面靜態化、並發處理、隊列處理、負載均衡等等

數據庫優化：比如數據庫緩存、分庫分表、分區操作、讀寫分離、負載均衡等等

 

2、我們說的高並發是什么？

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

某個時間點的並發訪問量：上面的定義明顯不是我們通常所言的並發，在互聯網時代，所講的並發、高並發，通常是指並發訪問。也就是在某個時間點，有多少個訪問同時到來。

日PV在干萬以上：通常如果一個系統的日PV在干萬以上，有可能是一個高並發的系統

 

3、高並發解決方案？

技術：各種優化、緩存、負載均衡等技術

機器堆：有的公司完全不走技術路線，全靠機器堆，有錢，任性

 

4、高並發的問題中，需要了解的一些名詞？

qps、吞吐量、響應時間、pv、uv、帶寬、日網站帶寬、峰值

QPS：每秒響應請求數（指HTTP請求）：每秒鍾請求或者查詢的數量，在互聯網領域，指每秒響應請求數（指HTTP請求）；
吞吐量：單位時間內處理的請求數量（通常由QPS與並發數決定）
響應時間：從請求發出到收到響應花費的時間。例如系統處理一個HTTP請求需要100ms，這個100ms就是系統的響應時間
PV：綜合瀏覽量（Page View），即頁面瀏覽量或者點擊量，一個訪客在24小時內訪問的頁面數量；同一個人瀏覽你的網站同一頁面，只記作一次PV
UV：獨立訪客（UniQue Visitor），即一定時間范圍內相同訪客多次訪問網站，只計算為1個獨立訪客
帶寬：計算帶寬大小需關注兩個指標，峰值流量和頁面的平均大小
日網站帶寬=PV/統計時間（換算到秒）*平均頁面大小（單位KB）*8
峰值一般是平均值的倍數，根據實際情況來定
峰值每秒請求數（QPS）=（總PV數*80%）/（6小時秒數*20%）

 

5、日網站帶寬如何計算？

帶寬：計算帶寬大小需關注兩個指標，峰值流量和頁面的平均大小

日網站帶寬=PV/統計時間（換算到秒）*平均頁面大小（單位KB）*8

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

 

6、QPS 等於並發連接數 么？

不等於：QPS是每秒HTTP請求數量，並發連接數是系統同時處理的請求數：一個連接里面可能有多個http請求

 

7、峰值每秒請求數（QPS） 如何計算？

峰值每秒請求數（QPS）=（總PV數*80%）/（6小時秒數*20%）

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

 

8、壓力測試是什么？

最大並發：測試服務器集群（或單台）能承受的最大並發

QPS值：測試服務器集群（或單台）最大承受的QPS值

一般了解單台服務器能夠承受的QPS是多少

 

9、常用性能測試工具？

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

ab：全稱是apache benchmark，是apache官方推出的工具

ab原理：創建多個並發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基於URL的，因此，它既可以用來測試apache的負載壓力，也可以測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。

 

10、ab（apache benchmark）是apache官方推出的工具，那么它能夠測試nginx么？

能：它的測試目標是基於URL的：ab創建多個並發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基於URL的，因此，它既可以用來測試apache的負載壓力，也可以測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。

 

 

11、ab的使用（比如 模擬並發請求100次，總共請求5000次）？

運行ab命令：ab -c 100 -n 5000 待測試網站

 

12、ab測試注意事項？

測試機器與被測試機器分開

不要對線上服務做壓力測試

不超過最高限度的75%：觀察測試工具ab所在機器，以及被測試的前端機的CPU，內存，網絡等都不超過最高限度的75%

 

13、如何安裝使用ab測試？

獨立安裝：yum -y install httpd-tools

一般安裝apache會自動安裝ab

ab使用：ab -c 100 -n 5000 http://192.168.52.6/index

[root@localhost ~]# ab -c 100 -n 5000 http://192.168.52.6/index
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.52.6 (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        Apache
Server Hostname:        192.168.52.6
Server Port:            80

Document Path:          /index
Document Length:        1917 bytes

Concurrency Level:      100
Time taken for tests:   22.049 seconds
Complete requests:      5000
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Total transferred:      11438133 bytes
HTML transferred:       9579249 bytes
Requests per second:    226.77 [#/sec] (mean)
Time per request:       440.972 [ms] (mean)
Time per request:       4.410 [ms] (mean, across all concurrent requests)
Transfer rate:          506.61 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   9.0      0     125
Processing:     1  419 1614.8     68   17425
Waiting:        0  412 1601.8     68   17425
Total:          1  420 1614.8     72   17427

Percentage of the requests served within a certain time (ms)
  50%     72
  66%    125
  75%    163
  80%    193
  90%    399
  95%    987
  98%   7019
  99%   9085
 100%  17427 (longest request)

 

 

14、不同QPS下，優化與哪些方面有關？

硬件條件

網絡帶寬

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

 

15、不同QPS下的優化方案？

QPS100：數據庫緩存層、數據庫的負載均衡

QPS800：CDN加速、負載均衡

QPS1000：靜態HTML緩存

QPS2000：做業務分離，分布式存儲

 

16、QPS達到50 需要優化么？

可以不需要；稱之為小型網站，一般的服務器就可以應付

 

17、QPS達到100 如何優化？

|||-begin

假設關系型數據庫的每次請求在0.01秒完成；

假設單頁面只有一個SQL查詢，那么100QPS意味着1秒鍾完成100次請求，但是此時我們並不能保證數據庫查詢能完成100次

|||-end

數據庫緩存層、數據庫的負載均衡

 

18、QPS 達到800 如何優化？

|||-begin

假設我們使用百兆帶寬，意味着網站出口的實際帶寬是8M左右

假設每個頁面只有10K，在這個並發條件下，百兆帶寬已經吃完

|||-end

CDN加速、負載均衡

 

19、QPS 達到1000 如何優化？

|||-begin

假設使用Memcache緩存數據庫查詢數據，每個頁面對Memcache的請求遠大於直接對DB的請求

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

|||-end

靜態HTML緩存

 

20、QPS 達到2000 如何優化？

|||-begin

這個級別下，文件系統訪問鎖都成為了災難

|||-end

做業務分離，分布式存儲

 

 

21、高並發優化的方向有哪些？

流量優化+前端優化：比如防盜鏈處理、減少HTTP請求、添加異步請求、CDN加速、建立獨立圖片服務器、啟用瀏覽器緩存和文件壓縮等等

服務端優化+Web服務器優化：比如頁面靜態化、並發處理、隊列處理、負載均衡等等

數據庫優化：比如數據庫緩存、分庫分表、分區操作、讀寫分離、負載均衡等等

流量優化 方法
防盜鏈處理


前端優化 方法
減少HTTP請求
添加異步請求：比如ajax
啟用瀏覽器緩存和文件壓縮
CDN加速
建立獨立圖片服務器



服務端優化 方法
頁面靜態化
並發處理
隊列處理


數據庫優化 方法
數據庫緩存
分庫分表、分區操作
讀寫分離
負載均衡


Web服務器優化 方法
負載均衡

 

22、流量優化 方法？

防盜鏈處理

 

23、前端優化 方法？

減少HTTP請求

添加異步請求：比如ajax

啟用瀏覽器緩存和文件壓縮

CDN加速 + 建立獨立圖片服務器

 

24、服務端優化 方法？

頁面靜態化

並發處理

隊列處理

 

25、數據庫優化 方法？

數據庫緩存

分庫分表、分區操作

讀寫分離

負載均衡

 

26、Web服務器優化 方法？

負載均衡

 

27、如何查看頁面的響應時間？

chrome瀏覽器->network->右下角紅色字：比如 Load:1.65s

 

95 requests I 409 KB transferred I 718 KB resources l Finish:3.06s l DOMContentloaded:910 ms I Load:1.65s

 

 

 

二、內容在總結中