這篇“redis中怎么應(yīng)對緩存熱key問題”文章的知識點大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Redis中怎么應(yīng)對緩存熱key問題”文章吧。

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計、成都做網(wǎng)站、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)同安,十載網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

背景

熱key是什么問題，如何導(dǎo)致的？

一般來說，我們使用的緩存Redis都是多節(jié)點的集群版，對某個key進(jìn)行讀寫時，會根據(jù)該key的hash計算出對應(yīng)的slot，根據(jù)這個slot就能找到與之對應(yīng)的分片(一個master和多個slave組成的一組redis集群)來存取該K-V。但是在實際應(yīng)用過程中，對于某些特定業(yè)務(wù)或者一些特定的時段（比如電商業(yè)務(wù)的商品秒殺活動），可能會發(fā)生大量的請求訪問同一個key。所有的請求（且這類請求讀寫比例非常高）都會落到同一個redis server上，該redis的負(fù)載就會嚴(yán)重加劇，此時整個系統(tǒng)增加新redis實例也沒有任何用處，因為根據(jù)hash算法，同一個key的請求還是會落到同一臺新機(jī)器上，該機(jī)器依然會成為系統(tǒng)瓶頸2，甚至造成整個集群宕掉，若此熱點key的value 也比較大，也會造成網(wǎng)卡達(dá)到瓶頸，這種問題稱為 “熱key” 問題。

如下圖1、2所示，分別是正常redis cluster集群和使用一層proxy代理的redis 集群key訪問。

如上所說，熱key會給集群中的少部分節(jié)點帶來超高的負(fù)載壓力，如果不正確處理，那么這些節(jié)點宕機(jī)都有可能，從而會影響整個緩存集群的運作，因此我們必須及時發(fā)現(xiàn)熱key、解決熱key問題。

1.熱key探測

熱key探測，看到由于redis集群的分散性以及熱點key帶來的一些顯著影響，我們可以通過由粗及細(xì)的思考流程來做熱點key探測的方案。

1.1 集群中每個slot的qps監(jiān)控

熱key最明顯的影響是整個redis集群中的qps并沒有那么大的前提下，流量分布在集群中slot不均的問題，那么我們可以最先想到的就是對于每個slot中的流量做監(jiān)控，上報之后做每個slot的流量對比，就能在熱key出現(xiàn)時發(fā)現(xiàn)影響到的具體slot。雖然這個監(jiān)控最為方便，但是粒度過于粗了，僅適用于前期集群監(jiān)控方案，并不適用于精準(zhǔn)探測到熱key的場景。

1.2 proxy的代理機(jī)制作為整個流量入口統(tǒng)計

如果我們使用的是圖2的redis集群proxy代理模式，由于所有的請求都會先到proxy再到具體的slot節(jié)點，那么這個熱點key的探測統(tǒng)計就可以放在proxy中做，在proxy中基于時間滑動窗口，對每個key做計數(shù)，然后統(tǒng)計出超出對應(yīng)閾值的key。為了防止過多冗余的統(tǒng)計，還可以設(shè)定一些規(guī)則，僅統(tǒng)計對應(yīng)前綴和類型的key。這種方式需要至少有proxy的代理機(jī)制，對于redis架構(gòu)有要求。

1.3 redis基于LFU的熱點key發(fā)現(xiàn)機(jī)制

redis 4.0以上的版本支持了每個節(jié)點上的基于LFU的熱點key發(fā)現(xiàn)機(jī)制，使用redis-cli –hotkeys即可，執(zhí)行redis-cli時加上–hotkeys選項。可以定時在節(jié)點中使用該命令來發(fā)現(xiàn)對應(yīng)熱點key。

如下所示，可以看到redis-cli –hotkeys的執(zhí)行結(jié)果，熱key的統(tǒng)計信息，這個命令的執(zhí)行時間較長，可以設(shè)置定時執(zhí)行來統(tǒng)計。

1.4 基于Redis客戶端做探測

由于redis的命令每次都是從客戶端發(fā)出，基于此我們可以在redis client的一些代碼處進(jìn)行統(tǒng)計計數(shù)，每個client做基于時間滑動窗口的統(tǒng)計，超過一定的閾值之后上報至server，然后統(tǒng)一由server下發(fā)至各個client，并且配置對應(yīng)的過期時間。

這個方式看起來更優(yōu)美，其實在一些應(yīng)用場景中并不是那么合適，因為在client端這一側(cè)的改造，會給運行的進(jìn)程帶來更大的內(nèi)存開銷，更直接的來說，對于Java和goLang這種自動內(nèi)存管理的語言，會更加頻繁的創(chuàng)建對象，從而觸發(fā)gc導(dǎo)致接口響應(yīng)耗時增加的問題，這個反而是不太容易預(yù)料到的事情。

最終可以通過各個公司的基建，做出對應(yīng)的選擇。

2.熱key解決

通過上述幾種方式我們探測到了對應(yīng)熱key或者熱slot，那么我們就要解決對應(yīng)的熱key問題。解決熱key也有好幾種思路可以參考，我們一個一個捋一下。

2.1 對特定key或slot做限流

一種最簡單粗暴的方式，對于特定的slot或者熱key做限流，這個方案明顯對于業(yè)務(wù)來說是有損的，所以建議只用在出現(xiàn)線上問題，需要止損的時候進(jìn)行特定的限流。

2.2 使用二級（本地）緩存

本地緩存也是一個最常用的解決方案，既然我們的一級緩存扛不住這么大的壓力，就再加一個二級緩存吧。由于每個請求都是由service發(fā)出的，這個二級緩存加在service端是再合適不過了，因此可以在服務(wù)端每次獲取到對應(yīng)熱key時，使用本地緩存存儲一份，等本地緩存過期后再重新請求，降低redis集群壓力。以java為例，guavaCache就是現(xiàn)成的工具。以下示例：

    //本地緩存初始化以及構(gòu)造
    private static LoadingCache<String, List<Object>> configCache
            = CacheBuilder.newBuilder()
            .concurrencyLevel(8)  //并發(fā)讀寫的級別，建議設(shè)置cpu核數(shù)
            .expireAfterWrite(10, TimeUnit.SECONDS)  //寫入數(shù)據(jù)后多久過期
            .initialCapacity(10) //初始化cache的容器大小
            .maximumSize(10)//cache的容器最大
            .recordStats()
            // build方法中可以指定CacheLoader，在緩存不存在時通過CacheLoader的實現(xiàn)自動加載緩存
            .build(new CacheLoader<String, List<Object>>() {
                @Override
                public List<Object> load(String hotKey) throws Exception {
                    
                }
            });
    
    //本地緩存獲取
    Object result = configCache.get(key);

本地緩存對于我們的最大的影響就是數(shù)據(jù)不一致的問題，我們設(shè)置多長的緩存過期時間，就會導(dǎo)致最長有多久的線上數(shù)據(jù)不一致問題，這個緩存時間需要衡量自身的集群壓力以及業(yè)務(wù)接受的最大不一致時間。

2.3 拆key

如何既能保證不出現(xiàn)熱key問題，又能盡量的保證數(shù)據(jù)一致性呢？拆key也是一個好的解決方案。

我們在放入緩存時就將對應(yīng)業(yè)務(wù)的緩存key拆分成多個不同的key。如下圖所示，我們首先在更新緩存的一側(cè)，將key拆成N份，比如一個key名字叫做"good_100"，那我們就可以把它拆成四份，"good_100_copy1"、"good_100_copy2"、"good_100_copy3"、"good_100_copy4"，每次更新和新增時都需要去改動這N個key，這一步就是拆key。

對于service端來講，我們就需要想辦法盡量將自己訪問的流量足夠的均勻，如何給自己即將訪問的熱key上加入后綴。幾種辦法，根據(jù)本機(jī)的ip或mac地址做hash，之后的值與拆key的數(shù)量做取余，最終決定拼接成什么樣的key后綴，從而打到哪臺機(jī)器上；服務(wù)啟動時的一個隨機(jī)數(shù)對拆key的數(shù)量做取余。

2.4 本地緩存的另外一種思路 配置中心

對于熟悉微服務(wù)配置中心的伙伴來講，我們的思路可以向配置中心的一致性轉(zhuǎn)變一下。拿nacos來舉例，它是如何做到分布式的配置一致性的，并且相應(yīng)速度很快？那我們可以將緩存類比配置，這樣去做。

長輪詢+本地化的配置。首先服務(wù)啟動時會初始化全部的配置，然后定時啟動長輪詢?nèi)ゲ樵儺?dāng)前服務(wù)監(jiān)聽的配置有沒有變更，如果有變更，長輪詢的請求便會立刻返回，更新本地配置；如果沒有變更，對于所有的業(yè)務(wù)代碼都是使用本地的內(nèi)存緩存配置。這樣就能保證分布式的緩存配置時效性與一致性。

2.5 其他可以提前做的預(yù)案

上面的每一個方案都相對獨立的去解決熱key問題，那么如果我們真的在面臨業(yè)務(wù)訴求時，其實會有很長的時間來考慮整體的方案設(shè)計。一些極端的秒殺場景帶來的熱key問題，如果我們預(yù)算充足，可以直接做服務(wù)的業(yè)務(wù)隔離、redis緩存集群的隔離，避免影響到正常業(yè)務(wù)的同時，也會可以臨時采取更好的容災(zāi)、限流措施。

一些整合的方案

目前市面上已經(jīng)有了不少關(guān)于hotKey相對完整的應(yīng)用級解決方案，其中京東在這方面有開源的hotkey工具，原理就是在client端做洞察，然后上報對應(yīng)hotkey，server端檢測到后，將對應(yīng)hotkey下發(fā)到對應(yīng)服務(wù)端做本地緩存，并且這個本地緩存在遠(yuǎn)程對應(yīng)的key更新后，會同步更新，已經(jīng)是目前較為成熟的自動探測熱key、分布式一致性緩存解決方案，京東零售熱key。

以上就是關(guān)于“Redis中怎么應(yīng)對緩存熱key問題”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對大家有幫助，若想了解更多相關(guān)的知識內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

文章題目：Redis中怎么應(yīng)對緩存熱key問題
網(wǎng)頁URL：http://www.chinadenli.net/article14/gpcige.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、網(wǎng)站維護(hù)、全網(wǎng)營銷推廣、商城網(wǎng)站、電子商務(wù)、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)