2. 程式人生 > >快取失效及解決方案

快取失效及解決方案

阿新 • • 發佈：2018-12-01

這幾天在網易雲課堂上看到幾個關於Java開發比較好的視訊，推薦給大家
Java高階開發工程師公開課
這篇文章也是對其中一門課程的個人總結。

何謂快取失效

對於一個併發量大的專案，快取是必須的，如果沒有快取，所有的請求將直擊資料庫，資料庫很有可能抗不住，所以建立快取勢在不行。

那麼建立快取後就有可能出現快取失效的問題：

  1. 大面積的快取key失效
  2. 熱點key失效

類似12306網站，因為使用者頻繁的查詢車次資訊，假設所有車次資訊都建立對應的快取，那麼如果所有車次建立快取的時間一樣，失效時間也一樣，那麼在快取失效的這一刻，也就意味著所有車次的快取都失效。通常當快取失效的時候我們需要重構快取，這時所有的車次都將面臨重構快取，即出現問題1的場景，此時資料庫就將面臨大規模的訪問。
針對以上這種情況，可以將建立快取的時間進行分佈，使得快取失效時間儘量不同，從而避免大面積的快取失效。

下面討論第二個問題。
春節馬上快到了，搶票回家的時刻也快來臨了。通常我們會事先選擇好一個車次然後瘋狂更新車次資訊，假設此時這般車的快取剛好失效，可以想象會有多大的請求會直懟資料庫。

使用快取

下面是通常的快取使用方法，無非就是先查快取，再查DB，重構快取。

@Service
public class TicketService {

    @Autowired
    TicketRepository ticketRepository;
    

    @Autowired
    RedisUtil redis;
    public Integer findTicketByName(String name){
        //1.先從快取獲取
        String value = redis.get(name);
        if(value != null){
            System.out.println(Thread.currentThread().getId()+"從快取獲取："+value);
            return Integer.valueOf(value);
        }
        //2.查詢資料庫
        Ticket ticket = ticketRepository.findByName(name);
        System.out.println(Thread.currentThread().getId()+"從資料庫獲取："+ticket.getTickets());
        //3.放入快取
        redis.set(name,ticket.getTickets(),120);
        return 0;
    }
}

接下來我們模擬1000個請求同時訪問這個service

@RunWith(SpringRunner.class)
@SpringBootTest
public class RedisQpsApplicationTests {

    //車次
    public static final String NAME = "G2386";

    //請求數量
    public static final Integer THREAD_NUM = 1000;

    //倒計時
    private CountDownLatch countDownLatch = new CountDownLatch(THREAD_NUM);
    @Autowired
    private TicketService tocketService;

    @Autowired
    private TicketService2 tocketService2;

    @Autowired
    private TicketService3 tocketService3;
    @Test
    public void contextLoads() {
        long startTime = System.currentTimeMillis();
        System.out.println("開始測試");
        Thread[] threads = new Thread[THREAD_NUM];
        for(int i=0;i<THREAD_NUM;i++){
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {

                    try {
                        //所有開啟的執行緒在此等待，倒計時結束後統一開始請求,模擬併發量
                        countDownLatch.await();
                        //查詢票數
                        tocketService.findTicketByName(NAME);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }

                }
            });
            threads[i].start();
            //倒計時
            countDownLatch.countDown();
        }

        for(Thread thread:threads){
            try {
                thread.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println("結束測試===="+(System.currentTimeMillis()-startTime));
    }

}

經過測試可以很簡單地發現所有的訪問都直接去查詢資料庫而獲得資料
在這裡插入圖片描述
那麼明明我們已經使用了快取為什麼還會出現這種情況呢？只要稍微瞭解多執行緒的知識就不難知道為什麼會出現這個問題。
我們的思路是第一個訪問的人在沒有快取的情況下，去重構快取，那麼剩下的訪問再去查快取。上述的情況就是因為在第一人去查DB的時候，剩下的訪問也去查DB了。
那麼根據我們的思路無非就是想讓剩下的訪問阻塞等待嘛，於是有了我們下面經過改良的方案。

加鎖重構快取

@Service
public class TicketService2 {

    @Autowired
    TicketRepository ticketRepository;

    Lock lock = new ReentrantLock();

    @Autowired
    RedisUtil redis;
    public Integer findTicketByName(String name){
        //1.先從快取獲取
        String value = redis.get(name);
        if(value != null){
            System.out.println(Thread.currentThread().getId()+"從快取獲取："+value);
            return Integer.valueOf(value);
        }
        //第一人獲取鎖，去查DB，剩餘人二次查詢快取
        long s = System.currentTimeMillis();
        lock.lock();
        try {
            System.out.println(Thread.currentThread().getId()+"加鎖阻塞時長"+(System.currentTimeMillis()-s));
            value = redis.get(name);
            if(value != null){
                System.out.println(Thread.currentThread().getId()+"從快取獲取："+value);
                return Integer.valueOf(value);
            }
            //2.查詢資料庫
            Ticket ticket = ticketRepository.findByName(name);
            System.out.println(Thread.currentThread().getId()+"從資料庫獲取："+ticket.getTickets());
            //3.放入快取
            redis.set(name,ticket.getTickets(),120);
        }finally {
            lock.unlock();
        }

        return 0;
    }
}

通過單元測試可以看到確實符合我們的預期。第一個去重構快取，剩餘的查快取。這裡要注意記得在鎖內對快取進行二次查詢。

在這裡插入圖片描述
這種解決方案怎麼說呢，有好有壞。

  • 優點：簡單通用，使用範圍廣
  • 缺點：阻塞訪問，使用者體驗差，鎖粒度粗

關於鎖的粒度：12306的車次是非常多的，假設有兩個車次的快取都失效了，假設使用上述方案，第一個車次的去查DB，第二個車次的也要去查DB重構快取啊，憑什麼我要等你第一個車次的查完，我再去查。這就是鎖粒度粗導致的，一把鎖面對所有車次的查詢，當別車次擁有了鎖，那你只好乖乖等待了。

快取降級

快取降級簡單的理解就是降低預期期望。比如雙十一的時候很多人因為支付不成功而提示的稍後再試，這些都屬於快取降級，快取降級也有好幾種方案，具體要結合實際業務場景，可以返回固定的資訊，返回備份快取的值(並不一定是真實值)，返回提示等待…

對鎖的粒度進行優化結合快取降級，對於每一個車次如果已經在重構快取，那麼同車次的訪問進行快取降級，不同車次的訪問則也可以重構快取。大體思路如下
在這裡插入圖片描述
下面使用ConcurrentHashMap對每個車次的鎖進行標記

@Service
public class TicketService3 {

    @Autowired
    TicketRepository ticketRepository;
    //標記該車次是否有人在重構快取
    ConcurrentHashMap<String,String> mapLock = new ConcurrentHashMap<>();

    @Autowired
    RedisUtil redis;
    public Integer findTicketByName(String name){
        //1.先從快取獲取
        String value = redis.get(name);
        if(value != null){
            System.out.println(Thread.currentThread().getId()+"從快取獲取："+value);
            return Integer.valueOf(value);
        }
        boolean lock = false;
        try {
            /* putIfAbsent 如果不存在，新增鍵值，返回null，存在則返回存在的值 */
            lock = mapLock.putIfAbsent(name,"true") == null ;  //1000個請求，只有一個拿到鎖，剩餘人快取降級
            if(lock){   //拿到鎖
                //2.查詢資料庫
                Ticket ticket = ticketRepository.findByName(name);
                System.out.println(Thread.currentThread().getId()+"從資料庫獲取："+ticket.getTickets());
                //3.放入快取
                redis.set(name,ticket.getTickets(),120);
                //4.有備份快取 雙寫快取 不設時間
            }else{
                //方案1 返回固定值
                System.out.println(Thread.currentThread().getId()+"固定值獲取：0");
                return 0;
                //方案2 備份快取
                //方案3 提示使用者重試
            }
        }finally {
            if(lock){//有鎖才釋放
                mapLock.remove(name);//釋放鎖
            }

        }

        return 0;
    }
}

詳細程式碼已經見碼雲

總結

快取失效的兩種情況：
1.大面積快取key失效，所有車次查詢都依賴資料庫，可對快取的時間進行隨機分佈
2.熱點key失效，某個key的海量請求直擊資料庫
快取的實現原理：先查快取，再查DB，塞進快取
1.快取失效：快取有有效時間，當有效時間到達，大量併發執行緒會直擊資料庫。
解決方案：1.Lock 第一人查DB，做快取，剩餘人二次查詢快取

優點：簡單有效，適用範圍廣
缺點：阻塞其他執行緒，使用者體驗差
鎖顆粒度大
優化：細粒度鎖實現

2.快取降級：1）做備份快取，不設定事件 2）返回固定值
主備都無資料，一人去查DB，剩餘人返回固定值
主無資料，備有資料，一人查DB，剩餘人查備份
優點：靈活多變
缺點：備份快取資料可能不一致

相關推薦

快取失效及解決方案

這幾天在網易雲課堂上看到幾個關於Java開發比較好的視訊，推薦給大家 Java高階開發工程師公開課 這篇文章也是對其中一門課程的個人總結。 何謂快取失效 對於一個併發量大的專案，快取是必須的，如果沒有快取，所有的請求將直擊資料庫，資料庫很有可能抗不住，所以建立快取勢在不行。 那麼

關於快取穿透、快取併發、快取失效的解決方案

一、快取穿透 我們在專案中使用快取通常都是APP先檢查快取中是否存在，如果存在直接返回快取內容，如果不存在就直接查詢資料庫然後再快取查詢結果返回。這個時候如果我們查詢的某一個數據在快取中一直不存在，就會造成每一次請求都查詢DB，這樣快取就失去了意義，在流量大時，可能DB

快取擊穿、快取失效及熱點key的解決方案

分散式快取是網站服務端經常用到的一種技術，在讀多寫少的業務場景中，通過使用快取可以有效地支撐高併發的訪問量，對後端的資料庫等資料來源做到很好地保護。現在市面上有很多分散式快取，比如Redis、Memcached以及阿里的Tair等，不管我們使用的哪種快取產品，基本上都會遇到快取擊穿、快取失效以及熱點key的問

Redis快取穿透問題及解決方案

上週在工作中遇到了一個問題場景，即查詢商品的配件資訊時（商品：配件為1：N的關係），如若商品並未配置配件資訊，則查資料庫為空，且不會加入快取，這就會導致，下次在查詢同樣商品的配件時，由於快取未命中，則仍舊會查底層資料庫，所以快取就一直未起到應有的作用，當併發流量大時，會很容易把DB打垮。 快取穿透問題 快

高併發快取處理之——快取穿透的幾種形式及解決方案

快取失效的幾種形式 1 快取穿透 快取穿透是指查詢一個一定不存在的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。在流量大時，可能DB就掛掉了，要是有人利用不存在

面試常考！快取三大問題及解決方案

1. 快取來由 隨著網際網路系統發展的逐步完善，提高系統的qps，目前的絕大部分系統都增加了快取機制從而避免請求過多的直接與資料庫操作從而造成系統瓶頸，極大的提升了使用者體驗和系統穩定性。   2. 快取問題 雖然使用快取給系統帶來了一定的質的提升，但同時也帶來了一些需要注

vue單頁快取存在的問題及解決方案

1.css同名覆蓋,解決方法：父元件加上scoped <style lang="scss" scoped> @import './unbind.scss' </style> 子元件同名樣式加上deep /deep/ .tabs-row { .item

快取穿透、快取雪崩、快取擊穿的概念及解決方案

一、快取穿透 概念  訪問一個不存在的key，快取不起作用，請求會穿透到DB，流量大時DB會掛掉。 解決方案  採用布隆過濾器，使用一個足夠大的bitmap，用於儲存可能訪問的key，不存在的key直接被過濾；  訪問key未在DB查詢到值，也將空值寫進快取，但

oracle索引失效的原因及解決方案

一、以下的方法會引起索引失效?1,<>2,單獨的>,<,(有時會用到，有時不會)3,like "%_" 百分號在前.4,表沒分析.5,單獨引用複合索引裡非第一位置的索引列.6,字元型欄位為數字時在where條件裡不新增引號.7,對索引列進行運算.需要建

快取失效、快取穿透、快取併發及其解決方案

1. 快取失效 問題描述：　　        引起這個原因的主要因素是高併發下，我們一般設定一個快取的過期時間時，可能有一些會設定5分鐘啊，10分鐘這些；併發很高時可能會出在某一個時間同時生成了很多的快取，並且過期時間在同一時刻，這個時候就可能引發——當過期時間到後，這些

高併發熱點快取資料可能出現問題及解決方案

背景 電商場景促銷活動的會場頁由於經常集中在某個時間點進行“秒殺”促銷，這些頁面的QPS（伺服器每秒可以處理的請求量）往往特別高，資料庫通常無法直接支撐如此高QPS的請求，常見的解決方案是讓大部分相同資訊的請求都儘可能地壓在快取（cache）上來緩解資料庫（DB）的壓力

快取失效、快取穿透問題解決方案

快取失效： 　　引起這個原因的主要因素是高併發下，我們一般設定一個快取的過期時間時，可能有一些會設定5分鐘啊，10分鐘這些；併發很高時可能會出在某一個時間同時生成了很多的快取，並且過期時間在同一時刻，這個時候就可能引發——當過期時間到後，這些快取同時失效，請求全部轉發到DB，

快取穿透、快取擊穿、快取雪崩概念及解決方案

快取穿透 概念 訪問一個不存在的key，快取不起作用，請求會穿透到DB，流量大時DB會掛掉。 解決方案 採用布隆過濾器，使用一個足夠大的bitmap，用於儲存可能訪問的key，不存在的key直接被過濾； 訪問key未在DB查詢到值，也將空值寫進快取，但可以設定較短過

Redis快取擊穿，穿透，雪崩等問題，及解決方案

快取穿透快取穿透是指查詢一個一定不存在的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。在流量大時，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這

快取世界中的三大問題及解決方案

目前的IO裝置遠不能滿足網際網路應用海量的讀寫請求。於是便出現了快取，利用記憶體的高速讀寫效能來應付海量的查詢請求。然而記憶體資源非常寶貴，將全量資料儲存在記憶體中顯然是不切合實際的。因此目前採用記憶體和IO結合的方式，記憶體只儲存熱點資料，而IO裝置儲存

快取與資料庫雙寫，不一致問題及解決方案

面試題 如何保證快取與資料庫的雙寫一致性？ 面試官心理分析 你只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是

redis快取穿透、快取雪崩、熱點Key問題分析及解決方案

我們通常使用 快取 + 過期時間的策略來幫助我們加速介面的訪問速度，減少了後端負載，同時保證功能的更新。 快取穿透 快取系統，按照

Linux PHP安裝遇見的問題及解決方案

linux php安裝出現錯誤 解決方法 遇到的問題與解決方案 問題一:報以下錯誤./configure以下錯誤發生Sorry, I cannot run apxs. Possiblereasons follow:1. Perl is not installed2. apxs was not fou

CentOS 7 安裝MySQL 5.6遇到問題及解決方案

linux localhost not ces name 解決 info target case centos下安裝mysql真的沒有想象中那麽容易，在這裏我總結一下遇到的問題 1. ERROR 2002 (HY000): Can’t connect to loca

內存溢出原因及解決方案

使用 -xmx 遞歸調用 其它 地址 str 啟動 遞歸 對象 參考地址：http://baike.baidu.com/view/79183.htm 內存溢出是指應用系統中存在無法回收的內存或使用的內存過多，最終使得程序運行要用到的內存大於虛擬機能提供的最大內存