最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

高并發(fā)技巧之Redis和本地緩存使用技巧分享

 更新時間:2022年10月28日 16:34:52   作者:可以回家加班嗎  
在這篇文章中,我主要介紹的是分布式緩存和本地緩存的使用技巧,包括緩存種類介紹,各種的使用場景,以及如何使用,最后再給出實戰(zhàn)案例,需要的可以參考一下

眾所周知,緩存最主要的目的就是加速訪問,緩解數(shù)據(jù)庫壓力。最常用的緩存就是分布式緩存,比如redis,在面對大部分并發(fā)場景或者一些中小型公司流量沒有那么高的情況,使用redis基本都能解決了。但是在流量較高的情況下可能得使用到本地緩存了,比如guava的LoadingCache和快手開源的ReloadableCache。

三種緩存的使用場景

這部分會介紹redis,比如guava的LoadingCache和快手開源的ReloadableCache的使用場景和局限,通過這一部分的介紹就能知道在怎樣的業(yè)務場景下應該使用哪種緩存,以及為什么。

Redis的使用場景和局限性

如果寬泛的說redis何時使用,那么自然就是用戶訪問量過高的地方使用,從而加速訪問,并且緩解數(shù)據(jù)庫壓力。如果細分的話,還得分為單節(jié)點問題和非單節(jié)點問題。

如果一個頁面用戶訪問量比較高,但是訪問的不是同一個資源。比如用戶詳情頁,訪問量比較高,但是每個用戶的數(shù)據(jù)都是不一樣的,這種情況顯然只能用分布式緩存了,如果使用redis,key為用戶唯一鍵,value則是用戶信息。

redis導致的緩存擊穿

但是需要注意一點,一定要設置過期時間,而且不能設置到同一時間點過期。舉個例子,比如用戶又個活動頁,活動頁能看到用戶活動期間獲獎數(shù)據(jù),粗心的人可能會設置用戶數(shù)據(jù)的過期時間點為活動結(jié)束,這樣會

單(熱)點問題

單節(jié)點問題說的是redis的單個節(jié)點的并發(fā)問題,因為對于相同的key會落到redis集群的同一個節(jié)點上,那么如果對這個key的訪問量過高,那么這個redis節(jié)點就存在并發(fā)隱患,這個key就稱為熱key。

如果所有用戶訪問的都是同一個資源,比如小愛同學app首頁對所有用戶展示的內(nèi)容都一樣(初期),服務端給h5返回的是同一個大json,顯然得使用到緩存。首先我們考慮下用redis是否可行,由于redis存在單點問題,如果流量過大的話,那么所有用戶的請求到達redis的同一個節(jié)點,需要評估該節(jié)點能否抗住這么大流量。我們的規(guī)則是,如果單節(jié)點qps達到了千級別就要解決單點問題了(即使redis號稱能抗住十萬級別的qps),最常見的做法就是使用本地緩存。顯然小愛app首頁流量不過百,使用redis是沒問題的。

LoadingCache的使用場景和局限性

對于這上面說的熱key問題,我們最直接的做法就是使用本地緩存,比如你最熟悉的guava的LoadingCache,但是使用本地緩存要求能夠接受一定的臟數(shù)據(jù),因為如果你更新了首頁,本地緩存是不會更新的,它只會根據(jù)一定的過期策略來重新加載緩存,不過在我們這個場景是完全沒問題的,因為一旦在后臺推送了首頁后就不會再去改變了。即使改變了也沒問題,可以設置寫過期為半小時,超過半小時重新加載緩存,這種短時間內(nèi)的臟數(shù)據(jù)我們是可以接受的。

LoadingCache導致的緩存擊穿

雖然說本地緩存和機器上強相關(guān)的,雖然代碼層面寫的是半小時過期,但由于每臺機器的啟動時間不同,導致緩存的加載時間不同,過期時間也就不同,也就不會所有機器上的請求在同一時間緩存失效后都去請求數(shù)據(jù)庫。但是對于單一一臺機器也是會導致緩存穿透的,假如有10臺機器,每臺1000的qps,只要有一臺緩存過期就可能導致這1000個請求同時打到了數(shù)據(jù)庫。這種問題其實比較好解決,但是容易被忽略,也就是在設置LoadingCache的時候使用LoadingCache的load-miss方法,而不是直接判斷cache.getIfPresent()== null然后去請求db;前者會加虛擬機層面的鎖,保證只有一個請求打到數(shù)據(jù)庫去,從而完美的解決了這個問題。

但是,如果對于實時性要求較高的情況,比如有段時間要經(jīng)常做活動,我要保證活動頁面能近實時更新,也就是運營在后臺配置好了活動信息后,需要在C端近實時展示這次配置的活動信息,此時使用LoadingCache肯定就不能滿足了。

ReloadableCache的使用場景和局限性

對于上面說的LoadingCache不能解決的實時問題,可以考慮使用ReloadableCache,這是快手開源的一個本地緩存框架,最大的特點是支持多機器同時更新緩存,假設我們修改了首頁信息,然后請求打到的是A機器,這個時候重新加載ReloadableCache,然后它會發(fā)出通知,監(jiān)聽了同一zk節(jié)點的其他機器收到通知后重新更新緩存。使用這個緩存一般的要求是將全量數(shù)據(jù)加載到本地緩存,所以如果數(shù)據(jù)量過大肯定會對gc造成壓力,這種情況就不能使用了。由于小愛同學首頁這個首頁是帶有狀態(tài)的,一般online狀態(tài)的就那么兩個,所以完全可以使用ReloadableCache來只裝載online狀態(tài)的首頁。

小結(jié)

到這里三種緩存基本都介紹完了,做個小結(jié):

  • 對于非熱點的數(shù)據(jù)訪問,比如用戶維度的數(shù)據(jù),直接使用redis即可;
  • 對于熱點數(shù)據(jù)的訪問,如果流量不是很高,無腦使用redis即可;
  • 對于熱點數(shù)據(jù),如果允許一定時間內(nèi)的臟數(shù)據(jù),使用LoadingCache即可;
  • 對于熱點數(shù)據(jù),如果一致性要求較高,同時數(shù)據(jù)量不大的情況,使用ReloadableCache即可;

小技巧

不管哪種本地緩存雖然都帶有虛擬機層面的加鎖來解決擊穿問題,但是意外總有可能以你意想不到的方式發(fā)生,保險起見你可以使用兩級緩存的方式即本地緩存+redis+db。

緩存使用的簡單介紹

這里redis的使用就不再多說了,相信很多人對api的使用比我還熟悉

LoadingCache的使用

這個是guava提供的網(wǎng)上一抓一大把,但是給兩點注意事項

  • 要使用load-miss的話, 要么使用V get(K key, Callable<? extends V> loader);要么使用build的時候使用的是build(CacheLoader<? super K1, V1> loader)這個時候可以直接使用get()了。此外建議使用load-miss,而不是getIfPresent==null的時候再去查數(shù)據(jù)庫,這可能導致緩存擊穿;
  • 使用load-miss是因為這是線程安全的,如果緩存失效的話,多個線程調(diào)用get的時候只會有一個線程去db查詢,其他線程需要等待,也就是說這是線程安全的。
LoadingCache<String, String> cache = CacheBuilder.newBuilder()
                .maximumSize(1000L)
                .expireAfterAccess(Duration.ofHours(1L)) // 多久不訪問就過期
                .expireAfterWrite(Duration.ofHours(1L))  // 多久這個key沒修改就過期
                .build(new CacheLoader<String, String>() {
                    @Override
                    public String load(String key) throws Exception {
                        // 數(shù)據(jù)裝載方式,一般就是loadDB
                        return key + " world";
                    }
                });
String value = cache.get("hello"); // 返回hello world

reloadableCache的使用

導入三方依賴

<dependency>
  <groupId>com.github.phantomthief</groupId>
  <artifactId>zknotify-cache</artifactId>
  <version>0.1.22</version>
</dependency>

需要看文檔,不然無法使用,有興趣自己寫一個也行的。

public interface ReloadableCache<T> extends Supplier<T> {

    /**
     * 獲取緩存數(shù)據(jù)
     */
    @Override
    T get();

    /**
     * 通知全局緩存更新
     * 注意:如果本地緩存沒有初始化,本方法并不會初始化本地緩存并重新加載
     *
     * 如果需要初始化本地緩存,請先調(diào)用 {@link ReloadableCache#get()}
     */
    void reload();

    /**
     * 更新本地緩存的本地副本
     * 注意:如果本地緩存沒有初始化,本方法并不會初始化并刷新本地的緩存
     *
     * 如果需要初始化本地緩存,請先調(diào)用 {@link ReloadableCache#get()}
     */
    void reloadLocal();
}

老生常談的緩存擊穿/穿透/雪崩問題

這三個真的是亙古不變的問題,如果流量大確實需要考慮。

緩存擊穿

簡單說就是緩存失效,導致大量請求同一時間打到了數(shù)據(jù)庫。對于緩存擊穿問題上面已經(jīng)給出了很多解決方案了。

  • 比如使用本地緩存
  • 本地緩存使用load-miss方法
  • 使用第三方服務來加載緩存

1.2和都說過,主要來看3。假如業(yè)務愿意只能使用redis而無法使用本地緩存,比如數(shù)據(jù)量過大,實時性要求比較高。那么當緩存失效的時候就得想辦法保證只有少量的請求打到數(shù)據(jù)庫。很自然的就想到了使用分布式鎖,理論上說是可行的,但實際上存在隱患。我們的分布式鎖相信很多人都是使用redis+lua的方式實現(xiàn)的,并且在while中進行了輪訓,這樣請求量大,數(shù)據(jù)多的話會導致無形中讓redis成了隱患,并且占了太多業(yè)務線程,其實僅僅是引入了分布式鎖就加大了復雜度,我們的原則就是能不用就不用。

那么我們是不是可以設計一個類似分布式鎖,但是更可靠的rpc服務呢?當調(diào)用get方法的時候這個rpc服務保證相同的key打到同一個節(jié)點,并且使用synchronized來進行加鎖,之后完成數(shù)據(jù)的加載。在快手提供了一個叫cacheSetter的框架。下面提供一個簡易版,自己寫也很容易實現(xiàn)。

import com.google.common.collect.Lists;
import org.apache.commons.collections4.CollectionUtils;

import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.CountDownLatch;

/**
 * @Description 分布式加載緩存的rpc服務,如果部署了多臺機器那么調(diào)用端最好使用id做一致性hash保證相同id的請求打到同一臺機器。
 **/
public abstract class AbstractCacheSetterService implements CacheSetterService {

    private final ConcurrentMap<String, CountDownLatch> loadCache = new ConcurrentHashMap<>();

    private final Object lock = new Object();

    @Override
    public void load(Collection<String> needLoadIds) {
        if (CollectionUtils.isEmpty(needLoadIds)) {
            return;
        }
        CountDownLatch latch;
        Collection<CountDownLatch> loadingLatchList;
        synchronized (lock) {
            loadingLatchList = excludeLoadingIds(needLoadIds);

            needLoadIds = Collections.unmodifiableCollection(needLoadIds);

            latch = saveLatch(needLoadIds);
        }
        System.out.println("needLoadIds:" + needLoadIds);
        try {
            if (CollectionUtils.isNotEmpty(needLoadIds)) {
                loadCache(needLoadIds);
            }
        } finally {
            release(needLoadIds, latch);
            block(loadingLatchList);
        }

    }

    /**
     * 加鎖
     * @param loadingLatchList 需要加鎖的id對應的CountDownLatch
     */
    protected void block(Collection<CountDownLatch> loadingLatchList) {
        if (CollectionUtils.isEmpty(loadingLatchList)) {
            return;
        }
        System.out.println("block:" + loadingLatchList);
        loadingLatchList.forEach(l -> {
            try {
                l.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
    }

    /**
     * 釋放鎖
     * @param needLoadIds 需要釋放鎖的id集合
     * @param latch 通過該CountDownLatch來釋放鎖
     */
    private void release(Collection<String> needLoadIds, CountDownLatch latch) {
        if (CollectionUtils.isEmpty(needLoadIds)) {
            return;
        }
        synchronized (lock) {
            needLoadIds.forEach(id -> loadCache.remove(id));
        }
        if (latch != null) {
            latch.countDown();
        }
    }

    /**
     * 加載緩存,比如根據(jù)id從db查詢數(shù)據(jù),然后設置到redis中
     * @param needLoadIds 加載緩存的id集合
     */
    protected abstract void loadCache(Collection<String> needLoadIds);

    /**
     * 對需要加載緩存的id綁定CountDownLatch,后續(xù)相同的id請求來了從map中找到CountDownLatch,并且await,直到該線程加載完了緩存
     * @param needLoadIds 能夠正在去加載緩存的id集合
     * @return 公用的CountDownLatch
     */
    protected CountDownLatch saveLatch(Collection<String> needLoadIds) {
        if (CollectionUtils.isEmpty(needLoadIds)) {
            return null;
        }
        CountDownLatch latch = new CountDownLatch(1);
        needLoadIds.forEach(loadId -> loadCache.put(loadId, latch));
        System.out.println("loadCache:" + loadCache);
        return latch;
    }

    /**
     * 哪些id正在加載數(shù)據(jù),此時持有相同id的線程需要等待
     * @param ids 需要加載緩存的id集合
     * @return 正在加載的id所對應的CountDownLatch集合
     */
    private Collection<CountDownLatch> excludeLoadingIds(Collection<String> ids) {
        List<CountDownLatch> loadingLatchList = Lists.newArrayList();
        Iterator<String> iterator = ids.iterator();
        while (iterator.hasNext()) {
            String id = iterator.next();
            CountDownLatch latch = loadCache.get(id);
            if (latch != null) {
                loadingLatchList.add(latch);
                iterator.remove();
            }
        }
        System.out.println("loadingLatchList:" + loadingLatchList);
        return loadingLatchList;
    }
}

業(yè)務實現(xiàn)

import java.util.Collection;
public class BizCacheSetterRpcService extends AbstractCacheSetterService {
    @Override
    protected void loadCache(Collection<String> needLoadIds) {
        // 讀取db進行處理
   	// 設置緩存
    }
}

緩存穿透

簡單來說就是請求的數(shù)據(jù)在數(shù)據(jù)庫不存在,導致無效請求打穿數(shù)據(jù)庫。

解法也很簡單,從db獲取數(shù)據(jù)的方法(getByKey(K key))一定要給個默認值。

比如我有個獎池,金額上限是1W,用戶完成任務的時候給他發(fā)筆錢,并且使用redis記錄下來,并且落表,用戶在任務頁面能實時看到獎池剩余金額,在任務開始的時候顯然獎池金額是不變的,redis和db里面都沒有發(fā)放金額的記錄,這就導致每次必然都去查db,對于這種情況,從db沒查出來數(shù)據(jù)應該緩存?zhèn)€值0到緩存。

緩存雪崩

就是大量緩存集中失效打到了db,當然肯定都是一類的業(yè)務緩存,歸根到底是代碼寫的有問題??梢詫⒕彺媸У倪^期時間打散,別讓其集中失效就可以了。

以上就是高并發(fā)技巧之Redis和本地緩存使用技巧分享的詳細內(nèi)容,更多關(guān)于Redis本地緩存的資料請關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • 在Mac OS上安裝Vagrant和Docker的教程

    在Mac OS上安裝Vagrant和Docker的教程

    這篇文章主要介紹了在Mac OS上安裝Vagrant和Docker的教程,并安裝和設置Postgres和Elasticsearch和Redis,需要的朋友可以參考下
    2015-04-04
  • 使用redis分布式鎖解決并發(fā)線程資源共享問題

    使用redis分布式鎖解決并發(fā)線程資源共享問題

    這篇文章主要介紹了使用redis分布式鎖解決并發(fā)線程資源共享問題,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下
    2019-07-07
  • Redis客戶端及服務端的安裝教程詳解

    Redis客戶端及服務端的安裝教程詳解

    這篇文章主要介紹了Redis客戶端及服務端的安裝教程,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2020-11-11
  • 基于Redis緩存數(shù)據(jù)常見的三種問題及解決

    基于Redis緩存數(shù)據(jù)常見的三種問題及解決

    這篇文章主要介紹了基于Redis緩存數(shù)據(jù)常見的三種問題及解決方案,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2022-06-06
  • redis分布式鎖與zk分布式鎖的對比分析

    redis分布式鎖與zk分布式鎖的對比分析

    這篇文章主要介紹了redis分布式鎖與zk分布式鎖的對比分析,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2022-11-11
  • Redis主從復制分步講解使用

    Redis主從復制分步講解使用

    Redis因為其高性能和易用性在我們后端的服務中發(fā)揮了巨大的作用,并且很多重要功能的實現(xiàn)都會依賴redis,本篇我們來了解Redis高可用主從復制,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習吧
    2022-09-09
  • Redis實現(xiàn)分布式鎖的幾種方法總結(jié)

    Redis實現(xiàn)分布式鎖的幾種方法總結(jié)

    這篇文章主要介紹了Redis實現(xiàn)分布式鎖的幾種方法總結(jié)的相關(guān)資料, Redis實現(xiàn)與Zookeeper實現(xiàn)和數(shù)據(jù)庫實現(xiàn),需要的朋友可以參考下
    2017-07-07
  • redis哈希和集合_動力節(jié)點Java學院整理

    redis哈希和集合_動力節(jié)點Java學院整理

    這篇文章主要為大家詳細介紹了redis哈希和集合的相關(guān)資料,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2017-08-08
  • 使用Redis實現(xiàn)向量相似度搜索

    使用Redis實現(xiàn)向量相似度搜索

    在自然語言處理領(lǐng)域,有一個常見且重要的任務就是文本相似度搜索,所以本文為大家介紹一下如何利用Redis實現(xiàn)向量相似度搜索,解決文本、圖像和音頻之間的相似度匹配問題,需要的可以了解下
    2023-07-07
  • Redis實現(xiàn)每日簽到功能(大數(shù)據(jù)量)

    Redis實現(xiàn)每日簽到功能(大數(shù)據(jù)量)

    在面對百萬級用戶簽到情況下,傳統(tǒng)數(shù)據(jù)庫存儲和判斷會遇到瓶頸,使用Redis的二進制數(shù)據(jù)類型可實現(xiàn)高效的簽到功能,示例代碼展示了如何調(diào)用這些功能,包括當天簽到、補簽以及查詢簽到記錄,PHP結(jié)合Redis二進制數(shù)據(jù)類型可有效處理大數(shù)據(jù)量下的簽到問題
    2024-10-10

最新評論

微山县| 万荣县| 衡阳市| 拜城县| 塘沽区| 上虞市| 曲水县| 贵德县| 灌云县| 桦川县| 水城县| 三亚市| 庆城县| 祥云县| 英吉沙县| 同德县| 嘉禾县| 靖安县| 江山市| 万全县| 定西市| 临朐县| 云林县| 惠东县| 成安县| 宝坻区| 安庆市| 贵州省| 常州市| 红河县| 石家庄市| 南宁市| 嘉祥县| 沙田区| 河曲县| 湄潭县| 裕民县| 沅江市| 双桥区| 浪卡子县| 桃源县|