1）併發
併發，在操作系統中，是指一個時間段中有幾個程序都處於已啓動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一個時刻點上只有一個程序在處理機上運行。
2）我們說的高併發是什麼？
上面的定義明顯不是我們通常所言的併發，在互聯網時代，所講的併發、高併發，通常是指併發訪問。也就是在某個時間點，有多少個訪問同時到來。通常如果一個系統的日PV在千萬以上，
有可能是一個高併發的系統。有的公司完全不走技術路線，全靠機器堆，這不是我們的討論範圍。
3）高併發的問題，我們具體該關心什麼？
- QPS：每秒鐘請求或者查詢的數量，在互聯網領域，指每秒響應請求數（指HTTP請求）；
- 吞吐量：單位時間內處理的請求數量（通常由QPS與併發數決定）；
- 響應時間：從請求發出到收到響應花費的時間（例如：系統處理一個HTTP請求需要 100ms，這個 100ms 就是系統的響應時間）；
- PV：綜合瀏覽量（Page View），即頁面瀏覽量或者點擊量，一個訪客在 24 小時內訪問的頁面數量。同一個人瀏覽你的網站同一頁面，只記作一次PV；
- UV：獨立訪客（UniQue Visitor），即一定時間範圍內相同訪客多次訪問網站，只計算爲1個獨立訪客；
- 帶寬：計算帶寬大小需關注兩個指標， 峯值流量 和 頁面的平均大小。
- 日網站帶寬 = PV / 統計時間（換算到秒）x 平均頁面大小（單位KB）x 8
- 峯值一般是平均值得倍數，根據實際情況來定；
- QPS 不等於 併發連接數；
- QPS是每秒HTTP請求數量，併發連接數是系統同時處理的請求數量（1個HTTP請求叫做1個QPS，一個併發連接數有可能裏面有多個HTTP請求）
- 峯值每秒請求數（QPS） = （總PV數 * 80%) / (6小時秒數 * 20%)【代表80% 的訪問量集中在 20% 的時間】；
- QPS壓力測試：用來了解單臺服務器所能承受的QPS值是多少：
- 測試能承受的最大併發數（測試服務器最大能承受多少QPS，網站一天PV是多少，可以計算出來整個QPS的峯值是多少）；
- 測試最大承受的QPS值
注：首先要知道 整個網站的日PV 是多少，服務器單臺QPS的承受能力 是多少（如：我們日QPS經過計算得到200（單機峯值QPS爲200），單機QPS承受力爲50，至少需要4臺機器，才能完成訪問）。
4）常用性能測試工具
① ab
全稱是 apache benchmark，是 apache 官方推出的工具。 原理：創建多個併發訪問線程，模擬多個訪問者同時對某一個URL地址進行訪問。它的測試目標是基於URL的，因此，它既可以用來測試 apache 的負載壓力，
也可以測試 nginx、lighthttp、tomcat、IIS等其它 Web 服務器的壓力。 使用方法：如模擬併發請求 100次，總共請求 5000次（ab -c 100 -n 5000 待測試網站：-c 表示 併發數，這兒是100； -n表示 總共請求次數，這兒是5000）。
注意事項：
測試機器與被測試機器分開； 不要對線上服務做壓力測試； 觀察測試工具ab所在機器，以及被測試的前端機的CPU，內存，網絡等都不超過最高限度的 75%.
② wrk
③ http_load
④ Web Bench
⑤ Siege
⑥ Apache JMeter
5）QPS達到極限，該怎麼辦？
隨着QPS的增長，每個階段需要根據實際情況來進行優化，優化的方案也與硬件條件、網絡帶寬息息相關。
① QPS 達到 50
可以稱之爲小型網站，一般的服務器就可以應付。（不需要進行優化）
② QPS 達到 100
假設關係型數據庫的每次請求在 0.01秒 完成； 假設單頁面只有一個SQL查詢，那麼 100QPS 意外着 1秒鐘 完成 100次請求，但是此時我們並不能保證數據庫查詢能完成 100次； 方案：數據庫緩存層、數據庫的負載均衡。
③ QPS 達到 800
假設我們使用百兆帶寬，意味着網站出口的實際帶寬是 8M 左右； 假設每個頁面只有 10K，在這個併發條件下，百兆帶寬已經喫完； 方案：CDN加速、負載均衡。
④ QPS 達到 1000
假設使用 Memcache 緩存數據庫查詢數據，每個頁面對 Memcache 的請求遠大於直接對 DB 的請求； Memcache 的悲觀併發數在 2w 左右（Memcache 在 QPS 達到 800 的時候已經不太穩定了），但有可能在之前內網帶寬已經喫光，表現出不穩定。 方案：靜態HTML緩存。
⑤ QPS 達到 2000
這個級別下，文件系統訪問鎖都成了災難； 方案：做業務分離，分佈式存儲。
如：現在有 庫存系統 和 訂單系統，可以把這兩個系統分到不同的集羣。
2、高併發解決方案案例
1）流量優化
防盜鏈處理
把一些惡意的請求拒之問外。如：現在有A，B兩個站，A站 想用 B站 的資源，直接在頁面嵌入了一些圖片，JS，CSS，本身來說，A站並不關心B站會消耗多少流量，
但是對於B站來說，如果我們調用了B站的一些圖片，JS或者CSS，都會對它做一個HTTP請求，就會消耗流量和帶寬，
所以本身對B站來說，會有不好的影響。從另一個角度來說，也侵犯了B站的版權問題，因此在這兒，要做 防盜鏈處理，這是流量的優化。
2）前端優化
① 減少HTTP請求
假設打開一個界面，可以把一些CSS，JS文件，圖片進行合併，這樣做雖然會使文件變大，但是減少了請求的次數。
② 添加異步請求
如：不是一些很重要的數據，用戶首次請求界面的時候，先不進行展示，需要的時候再進行展示，我們可以在旁邊放一些事件，通過一些JS、jQuery等第三方庫做一些AJAX的相關的異步請求，
這樣對於HTTP請求在性能上回有一個大幅度的提升，不要一次性把數據都加載過來，這樣會對服務器造成很大的壓力。
③ 啓用瀏覽器緩存和文件壓縮
如：啓用瀏覽器 去緩存HTML文件給其設定過期時間，設定緩存文件相關的指紋等等。還可以將靜態資源文件（如：JS、image等一些前端資源）設置過期時間緩存，爲其指定過期時間，
把它緩存到瀏覽器中，這樣下一次再去訪問的時候，不需要去請求服務端，可以直接通過瀏覽器把緩存讀取出來。對於 文件壓縮，可以通過一些壓縮方式，如：把圖片壓縮的小一些，
展示的時候圖片就會下載的更快些，響應速度會加深，並且減少了流量的消耗，減少了帶寬的消耗。同時也可以啓用 Nginx 的 GCPR服務，將文件整體來說壓的小一些。
④ CDN 加速
可以把一些前端的文件，前端的資源全部都放到CDN當中，用戶過來訪問的時候，可以就近來進行訪問，從而提高訪問速度，並且從一定意義上來說，也解決了帶寬不夠用的問題，
可以把數據緩存到CDN的節點中，在用戶去訪問的時候，都會就近的選擇CDN的節點進行訪問，從一定意義上來說，就不會訪問我們真實的服務器。
⑤ 建立獨立圖片服務器
因爲本身來說，圖片服務器是比較喫I/O的，爲了解決對 I/O的損耗，可以把它與我們的 Web 服務器完全分離開，這樣 Web 服務器本身的I/O 不會被我們的圖片損耗，
然後還可以針對性的對我們的圖片服務器做一些優化，如：提高硬盤的轉速；把CPU的計算能力降低下來；把圖片服務器做一個集羣。
3）服務端優化
① 頁面靜態化
把現有的服務端的邏輯（如：PHP），把PHP的一些邏輯，PHP的一些數據，PHP最終生成的要顯示給用戶的一些HTML內容緩存起來，直接緩存成HTML代碼速度會更快，
並且對我們的CPU負載，對我們的服務器的壓力都會減小很多。
② 併發處理
如：頁面做了一些靜態化，但是靜態化會有一個過期時間，不可能永遠顯示頁面，如果是這樣創建一些動態的內容就沒有意義了，但是對於實質性要求比較高的來說，
我們可能在做一些靜態化的時候，不是特別的合理。這時需要穿透靜態化，即繞過靜態化，來直接訪問真實的數據。訪問真實數據的時候，可能就需要做一些程序上的併發處理，
如 多線程多進程的異步處理、隊列處理 等等，都可以異步完成數據的處理，從而提升請求的響應的速度，同時也提升了併發數。
③ 隊列處理
4）數據庫優化
① 數據庫緩存
- memcache 緩存
- redis 緩存等
② 分庫分表、分區操作
- 垂直拆分、水平拆分；
- 分區
③ 讀寫分離
- 把一些服務器，一些數據完全分開；
- 一些服務器做數據庫的讀操作（查詢），一些服務器做寫操作（增、刪、該）
④ 負載均衡
5）Web 服務器優化
負載均衡
- 可以使用 Nginx 的反向代理來實現負載均衡；
- 使用七層，使用四層（LVS）軟件來實現負載均衡。