關於Redis熱點key的一些思考

時間 2019-12-05

標籤關於 redis 熱點 key 一些思考欄目 Redis 简体版

原文原文鏈接

關於Redis熱點key的一些思考

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

什麼是熱點Key

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

從基於用戶消費的數據遠遠大於生產的數據的角度來說，咱們日常使用的知乎等軟件時，大多數人日常僅僅只是瀏覽，並不會去提問問題、發表的文章，偶爾會發表本身的文章或者見解，這就是一個典型的讀多寫少的情景，固然此類情景不太容易致使熱點的產生。git

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

如何解決？

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

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

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

熱點檢測

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

若是要用Redis自帶命令查詢時，要注意須要先把內存逐出策略設置爲allkeys-lfu或者volatile-lfu，不然會返回錯誤。進入Redis中使用config set maxmemory-policy allkeys-lfu便可。sql

服務端緩存

假設咱們已經統計出了一些熱點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代碼塊中直接設置了兩個熱點Keybash

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))
}

複製代碼