Redis熱點大Key的優化過程

對於電商**中，我們經常可以會遇到熱門商品的搶購或者秒殺場景以及事先經過廣告投放等措施進行定向引流，這樣就會導致某個熱賣商品在短時間內湧入大量流量。

比如，雙十一期間某些熱門商品的降價**，當這其中的某一件商品被數萬次點選瀏覽或者購買時，會形成乙個較大的需求量，這種情況下就會造成熱點問題。

熱點key產生問題的原因

請求到的分片過於集中，超過單台server的效能極限。

在服務端讀資料進行訪問時，往往會對資料進行分片切分。此過程中會在某一主機server上對相應的key進行訪問，當訪問超過server極限時，就會導致熱點 key 問題的產生。

熱點key的危害

解決方式

redis使用過程中經常會有各種大key的情況，比如單個簡單的key儲存的value很大。

由於redis是單執行緒執行的，如果一次操作的value很大會對整個redis的響應時間造成負面影響，導致io網路擁塞。

將整存整取的大物件，分拆為多個小物件。可以嘗試將物件分拆成幾個key-value，使用multiget獲取值，這樣分拆的意義在於分拆單次操作的壓力，將操作壓力平攤到多個redis例項中，降低對單個redis的io影響；

在電商**的一次營銷事件中，通過相關的引流操作，將大量流量在指定時間引流到了商品搶購頁面，在搶購頁中涉及到的幾個後台介面，其中有一兩個都會去查商品資訊。

在商品模組對外暴露了乙個對條件查詢的介面，在上述的場景下就會短時間高頻次的呼叫這個介面。

根據這個場景發現，商品資料，在活動期間會有很大的訪問量，這是乙個熱點key。另外由於前期錯誤的設定導致了這個熱點key又是乙個大key。

所以我們的優化過程就是按照如果解決掉熱點key和大key的這兩個問題進行的。之前並沒有上述的概念，都是摸著石頭過河，漸漸地思路才清晰起來。

直接按條件查詢資料庫。

public listversion1(querycriteriondto querydto)

將全量資料快取到redis中，查出資料後再進行過濾返回。

public listversion2(querycriteriondto querydto)

仍然將全量資料快取到redis中，但是只快取必要的資料，比如過濾條件，從快取中拿出全部的資料後，進行過濾後列出需要返回的物件唯一id，再根據這一批唯一id去快取中查單個的物件出來，最後拼成list返回。

public listversion3(querycriteriondto querydto)

將每次的獲取單個物件的get操作，調整成mget這樣就可以一次操作取出多個物件出來，然後再跟查詢的keys比較一下size，如果少的話，再嘗試從庫中查一次，把少的資料補上。

public listversion4(querycriteriondto querydto)