關於Redis熱點key的一些思考

關於Redis熱點key的一些思考

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

什麼是熱點Key

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

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

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

如何解決?

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

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

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

熱點檢測

  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有更新操做的時候,客戶端也隨之更新。sql

主要代碼以下,監聽類負責接收到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))
}

代碼地址Github

參考文章

相關文章
相關標籤/搜索