緩存擊穿、緩存失效及熱點key的解決方案

　　分佈式緩存是網站服務端常常用到的一種技術，在讀多寫少的業務場景中，經過使用緩存能夠有效地支撐高併發的訪問量，對後端的數據庫等數據源作到很好地保護。如今市面上有不少分佈式緩存，好比Redis、Memcached以及阿里的Tair等，無論咱們使用的哪一種緩存產品，基本上都會遇到緩存擊穿、緩存失效以及熱點key的問題。如何有效地防止這些問題，也是咱們在享受緩存帶來的紅利的同時，必需要解決的難題。

　　一般咱們在使用緩存時都是先檢查緩存中是否存在，若是存在直接返回緩存內容，若是不存在就直接查詢數據庫而後再緩存查詢結果返回，例以下圖所示：

緩存擊穿：

描述

　　查詢一個數據庫中不存在的數據，好比商品詳情，查詢一個不存在的ID，每次都會訪問DB，若是有人惡意破壞，極可能直接對DB形成過大的壓力。

解決方案：

　　當經過某一個key去查詢數據的時候，若是對應在數據庫中的數據都不存在，咱們將此key對應的value設置爲一個默認的值，好比「NULL」，並設置一個緩存的失效時間，這時在緩存失效以前，全部經過此key的訪問都被緩存擋住了。後面若是此key對應的數據在DB中存在時，緩存失效以後，經過此key再去訪問數據，就能拿到新的value了。

緩存失效：

描述

　　在高併發的環境下，若是此時key對應的緩存失效，此時有多個進程就會去同時去查詢DB，而後再去同時設置緩存。這個時候若是這個key是系統中的熱點key或者同時失效的數量比較多時，DB訪問量會瞬間增大，形成過大的壓力。

解決方案：

　　將系統中key的緩存失效時間均勻地錯開，防止統一時間點有大量的key對應的緩存失效；
　　從新設計緩存的使用方式，當咱們經過key去查詢數據時，首先查詢緩存，若是此時緩存中查詢不到，就經過分佈式鎖進行加鎖，取得鎖的線程查DB並設置緩存，而後解鎖；其餘線程若是發現有鎖就等待，而後等解鎖後返回緩存數據或者再次查詢DB。

熱點key：

描述

　　緩存中的某些Key(可能對應用與某個促銷商品)對應的value存儲在集羣中一臺機器，使得全部流量涌向同一機器，成爲系統的瓶頸，該問題的挑戰在於它沒法經過增長機器容量來解決。

解決方案：

　　客戶端熱點key緩存：將熱點key對應value並緩存在客戶端本地，而且設置一個失效時間。對於每次讀請求，將首先檢查key是否存在於本地緩存中，若是存在則直接返回，若是不存在再去訪問分佈式緩存的機器。
將熱點key分散爲多個子key，而後存儲到緩存集羣的不一樣機器上，這些子key對應的value都和熱點key是同樣的。當經過熱點key去查詢數據時，經過某種hash算法隨機選擇一個子key，而後再去訪問緩存機器，將熱點分散到了多個子key上。