1、相關概念
併發：在操作系統中，是指一個時間段中有幾個程序都處於已啓動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一個時刻點上只有一個程序在處理機上運行；在互聯網時代，所講的併發，高併發通常是指併發訪問，也就是在某個時間點，有多少個訪問同時到來。通常一個系統的日PV在千萬以上，有可能是一個高併發的系統。有的公司完全不走技術路線，全靠機器堆，這不在討論範圍內。
QPS：每秒鐘請求或者查詢的數量，在互聯網領域，指每秒響應請求數(指HTTP請求)；併發連接數是系統同時處理的請求數量
吞吐量：單位時間內處理的請求數量(通常由QPS與併發數決定)
響應時間：從請求發出到收到響應花費的時間。例如系統處理一個HTTP請求需要100ms。
PV：綜合瀏覽量(page view)，即頁面瀏覽量或者點擊量，一個訪客在24小時內訪問的頁面數量；同一個人瀏覽網站同一頁面，只記作一次PV
UV：獨立訪客(unique visitor)，即一定時間範圍內相同訪客多次訪問網站，只計算爲一個獨立訪客
帶寬：計算帶寬大小需關注兩個指標，峯值流量和頁面的平均大小
日網站帶寬=PV/統計時間(換算到s)*平均頁面大小(單位KB)*8；峯值一般是平均值的倍數，根據實際情況來定
峯值每秒請求數(QPS)=(總PV數*80%)/(6小時秒數*20%)；80%的訪問量集中在20%的時間
壓力測試：測試能承受的最大併發，測試最大承受的QPS值
QPS達到極限：隨着QPS的增長，每個階段需要根據實際情況來進行優化，優化的方案也與硬件條件、網絡帶寬息息相關；QPS達到50，可以稱之爲小型網站，一般的服務器就可以應付；QPS達到100，假設關係型數據庫的每次請求在0.01s完成，假設單頁面只有一個SQL查詢，那麼100QPS意味着1s完成100次請求，但是此時並不能保證數據庫查詢能完成100次，數據庫緩存層，數據庫的負載均衡；QPS達到800，假設使用百兆帶寬，意味着網站出口的實際帶寬是8M左右，假設每個頁面只有10k，在這個併發條件下，百兆帶寬已經喫完，CDN加速，負載均衡；QPS達到1000，假設使用memcache緩存數據庫查詢數據，每個頁面對memcache的請求遠大於直接對db的請求，memcache的悲觀併發數在2w左右，但有可能在之前內網帶寬已經喫光，表現出不穩定，靜態HTML緩存；QPS達到2000，這個級別下，文件系統訪問鎖都成爲了災難，做業務分離，分佈式存儲高併發解決方案案例。
高併發解決方案案例
流量優化：防盜鏈處理。https://blog.csdn.net/linshichen/article/details/51679074
前端優化：減少HTTP請求，合併css或js，添加異步請求，啓用瀏覽器緩存和文件壓縮，CDN加速，建立獨立圖片服務器，
服務端優化：頁面靜態化，併發處理，隊列處理
數據庫優化：數據庫緩存，分庫分表，分區操作，讀寫分離，負載均衡
web服務器優化：負載均衡，nginx反向代理，7,4層LVS軟件
2、核心問題
併發問題核心是如何解決慢和等，核心一個是短，一個是少，一個是分流。
短是指路徑要短。典型的mvc結構是請求->controller->model->dao->view，然後把頁面返回給用戶。要想短的話，
1）頁面靜態化- 用戶可以直接獲取頁面，不用走那麼多流程，比較適用於頁面不頻繁更新。
2）使用緩存- 第一次獲取數據從數據庫準提取，然後保存在緩存中，以後就可以直接從緩存提取數據。不過需要有機制維持緩存和數據庫的一致性。
3）批量讀取 - 高併發情況下，可以把多個請求的查詢合併到一次進行，以減少數據庫的訪問次數
4）延遲修改 - 高併發情況下，可以把多次修改請求，先保存在緩存中，然後定時將緩存中的數據保存到數據庫中，風險是可能會斷電丟失緩存中的數據。
5）使用索引 - 索引可以看作是特殊的緩存，儘量使用索引就要求where字句中精確的給出索引列的值。
少是指查詢的數據要少。
1）分表 - 把本來同一張表的內容，可以按照地區，類別等分成多張表，很簡單的一個思路，但是要儘量避免分出來的多表關聯查詢。
2）分離活躍數據 - 例如登錄用戶業務，註冊用戶很多，但是活躍的登錄用戶很少，可以把活躍用戶專門保存一張表，查詢是先查詢活躍表，沒有的話再查總表，這也類似與緩存。
分流就是將原有的一個併發的流進行拆分
1）微服務
2）分佈式
3）負載均衡
https://blog.csdn.net/qq_37788067/article/details/79250623
4）讀寫分離（主從複製）
核心最重點：分流