關於Redis熱點key的一些思考

昨天在和一個已經跳槽的同事聊天時，詢問他這段時間面試時碰到的一些問題。自己也想積累一下這方面的知識。其中他說了在面試某贊公司時面試官問他關於熱點Key的的解決方案。於是針對這次談話以及上網查的一些資料後的思考進行一下總結。方便後續自己查閱。

什麼是熱點Key

其實對於熱點Key，網上一查一大堆，這裡我就引用網上的一段話。

從基於用戶消費的數據遠遠大於生產的數據的角度來講，我們平常使用的知乎等軟體時，大多數人平常僅僅只是瀏覽，並不會去提問問題、發表的文章，偶爾會發表自己的文章或者看法，這就是一個典型的讀多寫少的情景，當然此類情景不太容易導致熱點的產生。

在日常工作生活中一些突發的的事件，諸如：“雙11”期間某些熱門商品的降價促銷，當這其中的某一件商品被數萬次點擊、購買時，會形成一個較大的需求量，這種情況下就會產生一個單一的Key，這樣就會引起一個熱點；同理，當被大量刊發、瀏覽的熱點新聞，熱點評論等也會產生熱點；另外，在服務端讀數據進行訪問時，往往會對數據進行分片切分，此類過程中會在某一主機Server上對相應的Key進行訪問，當訪問超過主機Server極限時，就會導致熱點Key問題的產生。

如何解決？

針對於熱點Key的解決方案網上的查找出來無非就是兩種

• 服務端緩存：即將熱點數據緩存至服務端的記憶體中
• 備份熱點Key：即將熱點Key+隨機數，隨機分配至Redis其他節點中。這樣訪問熱點key的時候就不會全部命中到一臺機器上了。

其實這兩個解決方案前提都是知道了熱點Key是什麼的情況，那麼如何找到熱點key呢？

熱點檢測

1. 憑藉經驗，進行預估：例如提前知道了某個活動的開啟，那麼就將此Key作為熱點Key
2. 客戶端收集：在操作Redis之前對數據進行統計
3. 抓包進行評估：Redis使用TCP協議與客戶端進行通信，通信協議採用的是RESP，所以能進行攔截包進行解析
4. 在proxy層，對每一個 redis 請求進行收集上報
5. Redis自帶命令查詢：Redis4.0.4版本提供了redis-cli –hotkeys就能找出熱點Key

如果要用Redis自帶命令查詢時，要註意需要先把記憶體逐出策略設置為allkeys-lfu或者volatile-lfu，否則會返回錯誤。進入Redis中使用config set maxmemory-policy allkeys-lfu即可。

服務端緩存

假設我們已經統計出了一些熱點Key，將這些數據緩存到了服務端，那麼還有一個問題。就是如何保證Redis和服務端熱點Key的數據一致性。我這裡想到的解決方案是利用Redis自帶的消息通知機制，對於熱點Key客戶端建立一個監聽，當熱點Key有更新操作的時候，客戶端也隨之更新。

主要代碼如下，監聽類負責接收到Redis的事件，然後篩選出熱點Key進行相應的動作

public class KeyExpiredEventMessageListener implements MessageListener {

    @Autowired
    private RedisTemplate redisTemplate;

    @Override
    public void onMessage(Message message, byte[] pattern) {
        String key = new String(message.getChannel());
        key = key.substring(key.indexOf(":")+1);
        String action = new String(message.getBody());
        if (HotKey.containKey(key)){
            String value = redisTemplate.opsForValue().get(key)+"";
            switch (action){
                case "set":
                    log.info("熱點Key:{} 修改",key);
                    HotKeyAction.UPDATE.action(key,value);
                    break;
                case "expired":
                    log.info("熱點Key:{} 到期刪除",key);
                    HotKeyAction.REMOVE.action(key,null);
                    break;
                case "del":
                    log.info("熱點Key:{} 刪除",key);
                    HotKeyAction.REMOVE.action(key,null);
                    break;
            }
        }
    }
}

建立一個存儲熱點Key的數據結構ConcurrentHashMap，並設置相應的操作方法，這裡設置了假數據，在static代碼塊中直接設置了兩個熱點Key

public class HotKey {

    private static Map<String,String> hotKeyMap = new ConcurrentHashMap<>();
    private static List<String> hotKeyList = new CopyOnWriteArrayList<>();

    static {
        setHotKey("hu1","1");
        setHotKey("hu2","2");
    }

    public static void setHotKey(String key,String value){
        hotKeyMap.put(key,value);
        hotKeyList.add(key);
    }

    public static void updateHotKey(String key,String value){
        hotKeyMap.put(key,value);
    }

    public static String getHotValue(String key){
        return hotKeyMap.get(key);
    }

    public static void removeHotKey(String key){
        hotKeyMap.remove(key);
    }

    public static boolean containKey(String key){
        return hotKeyList.contains(key);
    }
}

其實用Redis的事件通知機制挺不好的，因為只要開啟了事件通知，那麼每個Key的變化都會發消息，這樣也會平白無故的加重Redis伺服器的負擔。當然我只是簡單的演示一下，除了這種通知方案以外還有很多種方法。

備份熱點Key

這個方案說起來其實也很簡單，就是不要讓key走到一臺機器上就行，但是我們知道在Redis集群中包含了16384個哈希槽(Hash slot)，集群使用公式CRC16(key) % 16384來計算Key屬於哪個槽。那麼同一個Key計算出來的值應該都是一樣的，如何將Key分到其他機器上呢？只要再後面加上隨機數就行了，這樣就能保證同一個Key分佈在不同機器上，在訪問的時候通過Key+隨機數的方式進行訪問。

偽代碼如下

const M = N * 2
//生成隨機數
random = GenRandom(0, M)
//構造備份新key
bakHotKey = hotKey + “_” + random
data = redis.GET(bakHotKey)
if data == NULL {
     //從資料庫中取數據
    data = GetFromDB()
    //存放在Redis中，以便下次能取到
    redis.SET(bakHotKey, expireTime + GenRandom(0,5))
}

寫在最後