關於Redis緩存預熱的思考

系統上線時，提早將相關的緩存數據直接加載到緩存系統。避免在用戶請求的時候，先查詢數據庫，而後再將數據緩存的問題。

這裏我考慮2個問題：

A、哪些數據須要預熱？

B、如何預熱？

 

關於問題A，根據不一樣的業務系統有不一樣的方法。

1. 能夠將已知的熱門數據加載到Redis，這種方法適合於基本不變化的數據；
2. 使用redis-faina（https://github.com/facebookarchive/redis-faina.git）實時監控Redis熱key，可是由於redis-faina是經過調用Redis的monitor命令來實現的，可能下降Redis50%左右的性能，因此須要根據實際狀況評估；
3. 在proxy層，對每一個請求進行收集上報，弊端就是須要修改proxy的代碼，須要考慮開發成本和穩定性問題；
4. Redis-cli --hotkyes 查詢熱點key，只適用於緩存淘汰策略是lfu的時候（https://yq.aliyun.com/articles/278922）；
5. TCP消息抓包，例如ELK體系下的packetbeat插件(https://www.elastic.co/guide/en/beats/packetbeat/current/index.html)，能夠實現對Redis、MySQL等衆多主流服務的數據包抓取、分析、報表展現；
6. 客戶端上報，例如nginx+lua將訪問量上報到kafka中，而後進行統計

 

關於如何預熱：

找出了熱點key以後，再根據本身的業務邏輯，到DB中查詢數據填充到Redis中去。不過既然考慮預熱，那麼訪問量、數據量都會很大，所以要考慮並行（提升預熱速度）+ 限速（併發量太大的話，DB也處理不過來）。

 

 

 參考連接：

https://jzuekk.com/page/redis_6.html 

https://elasticsearch.cn/topic/PacketBeat