背景
在面試過程中，常常會遇到對高併發場景進行提問的情況。請問，這樣的提問旨在瞭解哪些方面的信息呢？
- 技術功底：高併發確實涉及到一些底層原理和技術架構設計，有經驗者可結合實際情況作答，無經驗者則需考察其背誦能力。
- 團隊協作能力：高併發往往需要多個技術人員協同工作，包括架構、運維、測試等方面，因此需要考察應聘者的團隊協作能力。
- 應變和解決問題能力：高併發並非長期穩定的狀態，可能會因受到攻擊而突然增加，因此需要考察應聘者的應變和解決問題能力。
- 是否有離職意向：從併發量角度考慮公司盈利，如果面試公司正處於業務擴張期，訪問量激增，所以才來招聘有高併發經驗的人才，如果公司業務不行，面試官可以從面試者中篩選高併發經驗的公司，可以跑路。這個就是我瞎説，請勿當真！！！
問答
以下是一則可能的面試問答：
您能詳細闡述一下什麼是高併發嗎？其主要特性和衡量指標是什麼？
演唱會門票、商品秒殺等場景，大家都在同一時間瘋狂點擊“購買”按鈕，這些都可以理解為“高併發”。高併發的特點是大家同時進行相同操作，訪問量迅速增加，系統需快速響應。
衡量併發的一些關鍵指標包括
- QPS（Queries Per Second）: 每秒請求數，QPS值越大，説明系統處理能力越強、性能越好。
- TPS（Transactions Per Second）是每秒事務數。TPS值越大，説明系統處理能力越強、性能越好。
- RT（Response Time）: 響應時間，表示服務器從接收到請求到返回結果所消耗的時間。
- 併發用户數：同一時刻，系統能夠接待多少用户。通過全鏈路壓測來評估系統能夠承受的最大併發用户數。
- CPU/內存/IO: 這幾個硬件指標應該保持在一個合理的範圍。
對於一個高併發系統，您認為可能存在哪些瓶頸或挑戰？
常見的瓶頸或挑戰包括：硬件條件限制，數據庫瓶頸，代碼性能，緩存問題
比如數據庫併發高時候容易出現：
- 連接過多：數據庫的連接數達到上限，新的請求就無法獲取到數據庫連接，導致請求失敗。
- 數據庫查詢慢：某些查詢語句問題，導致數據庫響應速度慢。
- 數據庫鎖衝突：高併發下，事務併發操作鎖衝突的概率會增高。
如何解決
- 優化連接池：監控連接池，根據併發情況調整參數，持續監控
- SQL優化：查找出長SQL，根據SQL業務場景和SQL執行計劃進行優化。
- 數據庫讀寫分離：分離查詢和更新操作，這個需要藉助中間件的支持，比如：Java 使用 Sharding-JDBC。
- 數據庫分表分庫：根據業務場景，比如搞個活動，預計的數據表量會比較大，進行水平拆分，這個也是需要藉助中間件支持，如：Mycat
對於緩存，請問在應對高併發請求時，您有哪些需要特別關注的問題呢？
要防止緩存穿透問題：若緩存邏輯出現漏洞，攻擊者可偽造大量Key查詢不存在的數據，直接訪問數據庫，可能迅速佔據緩存導致服務崩潰。
- 參數KEY過濾：在接口層添加過濾規則，對於明顯異常的參數直接返回錯誤，比如一個正常用户的ID一般會是一個正整數，我們可以在接口層驗證，如果用户ID為非正常範圍內的數直接返回錯誤，不進行查詢。
- 緩存空對象：對於查詢不到數據的請求，也將其結果進行緩存，但是這種方案需要小心，大量的空結果可能會擠佔了我們的緩存空間，導致有效緩存的命中率降低，因此這些空結果的緩存時間需要設置得較短。
- 使用布隆過濾器：布隆過濾器是一種多哈希函數映射的位數組結構，它能判斷一個元素是否在一個集合裏面，而且不會返回誤判。
您是否考慮過將部分任務異步處理，如何合理運用線程池？
我會根據不同的業務場景去創建不同的線程池
- 未支付訂單超時自動取消，我使用ScheduledThreadPool 來處理。
- 實時順序寫入日誌，我使用SingleThreadExecutor 來處理。
- 訂單狀態變化推送通知和數據同步，我使用 CachedThreadPool 來處理，不過我們也需要控制線程數量，避免大量任務導致系統資源耗盡。
您是否瞭解過負載均衡策略，以及它們在何種場景下適用？
- 輪詢（Round Robin）：這是最簡單的負載均衡策略，就是按順序把請求分配到服務器列表中的每一台服務器，然後再回到列表的開頭重新開始這個過程。這種策略適用於所有服務器的硬件配置都相同，處理能力差異較小的場景。
- 隨機（Random）：隨機策略就是完全隨機地選擇一個服務器進行處理。這個策略適用於服務器羣裏每台服務器的性能都相當，且服務器數量相對較多的情況。
- 最少連接（Least Connections）：此策略會把請求分配給當前連接數最少的服務器。適用於每個請求處理時間較長，或者處理時間差異較大的場景。
- IP Hash：根據請求的IP地址進行哈希計算，然後根據計算結果把請求分配給固定的一台服務器，保證同一IP的客户端請求總是訪問同一台服務器。這個策略適用於需要會話保持的場景，例如電商網站的購物車功能。
- 權重（Weighted）：權重策略允許我們根據服務器的處理能力，指定請求分配的比例。比如某台服務器性能是其他服務器的兩倍，那就可以設置其處理請求的權重也是其他的兩倍。
- 資源使用率（Resource Utilization）：根據服務器當前的資源使用情況，如CPU、內存或磁盤等，將請求分發到資源利用率最低的服務器。這個策略適用於服務器硬件配置差異較大，或者處理請求的資源消耗率差異較大的場景。
總結
高併發場景系統設計主要結合以下方法進行，但是什麼萬能方案可以解決所有的高併發問題，基本都要結合業務場景和公司當前系統的架構硬件基礎展開設計。
- 橫向擴展：也就是增加更多的服務器節點，來分攤這個突增的流量。
- 使用負載均衡：通過負載均衡策略，將流量合理地分配到各個服務器上，防止某一台服務器壓力過大而崩潰。
- 使用CDN加速：通過CDN加速靜態內容的訪問，減輕源站的壓力。
- 數據庫分庫分表：對數據庫進行優化，分庫分表，提高數據庫查詢的效率，降低單一庫表的讀寫壓力。
- 使用緩存：使用Redis或Memcached這樣的緩存技術，將經常訪問的數據（如首頁熱銷商品）緩存在內存中，加快訪問速度。
