場(chǎng)景1: 中小型公司Redis緩存架構(gòu)以及線上問(wèn)題實(shí)戰(zhàn)

線程A在master獲取鎖之后，master在同步數(shù)據(jù)到slave時(shí)，master突然宕機(jī)(此時(shí)數(shù)據(jù)還沒(méi)有同步到slave)，然后slave會(huì)自動(dòng)選舉成為新的master，此時(shí)線程B獲取鎖，結(jié)果成功了，這樣會(huì)造成多個(gè)線程獲取同一把鎖

解決方案

• 網(wǎng)上說(shuō)RedLock能解決分布式鎖失效的問(wèn)題。對(duì)于RedLock實(shí)現(xiàn)原理是: 超過(guò)半數(shù)Redis節(jié)點(diǎn)加鎖成功之后才能算成功，否則返回false，和Zookeeper的"ZAB"原理很類(lèi)似，而且與Redis Cluster集群中解決腦裂問(wèn)題的方案類(lèi)似，但是RedLock方案有很大的弊端，也就是會(huì)造成Redis可用性的延遲，眾所周知，Redis的AP(可用性+分區(qū)容忍性)機(jī)制，假如把Redis變成CP(一致性+分區(qū)容忍性)，這樣肯定會(huì)犧牲一定的可用性，與Redis初衷不符合，也就是說(shuō)還不如使用Zookeeper。
• Zookeeper具備CP機(jī)制以及實(shí)現(xiàn)了ZAB，能夠確保某一個(gè)節(jié)點(diǎn)宕機(jī)，也能保證數(shù)據(jù)一致性，而且效率會(huì)比Redis高很多，更適合做分布式鎖

場(chǎng)景2: 大廠線上大規(guī)模商品緩存數(shù)據(jù)冷熱分離實(shí)戰(zhàn)

問(wèn)題: 在高并發(fā)場(chǎng)景下，一定要把所有的緩存數(shù)據(jù)一直保存在緩存不讓其失效嗎？

雖然一直緩存所有數(shù)據(jù)沒(méi)什么大問(wèn)題，但是考慮到如果數(shù)據(jù)太多，就會(huì)一直占用緩存空間(內(nèi)存資源非常寶貴)，并且數(shù)據(jù)的維護(hù)性也是需要耗時(shí)的.

解決方案

• 對(duì)緩存數(shù)據(jù)做冷熱分離。在查詢數(shù)據(jù)時(shí)，我們只需要在查詢代碼中再次更新過(guò)期時(shí)間，這樣就能保證熱點(diǎn)數(shù)據(jù)一直在緩存中，而不經(jīng)常訪問(wèn)的數(shù)據(jù)過(guò)期了就自動(dòng)從緩存中刪除。

流程分析

• 假如一個(gè)熱點(diǎn)數(shù)據(jù)每天訪問(wèn)特別高，不停的查詢?cè)摂?shù)據(jù)，每次查詢時(shí)再次更新過(guò)期時(shí)間，那么在這個(gè)過(guò)期時(shí)間之內(nèi)只要有人訪問(wèn)就會(huì)一直存在緩存中，這樣就保證熱點(diǎn)商品數(shù)據(jù)不會(huì)因?yàn)檫^(guò)期時(shí)間而從緩存中移除；
• 而對(duì)于不經(jīng)常訪問(wèn)的冷門(mén)數(shù)據(jù)到了過(guò)期時(shí)間就可以自動(dòng)釋放了，同時(shí)也釋放除了一部分緩存空間，而且當(dāng)再次訪問(wèn)冷門(mén)數(shù)據(jù)的時(shí)候，從數(shù)據(jù)庫(kù)拿到的永遠(yuǎn)是最新的數(shù)據(jù)，也減少了維護(hù)成本。

場(chǎng)景3: 基于DCL機(jī)制解決熱點(diǎn)緩存并發(fā)重建問(wèn)題實(shí)戰(zhàn)

DCL(雙重檢測(cè)鎖)

問(wèn)題: 冷門(mén)數(shù)據(jù)突然變成了熱門(mén)數(shù)據(jù)，大量的請(qǐng)求突發(fā)性的對(duì)熱點(diǎn)數(shù)據(jù)進(jìn)行緩存重建導(dǎo)致系統(tǒng)壓力暴增

解決方案

• 最容易想到的就是加鎖
• DCL機(jī)制。先查一次，緩存有數(shù)據(jù)就直接返回，沒(méi)有數(shù)據(jù)，就加鎖，在鎖的代碼塊中再次先查詢緩存。這樣鎖的目的就是為了當(dāng)?shù)谝淮尉彺鎻臄?shù)據(jù)庫(kù)查詢更新到緩存中，代碼塊執(zhí)行完，其他線程再次進(jìn)來(lái)，此時(shí)緩存中就已經(jīng)存在數(shù)據(jù)了，這樣就減少了查詢數(shù)據(jù)庫(kù)的次數(shù)

public Product get(Long productId) {
    Product product = null;
    String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;
    //DCL機(jī)制：第一次先從緩存里查數(shù)據(jù)
    product = getProductFromCache(productCacheKey);
    if (product != null) {
        return product;
    }
  
    //加分布式鎖解決熱點(diǎn)緩存并發(fā)重建問(wèn)題
    RLock hotCreateCacheLock = redisson.getLock(LOCK_PRODUCT_HOT_CACHE_CREATE_PREFIX + productId);
    hotCreateCacheLock.lock();
    // 這個(gè)優(yōu)化謹(jǐn)慎使用，防止超時(shí)導(dǎo)致的大規(guī)模并發(fā)重建問(wèn)題
    // hotCreateCacheLock.tryLock(1, TimeUnit.SECONDS);
    try {
        //DCL機(jī)制：在分布式鎖里面第二次查詢
        product = getProductFromCache(productCacheKey);
        if (product != null) {
            return product;
        }

        //RLock productUpdateLock = redisson.getLock(LOCK_PRODUCT_UPDATE_PREFIX + productId);
        RReadWriteLock productUpdateLock = redisson.getReadWriteLock(LOCK_PRODUCT_UPDATE_PREFIX + productId);
        RLock rLock = productUpdateLock.readLock();
        //加分布式讀鎖解決緩存雙寫(xiě)不一致問(wèn)題
        rLock.lock();
        try {
            product = productDao.get(productId);
            if (product != null) {
                redisUtil.set(productCacheKey, JSON.toJSONString(product),
                        genProductCacheTimeout(), TimeUnit.SECONDS);
            } else {
                //設(shè)置空緩存解決緩存穿透問(wèn)題
                redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeout(), TimeUnit.SECONDS);
            }
        } finally {
            rLock.unlock();
        }
    } finally {
        hotCreateCacheLock.unlock();
    }

    return product;
}

場(chǎng)景4: 突發(fā)性熱點(diǎn)緩存重建導(dǎo)致系統(tǒng)壓力暴增

問(wèn)題: 假如當(dāng)前有10w個(gè)線程沒(méi)有拿到鎖正在排隊(duì)，這種情況只能等到獲取鎖的線程執(zhí)行完代碼釋放鎖后，那排隊(duì)的10w個(gè)線程才能再次競(jìng)爭(zhēng)鎖。這里需要關(guān)注的問(wèn)題點(diǎn)就是又要再次競(jìng)爭(zhēng)鎖，意味著線程競(jìng)爭(zhēng)鎖的次數(shù)可能最少>1，頻繁的競(jìng)爭(zhēng)鎖對(duì)Redis性能也是有消耗的，有沒(méi)有更好的辦法讓每個(gè)線程競(jìng)爭(zhēng)鎖的次數(shù)盡可能減少呢？

解決方案

• 可以通過(guò)tryLock(time,TimeUnit)先讓所有線程嘗試獲取鎖

• 假如獲取鎖的線程執(zhí)行數(shù)據(jù)庫(kù)查詢?nèi)缓髮?shù)據(jù)更新到緩存所需要的時(shí)間為1s，那么當(dāng)其他線程獲取鎖時(shí)間結(jié)束后，會(huì)解除阻塞狀態(tài)直接往下執(zhí)行，然后再次查詢緩存的時(shí)候發(fā)現(xiàn)緩存有數(shù)據(jù)了就直接返回。

• 這樣設(shè)計(jì)的好處就是把分布式鎖在某些特定的場(chǎng)景使其"串行變并發(fā)"，不過(guò)這個(gè)優(yōu)化需要謹(jǐn)慎使用，防止超時(shí)導(dǎo)致的大規(guī)模并發(fā)重建問(wèn)題。畢竟沒(méi)有任何方案是完全解決問(wèn)題的，主要是根據(jù)公司業(yè)務(wù)而定.

場(chǎng)景5: 解決大規(guī)模緩存擊穿導(dǎo)致線上數(shù)據(jù)庫(kù)壓力暴增

緩存擊穿/緩存失效: 可能同一時(shí)間熱點(diǎn)數(shù)據(jù)全部過(guò)期而造成緩存查不到數(shù)據(jù)，請(qǐng)求就會(huì)從數(shù)據(jù)庫(kù)查詢，高并發(fā)情況下會(huì)導(dǎo)致數(shù)據(jù)庫(kù)壓力

解決方案

• 對(duì)于這個(gè)場(chǎng)景，可以給數(shù)據(jù)設(shè)置過(guò)期時(shí)間時(shí)，不要將所有緩存數(shù)據(jù)的過(guò)期時(shí)間設(shè)置為相同的過(guò)期時(shí)間，最好可以給每個(gè)數(shù)據(jù)的過(guò)期時(shí)間設(shè)置一個(gè)隨機(jī)數(shù)，保證數(shù)據(jù)在不同的時(shí)間段過(guò)期。

代碼案例

private Integer genProductCacheTimeout() {
  //加隨機(jī)超時(shí)機(jī)制解決緩存批量失效(擊穿)問(wèn)題
  return PRODUCT_CACHE_TIMEOUT + new Random().nextInt(5) * 60 * 60;
}

場(chǎng)景6: 黑客工資導(dǎo)致緩存穿透線上數(shù)據(jù)庫(kù)宕機(jī)

緩存穿透: 如果黑客通過(guò)腳本文件不停的傳一些不存在的參數(shù)刷網(wǎng)站的接口，而這種垃圾參數(shù)在緩存和數(shù)據(jù)庫(kù)又不存在，這樣就會(huì)一直地查數(shù)據(jù)庫(kù)，最終可能導(dǎo)致數(shù)據(jù)庫(kù)并發(fā)量過(guò)大而卡死宕機(jī)。

解決方案

• 網(wǎng)關(guān)限流。Nginx、Sentinel、Hystrix都可以實(shí)現(xiàn)
• 代碼層面。可以使用多級(jí)緩存，比如一級(jí)緩存采用布隆過(guò)濾器，二級(jí)緩存可以使用guava中的Cache，三級(jí)緩存使用Redis，為什么一級(jí)緩存使用布隆過(guò)濾器呢，其結(jié)構(gòu)和bitmap類(lèi)似，用于存儲(chǔ)數(shù)據(jù)狀態(tài)，能存大量的key

布隆過(guò)濾器

• 布隆過(guò)濾器就是一個(gè)大型的位數(shù)組和幾個(gè)不一樣的無(wú)偏Hash函數(shù).當(dāng)布隆過(guò)濾器說(shuō)某個(gè)值存在時(shí)，這個(gè)值可能不存在，當(dāng)說(shuō)不存在時(shí)，那就肯定不存在。

場(chǎng)景7: 大V直播帶貨導(dǎo)致線上商品系統(tǒng)崩潰原因分析

問(wèn)題: 這種場(chǎng)景可能是在某個(gè)時(shí)刻把冷門(mén)商品一下子變成了熱門(mén)商品。因?yàn)槔溟T(mén)的數(shù)據(jù)可能在緩存時(shí)間過(guò)期就刪除，而此時(shí)剛好有大量請(qǐng)求，比如直播期間推送一個(gè)商品連接，假如同時(shí)有幾十萬(wàn)人搶購(gòu)，而緩存沒(méi)有的話，意味著所有的請(qǐng)求全部達(dá)到了數(shù)據(jù)庫(kù)中查詢，而對(duì)于數(shù)據(jù)庫(kù)單節(jié)點(diǎn)支撐并發(fā)量也就不到1w，此時(shí)這么大的請(qǐng)求量，肯定會(huì)把數(shù)據(jù)庫(kù)整宕機(jī)(這種場(chǎng)景比較少，但是小概率還是會(huì)有)

解決方案

• 可以通過(guò)tryLock(time,TimeUnit)先讓所有線程嘗試獲取鎖

• 假如獲取鎖的線程執(zhí)行數(shù)據(jù)庫(kù)查詢?nèi)缓髮?shù)據(jù)更新到緩存所需要的時(shí)間為1s，那么當(dāng)其他線程獲取鎖時(shí)間結(jié)束后，會(huì)解除阻塞狀態(tài)直接往下執(zhí)行，然后再次查詢緩存的時(shí)候發(fā)現(xiàn)緩存有數(shù)據(jù)了就直接返回。

• 這樣設(shè)計(jì)的好處就是把分布式鎖在某些特定的場(chǎng)景使其"串行變并發(fā)"，不過(guò)這個(gè)優(yōu)化需要謹(jǐn)慎使用，防止超時(shí)導(dǎo)致的大規(guī)模并發(fā)重建問(wèn)題。畢竟沒(méi)有任何方案是完全解決問(wèn)題的，主要是根據(jù)公司業(yè)務(wù)而定.

場(chǎng)景8: Redis分布式鎖解決緩存與數(shù)據(jù)庫(kù)雙寫(xiě)不一致問(wèn)題實(shí)戰(zhàn)

解決方案

• 重入鎖保證并發(fā)安全。通常說(shuō)在分布式鎖中再加一把鎖，鎖太重，性能不是很好，還有優(yōu)化空間
• 分布式讀寫(xiě)鎖(ReadWriteLock)，實(shí)現(xiàn)機(jī)制和ReentranReadWriteLock一直，適合讀多寫(xiě)少的場(chǎng)景，注意讀寫(xiě)鎖的key得一致
• 使用canal通過(guò)監(jiān)聽(tīng)binlog日志及時(shí)去修改緩存，但是引入中間件，增加系統(tǒng)的維護(hù)度

Lua腳本設(shè)置讀寫(xiě)鎖

local mode = redis.call('hget', KEYS[1], 'mode');
if (mode == false) 
then redis.call('hset', KEYS[1], 'mode', 'read'); 
redis.call('hset', KEYS[1], ARGV[2], 1); 
redis.call('set', KEYS[2] .. ':1', 1); 
redis.call('pexpire', KEYS[2] .. ':1', ARGV[1]);
redis.call('pexpire', KEYS[1], ARGV[1]); 
return nil; 
end; 
if (mode == 'read') or (mode == 'write' and redis.call('hexists', KEYS[1], ARGV[3]) == 1) 
then local ind = redis.call('hincrby', KEYS[1], ARGV[2], 1); 
local key = KEYS[2] .. ':' .. ind;
redis.call('set', key, 1); 
redis.call('pexpire', key, ARGV[1]); redis.call('pexpire', KEYS[1], ARGV[1]); 
return nil; 
end;
return redis.call('pttl', KEYS[1]);

ReadWriteLock代碼案例

@Transactional
public Product update(Product product) {
  Product productResult = null;
  //RLock productUpdateLock = redisson.getLock(LOCK_PRODUCT_UPDATE_PREFIX + product.getId());
  RReadWriteLock productUpdateLock = redisson.getReadWriteLock(LOCK_PRODUCT_UPDATE_PREFIX + product.getId());
  // 添加寫(xiě)鎖
  RLock writeLock = productUpdateLock.writeLock();
  //加分布式寫(xiě)鎖解決緩存雙寫(xiě)不一致問(wèn)題
  writeLock.lock();
  try {
      productResult = productDao.update(product);
      redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(), JSON.toJSONString(productResult),
      genProductCacheTimeout(), TimeUnit.SECONDS);
   } finally {
          writeLock.unlock();
   }
  return productResult;
}

public Product get(Long productId) {
    Product product = null;
    String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

    //從緩存里查數(shù)據(jù)
    product = getProductFromCache(productCacheKey);
    if (product != null) {
        return product;
    }

    //加分布式鎖解決熱點(diǎn)緩存并發(fā)重建問(wèn)題
    RLock hotCreateCacheLock = redisson.getLock(LOCK_PRODUCT_HOT_CACHE_CREATE_PREFIX + productId);
    hotCreateCacheLock.lock();
    // 這個(gè)優(yōu)化謹(jǐn)慎使用，防止超時(shí)導(dǎo)致的大規(guī)模并發(fā)重建問(wèn)題
    // hotCreateCacheLock.tryLock(1, TimeUnit.SECONDS);
    try {
        product = getProductFromCache(productCacheKey);
        if (product != null) {
            return product;
        }

        //RLock productUpdateLock = redisson.getLock(LOCK_PRODUCT_UPDATE_PREFIX + productId);
        RReadWriteLock productUpdateLock = redisson.getReadWriteLock(LOCK_PRODUCT_UPDATE_PREFIX + productId);
        // 添加讀鎖
        RLock rLock = productUpdateLock.readLock();
        //加分布式讀鎖解決緩存雙寫(xiě)不一致問(wèn)題
        rLock.lock();
        try {
            product = productDao.get(productId);
            if (product != null) {
                redisUtil.set(productCacheKey, JSON.toJSONString(product),
                        genProductCacheTimeout(), TimeUnit.SECONDS);
            } else {
                //設(shè)置空緩存解決緩存穿透問(wèn)題
                redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeout(), TimeUnit.SECONDS);
            }
        } finally {
            rLock.unlock();
        }
    } finally {
        hotCreateCacheLock.unlock();
    }

    return product;
}

場(chǎng)景9: 大促壓力暴增導(dǎo)致分布式鎖串行爭(zhēng)用問(wèn)題優(yōu)化

解決方案

• 可以采用分段鎖，和JDK7的ConcurrentHashMap的實(shí)現(xiàn)原理很類(lèi)似，將一個(gè)鎖，分成多個(gè)鎖，比如lock，分成lock_1、lock_2...
• 然后將庫(kù)存平均分?jǐn)偟矫堪焰i，這樣做的目的是分?jǐn)偡植际芥i的壓力，本來(lái)只有一個(gè)鎖，意味著所有的線程進(jìn)來(lái)只能一個(gè)線程獲取到鎖，如果分?jǐn)倿?0把鎖，那么同一時(shí)間可以有10個(gè)線程同時(shí)獲取到鎖對(duì)同一個(gè)商品進(jìn)行操作，也就意味著在同等環(huán)境下，分段鎖的效率比只用一個(gè)鎖要高得多

場(chǎng)景10: 利用多級(jí)緩存解決Redis線上集群緩存雪崩問(wèn)題

緩存雪崩: 緩存支撐不住或者宕機(jī)，然后大量請(qǐng)求涌入數(shù)據(jù)庫(kù)。

解決方案

• 網(wǎng)關(guān)限流。Nginx、Sentinel、Hystrix都可以實(shí)現(xiàn)
• 代碼層面。可以使用多級(jí)緩存，比如一級(jí)緩存采用布隆過(guò)濾器，二級(jí)緩存可以使用guava中的Cache，三級(jí)緩存使用Redis，為什么一級(jí)緩存使用布隆過(guò)濾器呢，其結(jié)構(gòu)和bitmap類(lèi)似，用于存儲(chǔ)數(shù)據(jù)狀態(tài)，能存大量的key

場(chǎng)景11: 一次微博明顯熱點(diǎn)事件導(dǎo)致系統(tǒng)崩潰原因分析

問(wèn)題: 比如微博上某一天某個(gè)明星事件成為了熱點(diǎn)新聞，此時(shí)很多吃瓜群眾全部涌入這個(gè)熱點(diǎn)，如果并發(fā)每秒達(dá)到幾十萬(wàn)甚至上百萬(wàn)的并發(fā)量，但是Redis服務(wù)器單節(jié)點(diǎn)只能支撐并發(fā)10w而已，那么可能因?yàn)檫@么高的并發(fā)量導(dǎo)致很多請(qǐng)求卡死在那，要知道我們其他業(yè)務(wù)服務(wù)也會(huì)用到Redis，一旦Redis卡死，就會(huì)影響到其他業(yè)務(wù)，導(dǎo)致整個(gè)業(yè)務(wù)癱瘓，這就是典型的緩存雪崩問(wèn)題

解決方案: 參考場(chǎng)景10

場(chǎng)景12: 大廠對(duì)熱點(diǎn)數(shù)據(jù)處理方案

解決方案

• 如果按照場(chǎng)景10的方案去實(shí)現(xiàn)，需要考慮數(shù)據(jù)一致性問(wèn)題，這樣就不得不每次對(duì)數(shù)據(jù)進(jìn)行增加、刪除、更新都要立馬通知其他節(jié)點(diǎn)更新數(shù)據(jù)，能做到及時(shí)更新數(shù)據(jù)的方案可能就是：Redis發(fā)布/訂閱、MQ等
• 雖然說(shuō)這些方案實(shí)現(xiàn)也可以，但是不可避免的我們需要再維護(hù)相關(guān)的中間件，提高了維護(hù)成本
• 目前大廠對(duì)于熱點(diǎn)數(shù)據(jù)專(zhuān)門(mén)會(huì)有一個(gè)類(lèi)似于熱點(diǎn)緩存系統(tǒng)來(lái)維護(hù)，所有的web應(yīng)用只需要監(jiān)聽(tīng)這個(gè)系統(tǒng)，只要有熱點(diǎn)時(shí)，直接更新緩存，這樣既能減少代碼耦合，還能更好的維護(hù)熱點(diǎn)數(shù)據(jù)。
• 那么熱點(diǎn)數(shù)據(jù)來(lái)源怎么獲取呢？可以在設(shè)計(jì)查詢的接口使用類(lèi)似于Spring AOP的方式，每次查詢就把數(shù)據(jù)傳送到熱點(diǎn)數(shù)據(jù)，一般大廠都會(huì)有數(shù)據(jù)分析崗位，根據(jù)熱點(diǎn)規(guī)則將數(shù)據(jù)分類(lèi)

到此這篇關(guān)于淺談Redis高并發(fā)緩存架構(gòu)性能優(yōu)化實(shí)戰(zhàn)的文章就介紹到這了,更多相關(guān)Redis高并發(fā)緩存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論