秒殺系統高併發優化：系統流程 秒殺未開始【詳情頁】（各種商品資訊）包含-系統時間-倒計時；進入秒殺環節【地址暴露介面】（拿到秒殺地址）-【執行秒殺操作】-【放回結果】具體優化操作：詳情頁：使用者大量重新整理，可以將detail 頁靜態化，靜態資源css,js等部署到CDN（內容分發網路，可以是動態也可以是靜態資源，加速使用者獲取資料的系統，部署在使用者最近的網路節點，命中CDN不需要訪問後端伺服器） ,這些不需要對應我們的秒殺系統。而系統時間則可以通過伺服器呼叫，其實不需要怎麼優化，訪問速度10ns左右；秒殺地址介面分析：不適合CDN快取（地址是動態可變的） 適合redis服務端快取一致性維護成本低： 請求地址->redis->Mysal 【redis超時穿透/mysql 主動更新redis】 根據系統時間做判斷是否暴露秒殺地址秒殺操作優化分析：不適合CDN快取  後端快取問題：庫存問題  一行資料競爭【redis 中存放熱點商品的--】MySQL :update 壓力測試 一秒鐘能達到4wQPs   但是Java客戶端控制事務分析，執行update和 insert 會產生併發操作引發行鎖①update[減庫存]存在網路延遲/GC-          ②insert[購買明細】同樣會引數網路延遲/GS  同城機房：網路延遲0.5-2ms  1000QPs,存在GC 50ms  20QPs  異地機房：上海-北京 網路延遲20ms 解決方案：將客戶端邏輯放到Mysql 服務端，避免網路延遲和GC干擾1）定製SQL方案，修改MySql 原始碼    2）呼叫儲存過程：整個事物在Mysql端完成優化總結：前段控制：暴露介面，防重複按鈕     動靜態資料分離：CDN快取，後端快取  事務競爭優化：減少事務鎖時間