秒殺問題：
多人集中時間讀寫同一份庫表，讀寫沖突疯趟，鎖嚴重
優(yōu)化思路
- 將請求盡量攔截在系統(tǒng)前端
- 利用緩存
優(yōu)化細節(jié)
-
客戶端優(yōu)化
- 產(chǎn)品設計- 按鈕點擊后置灰晦譬，避免重復提交
- JS- 限制用戶在指定時間間隔提交請求次數(shù)
-
站點優(yōu)化（針對需要登錄的頁面）
- 通一uid,限制訪問頻度叭首，對uid進行控制和去重习勤，防止程序員for循環(huán)調(diào)用
比如x秒內(nèi)透過一個請求，其他請求都用頁面緩存焙格，返回統(tǒng)一頁面
- 通一uid,限制訪問頻度叭首，對uid進行控制和去重习勤，防止程序員for循環(huán)調(diào)用
-
服務層優(yōu)化
- 對于寫請求图毕，使用請求隊列，每次透有限個寫請求到數(shù)據(jù)層眷唉，多少數(shù)據(jù)透多少請求予颤，如果請求都成功囤官，其余請求返回“已無資源等等”
- 對于讀請求，上cache
-
業(yè)務規(guī)則優(yōu)化
- 分時分段等等...
- 數(shù)據(jù)粒度優(yōu)化蛤虐，比如對余量查詢党饮，如果只關心有還是無，而不關心數(shù)量驳庭，則做粗顆粒度的“有刑顺、無”緩存即可。
