redis緩存常見的問題有哪些

這篇文章主要講解了“redis緩存常見的問題有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“redis緩存常見的問題有哪些”吧！

企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的，是企業(yè)文化與產(chǎn)品對外擴(kuò)展宣傳的重要窗口，一個(gè)合格的網(wǎng)站不僅僅能為公司帶來巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺，成都創(chuàng)新互聯(lián)公司面向各種領(lǐng)域：成都酒店設(shè)計(jì)等成都網(wǎng)站設(shè)計(jì)、成都營銷網(wǎng)站建設(shè)解決方案、網(wǎng)站設(shè)計(jì)等建站排名服務(wù)。

1、什么是緩存？

緩存，就是數(shù)據(jù)交換的緩沖區(qū)，針對服務(wù)對象的不同（CPU、內(nèi)存、磁盤等）都可以構(gòu)建緩存。

目的是，把讀寫速度慢的介質(zhì)中的數(shù)據(jù)保存在讀寫速度快的介質(zhì)中，提升效率。

    例如：

        · CPU高速緩存

        · 內(nèi)存緩存

            將磁盤中常用的數(shù)據(jù)保存在內(nèi)存中。

日常業(yè)務(wù)中，我們使用比較多的數(shù)據(jù)庫是MySQL，緩存是Redis。Redis的性能比Mysql要快得多，因此我們將Mysql中的熱點(diǎn)數(shù)據(jù)，緩存到Redis中，提升讀取性能，減少數(shù)據(jù)庫壓力。

讀數(shù)據(jù)時(shí)，從redis中讀取，redis中沒有，再去mysql中讀取。

寫數(shù)據(jù)時(shí)，先寫到redis中，再定時(shí)異步回寫到redis中，或者同步回寫。

    場景：

        1、論壇帖子的訪問頻率比較高，且需要實(shí)時(shí)地更新閱讀量，可以使用Redis記錄帖子的閱讀量，提升并發(fā)度和性能

        2、商品信息，更新的頻率不高，但是讀取的頻率比較高，特別是熱門商品，因此將熱門商品信息存儲在Redis中

2、常見的緩存算法

    LRU（least recently used） 最近最少使用

    LFU（least frequently used） 最不經(jīng)常使用

    FIFO 先進(jìn)先出

3、常見的緩存工具和框架

    這里介紹的是Java環(huán)境中的

    本地緩存：

        Guava LocalCache、Ehcache、Caffeine

• Ehcache 的功能更加豐富，Caffeine 的性能要比 Guava LocalCache 好。

    分布式緩存：

        Redis、MemCache、Tair

• Redis 最為主流和常用。

4、緩存常見問題

    寫入問題：

• 緩存何時(shí)寫入？如何避免多線程環(huán)境下重讀寫入？

• 緩存如何失效？

• 緩存和DB的一致性如何保證

    經(jīng)典三連問：

•     如何避免緩存穿透？

•     如何避免緩存擊穿？

•     如何避免緩存雪崩？

5、如何避免雪崩

    實(shí)際業(yè)務(wù)中，如果緩存系統(tǒng)出現(xiàn)了問題（宕機(jī)），程序中應(yīng)該手動(dòng)捕獲這個(gè)異常，并且記錄日志，然后從數(shù)據(jù)庫查詢數(shù)據(jù)返回給用戶，這樣將不會導(dǎo)致業(yè)務(wù)不可用。但隨著而來的一個(gè)問題就是，緩存雪崩。

    緩存雪崩，是指緩存由于有些原因無法提供服務(wù)，所有請求全部抵達(dá)DB，導(dǎo)致DB負(fù)荷大增，最終掛掉的情況。

    如何解決：

        方法（1）緩存高可用

        通過搭建緩存的高可用，避免緩存掛掉導(dǎo)致無法提供服務(wù)的情況，從而降低出現(xiàn)緩存雪崩的情況的概率。

        假設(shè)我們使用Redis作緩存，可以使用Redis Sentinel或Redis Cluster實(shí)現(xiàn)高可用。

        方法（2）本地緩存    

        使用本地緩存，即使分布式緩存掛掉了，也可以將DB查詢到的結(jié)果緩存到本地，避免后續(xù)的請求全部到達(dá)DB。

        java環(huán)境中可以使用的本地緩存工具上文已經(jīng)介紹。

        方法（3）請求DB限流

        限制DB的每秒請求樹，避免DB掛掉，這樣做至少有兩個(gè)好處：

            1、可能有一部分用戶還可以使用，系統(tǒng)還沒死透

            2、未來緩存服務(wù)恢復(fù)后，系統(tǒng)可以立即恢復(fù)，無需再處理DB也掛掉的情況

    當(dāng)然，被限流的請求，最好也要有相應(yīng)的處理，走【服務(wù)降級】，提供一些默認(rèn)的值，或者友情提示。

    Java環(huán)境中可以使用Guaua RateLimiter、Sentinel、Hystrix實(shí)現(xiàn)限流功能

        方法（4）提前演練

6、如何避免緩存穿透

    緩存穿透，是指查詢緩存與數(shù)據(jù)庫中一個(gè)一定不存在的數(shù)據(jù)，由于查詢不到，將會前往數(shù)據(jù)庫中查找，同樣找不到，則不寫入緩存。這是沒意義的，也是非常消耗資源的，流量大時(shí)DB可能就掛掉了。

    要是有人利用不存在的key頻繁的攻擊我們的應(yīng)用，這就是漏洞。

    兩種解決辦法：    

        方法（1）緩存空對象

           當(dāng)從DB查詢數(shù)據(jù)為空，仍然將這個(gè)空結(jié)果緩存，使用特殊的標(biāo)識，使其和真正的數(shù)據(jù)區(qū)分開。另外，需要設(shè)置一個(gè)較短的過期時(shí)間，建議不超過五分鐘。

        適用場景：數(shù)據(jù)命中率不高、需要保證一致性的場景

        優(yōu)點(diǎn)：代碼維護(hù)簡單

        缺點(diǎn)：需要更多的內(nèi)存、數(shù)據(jù)不一致

        方法（2）BloomFilter 布隆過濾器（常用）

            在緩存服務(wù)的基礎(chǔ)上，構(gòu)建BloomFilter數(shù)據(jù)結(jié)構(gòu)，用來存儲對應(yīng)的Key是否存在的標(biāo)記，如果存在，說明該key對應(yīng)的值不為空。整個(gè)邏輯如下：

1.  根據(jù)key查詢布隆緩存。如果不存在，直接返回，如果存在，繼續(xù)向下執(zhí)行。【后續(xù)的流程，就是標(biāo)準(zhǔn)的查緩存流程】

2.  根據(jù)key查詢緩存。如果存在，直接返回。如果不存在，繼續(xù)向下執(zhí)行。

3.  根據(jù)key查詢DB，如果存在，則更新到緩存，并返回該值。

        適用場景：命中率不高、數(shù)據(jù)相對固定、實(shí)時(shí)性要求不高的場景

        優(yōu)點(diǎn)：緩存空間占用小

        缺點(diǎn)：代碼維護(hù)困難

實(shí)際場景中方案二使用比較多，因?yàn)槭?nèi)存，對緩存的負(fù)荷小。

7、Redis中不支持BloomFilter數(shù)據(jù)結(jié)構(gòu)，怎么實(shí)現(xiàn)布隆過濾器？

1.     RedisBloom

2.     Redis-Lua-scaling-bloom-filter，使用lua腳本實(shí)現(xiàn)布隆過濾器的功能

3.     Redisson BloomFilter，Java Redis庫實(shí)現(xiàn)布隆過濾器的功能

8、為什么說BloomFilter中不存在key，就可以判定緩存或數(shù)據(jù)庫中不存在對應(yīng)數(shù)據(jù)？
 

9、使用布隆過濾器應(yīng)該注意的地方

    （1）誤判。存在的不一定存在，不存在的一定不存在。由于布隆過濾器不允許刪除的特點(diǎn)這樣會導(dǎo)致，后來新增了一個(gè)數(shù)據(jù)，布隆過濾器也會一直判其不存在。

    使用布隆過濾器時(shí)，需要提前將已經(jīng)存在的key，初始化到布隆緩存中

    新增的數(shù)據(jù)的key怎么加到布隆緩存中？

10、如何避免擊穿?

    緩存擊穿，是指某個(gè)緩存中的數(shù)據(jù)過期了，恰好這時(shí)有大量請求對這個(gè)key進(jìn)行訪問。這些請求發(fā)現(xiàn)緩存已過期，就會往DB中查詢并回寫到緩存，如果請求過大可能會瞬間會壓垮DB。

        和雪崩、穿透有相似之處。

    區(qū)別：

        和雪崩的區(qū)別：前者針對某一個(gè)KEY，后者針對很多個(gè)KEY。其實(shí)在我看來也可以沒區(qū)別，都是雪崩。

        和穿透的區(qū)別：這個(gè)key在數(shù)據(jù)庫中是真實(shí)存在對應(yīng)的數(shù)據(jù)的

    解決方案：

    方案（1） 使用互斥鎖（分布式鎖）

        目的就是限制DB查詢量，只允許一個(gè)線程去查詢DB

    方案（2）手動(dòng)過期

11、如何保證緩存和DB的一致性（通常指最終一致性）？

    主要有兩種情況會導(dǎo)致緩存和DB的不一致問題

    1.并發(fā)場景下，讀取老的DB數(shù)據(jù)，更新到緩存中

        這里，主要指的是，更新 DB 數(shù)據(jù)之前，先刪除 Cache 的數(shù)據(jù)。在低并發(fā)量下沒什么問題，但是在高并發(fā)下，就會存在問題。在(刪除 Cache 的數(shù)據(jù), 和更新 DB 數(shù)據(jù))時(shí)間之間，恰好有一個(gè)請求，我們?nèi)绻褂?strong>被動(dòng)讀，因?yàn)榇藭r(shí) DB 數(shù)據(jù)還是老的，又會將老的數(shù)據(jù)寫入到 Cache 中。

    2.緩存和DB的操作，不在一個(gè)事務(wù)中，可能只有DB操作成功，緩存操作失敗，導(dǎo)致不一致

當(dāng)然，有一點(diǎn)我們要注意，緩存和 DB 的一致性，我們指的更多的是最終一致性。我們使用緩存只要是提高讀操作的性能，真正在寫操作的業(yè)務(wù)邏輯，還是以數(shù)據(jù)庫為準(zhǔn)。

解決方案:    

    方案（1）先淘汰緩存，再寫數(shù)據(jù)庫

        實(shí)現(xiàn)方案：引入分布式鎖，將并行寫變?yōu)榇┬袑?/strong>

• 在寫請求時(shí)，先淘汰緩存之前，先獲取該分布式鎖。

• 在讀請求時(shí)，發(fā)現(xiàn)緩存不存在時(shí)，先獲取分布式鎖。

    方案（2）先寫數(shù)據(jù)庫，再更新緩存

感謝各位的閱讀，以上就是“redis緩存常見的問題有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對redis緩存常見的問題有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！