1.發現靜態熱點資料：靜態熱點資料的發現相對簡單些，是可以提前預估**的資料。比如：秒殺活動商品、降價**商品、節假日的火車票機票、熱門電影門票、明星發布新**，以及大資料分析流行趨勢**熱點。
2.發現動態熱點資料：建立非同步監控統計服務和熱點資料服務。非同步監控統計服務在乙個週期內對key進行請求統計，在達到請求量級後將熱點key傳送到熱點資料服務收集，然後熱點資料服務對這些熱點key進行聚合分析，最後推送到業務系統。
1.快取熱點資料，放入lru佇列淘汰替換。
2.對請求限制、限流，加入驗證、防刷機制，對單一key限流。
3.熔斷降級處理，返回乙個固定值。
4.熱點資料隔離，防止影響其他業務。
熱點資料寫資料庫會造成大量的執行緒來競爭鎖，會嚴重影響資料庫的響應時間。
1.將請求放入訊息佇列，順序將更新請求傳送到資料庫執行。
2.優化資料庫儲存引擎，對單行記錄併發排隊寫。（**的資料庫團隊開發了針對mysql的innodb層上的patch，可以做到資料庫層上對單行記錄做到併發排隊。innodb內部的死鎖檢測以及mysql server和innodb的切換會比較耗效能，**的mysql核心團隊還做了很多其他方面的優化，如commit_on_success和rollback_on_fail的patch，配合在sql裡面加hint，在事務裡不需要等待應用層提交commit而在資料執行完最後一條sql後直接根據target_affect_row結果提交或回滾，可以減少網路的等待時間）
3.在資料庫層面對sql限流，thread_running達到閾值拒絕執行。
4.修改資料庫innodb_thread_concurrency併發執行緒數配置，限制併發執行緒的數量，會造成大量連線等待。
5.熱點資料的動態遷移到單獨資料庫，實現難度大。
6.將熱點資料在快取更新，定時同步到資料庫，一定時間內會出現資料不一致。
關於熱點資料的思考
熱點資料會造成什麼呢 流量集中，達到物理網絡卡上限 請求過多，快取分片服務被打垮 快取雪崩 快取崩潰進而引發資料庫崩潰 請求過程 client slb proxy service layers redis db 解決思路 打散訪問流量，可以通過slb proxy 在中間層加本地快取，盡可能的返回結果...
redis如何保證資料都是熱點資料
背景 眾所周知，redis是純記憶體的操作。所以速度極快。然而記憶體的大小是有限的。如 mysql中有2000w的資料，redis中只存20w的資料，那麼如何保證redis中的資料都是熱點資料呢？答案 redis記憶體資料集達到一定大小的時候，就會實行資料淘汰策略，記憶體的淘汰機制的初衷是為了更好地...
關於保證Redis資料都是熱點資料
mysql裡有2000w資料，redis中只存20w的資料，如何保證redis中的資料都是熱點資料?redis 會根據自身資料淘汰策略，載入熱資料到記憶體。所以，計算一下 20w 資料大約占用的記憶體，然後設定一下 redis 記憶體限制即可。比如使用者資料。資料庫有2000w條。活躍使用者 red...