PHP如何應對高併發

綜述

在之前的工作中,並沒有接觸過也沒有處理過高併發,但是高併發是必須要學習的,在現在的公司沒有技術leader,所以,高併發以及優化的一些問題需要自己去考慮並且解決。

這個我還真布吉島(不知道)

解決方案

一:什麼是高併發?

高併發指的是併發數量,是指同一時間有多少個訪問同時來訪問同一api接口或者url地址。

 

二:高併發相關概念

(1)(每秒查詢率):每秒請求或者查詢的數量,在互聯網領域,指每秒響應請求數(指HTTP請求);

       a) 使用ab對Nginx進行壓力測試

       b) Mysql狀態查看QPS

(2)PV(Page View):綜合瀏覽量,即頁面瀏覽量或者點擊量,一個訪客在24小時內訪問的頁面數量(注:同一個人瀏覽你的網站的同一頁面,只記做一次pv);

      a) PV的統計:PV是每次加載頁面都加1;

(3)UV(Unqie Vistor):獨立訪客,一定時間範圍內,相同訪客多次訪問網站,只計算爲1個獨立訪客;

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

(5)響應時間:從請求發出到收到響應花費的時間;

(6)帶寬:計算帶寬需關注兩個指標,峯值流量和頁面的平均大小;

(7)日網站帶寬: PV/統計時間(換算到秒) * 平均頁面大小(kb)* 8;

注意事項:

(1)QPS不等於併發連接數(QPS是每秒HTTP請求數量,併發連接數是系統同時處理的請求數量);

(2)峯值每秒請求數(QPS)= (總PV數*80%)/ (六小時秒數*20%)【代表80%的訪問量都集中在20%的時間內】;

(3)壓力測試: 測試能承受的最大併發數 以及測試最大承受的QPS值;

(4)常用的性能測試工具【ab,wrk,httpload,Web Bench,Siege,Apache JMeter】

 

三、優化

 

四、解決方案案例 

 (1)流量優化 -- 去除一些惡意請求,進行防盜鏈處理;

       a) Referer:以Nginx爲例,前提加載ngx_http_referer_module模塊 (易僞造referer,安全性低)

location ~* \.(gif|jpg|png|webp)$ {
#指令valid_referers  全局invalid_referer
   valid_referers none blocked domain.com *.domain.com ;
   if ($invalid_referer) {
        return 403;
        #rewrite ^/ http://www.domain.com/403.jpg;
   }
}

       b) 加密簽名:通過簽名,根據計算簽名的方式,判斷請求是否合法,如果合法則顯示,否則返回錯誤信息
加密簽名 (安全性高)

#以Nginx爲例,前提加載第三方模塊HttpAccessKeyModule實現防盜鏈
location ~* \.(gif|jpg|png|webp)$ {
    accesskey on;
    accesskey_hashmethod md5;
    accesskey_arg key;
    accesskey_signature "mysrc$remote_addr";
}

(2)前端優化;

  1. 減少http請求次數;

 a)  CSS Sprites(雪碧圖) -- 合拼圖片,再使用css的background-image和background-position來指定顯示元素 CSS Sprites與圖片地圖性能差不多,但CSS Sprites更加簡單靈活;

 b) 合併JS與CSS文件 -- 加載一個JS文件比加載多個JS文件要快,一般會使用前端自動構建工具打包合併;

 c) 圖片使用base64編碼 -- 圖片base64除了可以使用在<img>中,還可以使用在css的background-image中;

 d) 圖片地圖 -- 把多張圖片合成一張,再使用<map>標籤來實現對圖片上不同區域的鏈接;

     2. 添加異步請求,當用戶觸發某個事件之後,再異步請求數據;

     3. 啓用瀏覽器緩存和文件壓縮;

     4. CDN加速;

     5. 將圖片以及文件類放在其他服務器上(減少I/O);

(3)服務端優化;

    1. 頁面靜態化處理;

    2. 併發處理;

    3. 隊列處理;

(4)數據庫優化;

    1. 數據庫緩存;

    2. 數據庫讀寫分離;

      a) 對於高併發系統來說,一開始都是讀多寫少,大量的讀請求經過業務層到達持久層之後對數據庫產生了極大的壓力,此時就會準備一個和生產庫一致的數據庫來單獨接收處理讀請求,一般這個叫做從庫,也會被稱爲讀庫,高併發流量中的讀請求會被引流到從庫,而寫請求還是在主庫寫,主庫和從庫之間依靠主從複製機制來確保兩個庫的數據近乎實時一致,這樣用戶在讀請求的時候幾乎發現不了數據的不一致。

    3. 對數據庫進行分庫、分表;

     a) 讀寫分離主要是爲了應對讀請求,那如果寫請求的流量大,就會考慮用到對數據庫進行分庫分表操作;

    4. 負載均衡;

(5)WEB服務器優化;

  1. Nginx反向代理實現負載均衡;
  2. lvs實現負載均衡;

遇上你是我的緣

總結

以上只是一些方案,之後會不斷學習並且落實到項目中,針對各個方面進行優化,加油,奧利給。

奧利給(派大星)_大星_奧利表情

 參考:

https://blog.csdn.net/m_nanle_xiaobudiu/article/details/79261765

https://www.jianshu.com/p/cf0cb82ee5ec

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章