高并發大流量網站的優化方案

高并發常用術語：

• QPS：每秒鐘請求或者查詢的數量，在網際網路領域，指每秒響應請求數(指HTTP請求)
• 吞吐量：機關時間内處理的請求數量(通常由QPS與并發數決定)
• 響應時間：從請求發出到收到響應花費的時間，例如系統處理一個HTTP請求需要100ms，這個100ms就是系統的響應時間
• PV：綜合浏覽量(Page View)，即頁面浏覽量或者點選量，一個訪客在24小時内通路的頁面數量，同一個人浏覽你的網站同一頁面，隻記作一次PV
• UV：獨立通路(UniQue Visitor)，即一定時間範圍内相同訪客多次通路網站，隻計算為1個獨立訪客

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

  日網站帶寬=PV/統計時間(換算到秒)平均頁面大小(機關KB)8

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

  QPS不等于并發連接配接數

  QPS是每秒HTTP請求數量，并發連接配接數是系統同時處理的請求數量

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

  80%的通路量集中在20%的時間！！！

• PS達到50

  可以稱之為小型網站，一般的伺服器就可以應付

• QPS達到100

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

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

        方案:資料庫緩存層、資料庫的負載均衡

• QPS達到800

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

        假設每個頁面隻有10k，在這個并發條件下，百兆帶寬已經吃完

         方案：CDN加速、負載均衡

•  QPS達到1000

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

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

              方案：靜态HTML緩存

• QPS達到2000

         這個級别下，檔案系統通路鎖都成為災難

         方案：做業務分離，分布式存儲

優化方案：

前端優化：（壓縮工具，uglifyjs,webpack）

   檔案合并，減少HTTP請求

    （圖檔地圖，CSS 精靈，多個腳本合并，多個樣式表合并，圖檔使用base64編碼）

  啟用浏覽器緩存和檔案壓縮

    本地緩存：

pragma	當該字段值為“no-cache”的時候，會知會用戶端不要對該資源讀緩存，即每次都得向伺服器發一次請求才行
expire	啟用緩存和定義緩存時間，響應封包中Expires所定義的緩存時間是相對伺服器上的時間而言的。如果用戶端上的時間跟伺服器上的時間不一緻（特别是使用者修改了自己電腦的系統時間），那緩存時間可能就沒啥意義了
cache-control.nostore	所有内容部儲存到緩存或Internet臨時檔案中
cache-control.nocache	不使用緩存，向伺服器發起請求
cache-control.max-age	告知用戶端該資源在delta-seconds秒内是新鮮的，無需向伺服器發送請求

    協商緩存：

Last-modified	資源最後一次修改時間
if-Match	比較Etag 資源比對資訊
if-None-Match	比較Etag 資源比對資訊
If-Modified-Since	比較資源最後更新時間是否一緻
if-Unmodified-Since	比較資源最後更新時間是否一緻

nginx相關配置：

  etag:on|off

  gzip壓縮：

  gzip: on|off

  gzip_comp_level[1-9] 壓縮級别越高壓縮越小，越浪費CPU

　CＤＮ加速 

　異步請求（實時資料要求比較高）

　建立獨立的圖檔伺服器

後端優化：

　　防盜鍊

      1)referer  2)簽名

　　頁面靜态化

　　并發處理

　　隊列處理

　　資料庫緩存

　　分庫分表（分區）

　　讀寫分離

　　負載均衡