摘要：如何解決針對于熱點的解決方案網上的查找出來無非就是兩種服務端緩存即將熱點數據緩存至服務端的內存中備份熱點即將熱點隨機數，隨機分配至其他節點中。偽代碼如下生成隨機數構造備份新從數據庫中取數據存放在中，以便下次能取到代碼地址參考文章

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

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

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

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

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

服務端緩存：即將熱點數據緩存至服務端的內存中

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

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

憑借經驗，進行預估：例如提前知道了某個活動的開啟，那么就將此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即可。

假設我們已經統計出了一些熱點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 hotKeyMap = new ConcurrentHashMap<>();
    private static List 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走到一臺機器上就行，但是我們知道在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))
}

http://mysql.taobao.org/monthly/2018/09/08/

https://www.cnblogs.com/rjzheng/p/10874537.html