最近，有小伙伴私信我：冰哥，我最近出去面試，面試官問我如何設計緩存能讓系統在百萬級別流量下仍能平穩運行，我當時沒回答上來。接著，面試官問我之前的項目是怎么使用緩存的，我說只是緩存了一些數據。當時確實想不到緩存還有哪些用處，估計這次面試是掛了。冰哥，你可以給我講講互聯網大廠項目是怎么設計和使用緩存的嗎？

本文緩存方案已經開源，開源地址如下，如果開源方案對你有點幫助或者啟發，歡迎在代碼倉庫給個Star，讓更多的小伙伴看到它，互相學習，一起進步。

• GitHub：https://github.com/binghe001/spring-redis
• Gitee：https://gitee.com/binghe001/spring-redis
• GitCode：https://gitcode.net/binghe001/spring-redis

一、前言

通過這位小伙伴的自述，我們明顯感受到這位小伙伴對緩存的認識還是停留在簡單的存儲數據上，沒有對使用緩存背后的場景和實現邏輯進行深層次的思考。在互聯網大廠項目中，緩存也是一種必不可少的組件，那使用緩存僅僅是為了緩存熱點數據，提升讀性能嗎？如果你對緩存的認識只是停留在這里，那就未免太膚淺了。

今天，我們就以高并發、大流量業務場景中最具代表性的 秒殺系統 為例，采用市面上大家都比較熟悉的技術，一起探究下 秒殺系統 背后是如何設計和使用緩存的。

二、秒殺系統緩存核心訴求

秒殺系統在承接瞬時高并發流量時，如果將流量直接打到數據庫，那數據庫很有可能因為扛不住瞬間的高并發流量而導致崩潰和宕機。所以，需要對秒殺系統進行極致的緩存設計，讓大部分流量走緩存。

同時，在設計緩存架構方案時，為了進一步提升性能，將采用 本地緩存+分布式緩存的混合型緩存 設計方案，讓本地緩存抗大部分流量，分布式緩存次之，數據庫再次之，如圖1所示

圖片

并且針對秒殺系統這種瞬時并發量高的場景，在設計緩存時，需要注意的技巧：優先讀取本地緩存數據，如果本地緩存失效，則讀取分布式緩存數據，并且在同一時刻，只能有一個線程更新本地緩存，防止緩存擊穿。

沒有獲取到本地緩存更新機會的其他線程，需要立即返回而不是原地等待。如果分布式緩存失效時，在同一時刻，也只能有一個線程更新分布式緩存，防止緩存擊穿。沒有獲取到分布式緩存更新機會的線程，也需要立即返回而不是原地等待。

另外，需要注意的是：我們提出了采用 本地緩存+分布式緩存的混合型緩存設計方案，后文會著重對這種設計進行說明。

三、秒殺系統緩存使用場景

秒殺系統屬于典型的讀多寫少的高并發系統，應對這種場景的一個有效措施就是使用緩存，不管是單機JVM緩存還是以Redis為例的分布式緩存，其讀寫性能都會比數據庫高得多。所以，在秒殺系統中，為了應對高并發、大流量的業務場景，緩存自然也就成為建設秒殺系統過程中必不可少的環節。

3.1 秒殺系統接口分析

在秒殺系統中，主要是對一些讀數據的接口設計緩存策略，而在這些讀數據的接口中，獲取秒殺活動列表、獲取秒殺活動詳情、獲取秒殺商品列表和獲取秒殺商品詳情的接口流量比其他接口高。

尤其是獲取秒殺商品列表和獲取秒殺商品詳情的接口QPS一般會高于獲取秒殺活動列表和秒殺活動詳情的接口，畢竟大部分用戶在秒殺開始前就已經進入到秒殺詳情頁，當然這也不是絕對的，還是要看秒殺系統對于這些接口的設計。

3.2 秒殺系統緩存場景

盡管獲取秒殺商品列表和獲取秒殺商品詳情的接口QPS一般會高于獲取秒殺活動列表和秒殺活動詳情的接口。

但是我們在設計緩存時，需要對這些接口一視同仁，都要以嚴格的高標準來設計這些接口，不然稍有不慎，一個接口出現問題，就可能導致整場秒殺活動以失敗告終。秒殺系統緩存的使用場景如圖2所示。

圖片

所以，在秒殺系統中，會對獲取秒殺活動列表、獲取秒殺活動詳情、獲取秒殺商品列表和獲取秒殺商品詳情的接口設計緩存策略。

四、混合型緩存設計

總體來說，在設計秒殺系統的緩存過程中，會采用 本地緩存+分布式緩存的混合型緩存 設計方案。其中，本地緩存指的就是單機緩存，比如JVM內存緩存，單機Cache緩存。分布式緩存指的是以分布式的方式集中管理的緩存，比如Memcached、Redis等，如圖3所示。

圖片

4.1 抗流量洪峰

良好的緩存設計不僅僅能夠提升系統的總體性能，還能作為抗瞬時流量洪峰的有效防線。

可以這么說，如果整個秒殺系統前置的流量管控、流量清洗和限流等是秒殺系統流量洪峰的第一道防線，則本地緩存就是抗流量洪峰的第二道防線，而分布式緩存就是第三道防線，如圖4所示。

圖片

使用緩存能夠抗一定的流量洪峰，經過前置的流量管控、流量清洗和限流等措施的第一道防線、本地緩存的第二道防線、分布式緩存的第三道防線，真正進入數據庫的流量就會比較小了。

4.2 緩存集群方案

從緩存集群模式的角度去分析，每臺服務器甚至JVM實例都會擁有自己獨立的本地緩存，在承載大并發流量時，，以本地緩存為主，分布式緩存次之，如圖5所示。

圖片

可以看到，從緩存的集群模式角度來看，每臺服務器都會自己獨立本地緩存，除了前置的流程管控、流量清洗和限流等措施構筑的流量洪峰第一道防線外。本地緩存會承接剩余的大部分流量，構筑成流量洪峰的第二道防線，而分布式緩存則是流量洪峰的第三道防線。

并且在緩存的設計上，分布式緩存的作用主要是協調和同步最新數據到本地緩存。

也就是說，只有本地緩存失效時，才會訪問分布式緩存，將分布式緩存中的數據更新到本地緩存中，并且同一時刻只能有一個線程對本地緩存進行更新操作，以避免多個線程并發更新本地緩存。

同樣的，如果分布式緩存失效，則同一時刻只能有一個線程訪問數據庫來獲取對應的數據，并將其更新到分布式緩存。

在集群模式下，我們應該盡最大努力將流量攔截在本地緩存，避免過多的請求訪問分布式緩存，提高秒殺系統的性能，并且降低秒殺系統由于大量的遠程IO導致的各種風險。

4.3 緩存交互流程

采用本地緩存+分布式緩存的混合型緩存架構設計方案時，在讀取緩存數據時，會優先讀取本地緩存的數據，如果本地緩存未開啟，或者已經失效，此時就會使用分布式緩存。

也就是說，優先讀取本地緩存中的數據，如果本地緩存未開啟或者緩存數據失效，則讀取分布式緩存中的數據，如圖6所示。

圖片

可以看到，只有在本地緩存未開啟或者緩存失效的情況下，才會去訪問分布式緩存，讀取分布式緩存中的數據，并且在同一個時刻只能有一個線程更新本地緩存中的數據，這種方式可以最大限度減少遠程IO為秒殺系統帶來的風險。具體的流程如下所示。

（1）判斷本地緩存是否開啟，如果開啟則進行第2步，否則進行第4步。

（2）判斷本地緩存是否失效，如果未失效，則進行第3步，否則進行第4步。

（3）讀取本地緩存數據，讀取緩存流程結束。

（4）判斷分布式緩存是否開啟，如果開啟則進行第5步，否則進行第7步。

（5）判斷分布式緩存是否失效，如果未失效，則進行第6步，否則進行第7步。

（6）讀取分布式緩存數據，同一時刻只有一個線程更新本地緩存數據，讀取緩存流程結束。

（7）讀取數據庫數據，同一時刻只有一個線程更新分布式緩存數據，讀取緩存流程結束。

這里，有一個設計技巧需要大家注意：如果本地緩存失效，并且某個線程沒有獲取到更新本地緩存的機會，這個線程需要立即返回而不是在原地阻塞等待，這種方式可以最大限度的節省服務器資源和線程切換的成本，尤其是像在秒殺系統這種承接瞬時高并發流量的系統中，這種設計能夠節省不少服務器資源。

這種線程未獲取到更新數據的機會而快速返回的機制，需要客戶端配合在適配處理，也就是說，客戶端對這種情況需要進行靜默處理，不要提示錯誤信息，也不做其他處理，稍后重新調用接口進行重試即可。

4.4 混合型緩存設計的優點

采用本地緩存+分布式緩存的混合型緩存架構設計方案存在諸多的優點。其中，本地緩存一個很大的優勢就在于不會發生遠程IO操作，性能更高，有利于服務的橫向伸縮，大部分請求會命中本地單機緩存。這里，我們可以從整體的請求鏈路上進行分析。

例如，當前請求鏈路上需要讀取5次分布式緩存中的數據，這樣，如果秒殺系統承接了100萬的請求，則會產生500萬讀取分布式緩存的IO操作。這成倍的IO風險對于秒殺系統來說，是絕對不能忽視的風險因素，如圖7所示。

圖片

可以看到，一次請求會訪問5次分布式緩存，這在無形當中就增加了分布式緩存的IO成本，這對秒殺系統來說，是不容忽視的風險項，稍有不慎，則系統可能會由于IO瓶頸引發各種事故，最終造成系統崩潰或者宕機。所以，在設計秒殺系統時，一定要注意這種放大效應帶來的風險。

因此，在高并發大流量的場景下，很有必要精心的設計本地緩存。

五、緩存刷新機制

數據存放到緩存中，并不是一成不變的，也不會永久存放到緩存中。也就是說，存放到緩存中的數據終歸是要失效或者過期的，也就是存放到緩存中的數據會有相應的生命周期。

為此需要以一定的策略對緩存中的數據進行刷新操作，以防止緩存中的數據長時間過期而導致大部分流量直接打入數據庫。

本節，就從本地緩存和分布式緩存兩個角度簡單聊聊緩存的生命周期。

5.1 本地緩存刷新機制

假設本地緩存基于Guava Cache實現，在設計本地緩存時，本地緩存的容量不宜過大，有效時長不宜過大，并且在設計本地緩存時，可以基于版本號機制來實現緩存的失效策略。

對于本地緩存會實現兩種刷新機制：

（1）主動刷新

請求接口傳入的版本號如果大于本地緩存中的版本號，說明本地緩存已經失效，此時，就需要從分布式緩存中重新獲取數據進行刷新。

（2）被動刷新

本地緩存自動過期，被動從緩存中移除，此時，需要從分布式緩存中重新獲取數據進行刷新。

5.2 分布式緩存刷新機制

假設分布式緩存基于Redis實現，對于分布式緩存來說，也需要設置緩存的過期時間，不能讓緩存數據永久性駐留到Redis中。相比于本地緩存來說，分布式緩存的過期時間要稍微長一些，并且分布式緩存在刷新機制上與本地緩存略有不同。

（1）主動刷新

業務數據變更驅動刷新分布式緩存數據。當業務數據發生變更時，會主動刷新分布式緩存中的數據。

（2）被動刷新

可以基于Redis提供的緩存過期策略，比如基于LRU、TTL等策略淘汰緩存中的數據。后續在訪問分布式緩存中的數據時，如果檢測到分布式緩存中的數據已經過期，則會使用一個線程來刷新分布式緩存中的數據。

六、數據一致性

可以這么說，只要系統中使用了緩存，就或多或少會涉及到數據一致性的問題，在秒殺系統中，數據一致性的問題主要包括：本地緩存與分布式緩存數據一致性問題，緩存與數據庫數據一致性問題。同時，在數據一致性保證方面，就包括強一致性保證和弱一致性保證。

6.1 強一致性保證

CAP理論為數據的強一致性奠定了理論基礎，但是CAP理論下的數據強一致性，很難做到既保證系統高性能的同時，又要保證數據的絕對一致。在秒殺系統的設計中，我們會將數據的強一致性保證交給數據庫和業務規則來實現，在業務規則層面結合數據庫來實現強一致。

例如，假設用戶在搶購秒殺商品中，緩存中存在商品庫存，通過了緩存中的校驗邏輯。在真正下單時，還要校驗數據庫中的商品庫存，如果此時數據庫中已經沒有商品剩余庫存了，則終止下單邏輯，提示用戶商品已售罄。

6.2 弱一致性保證

強一致性保證交由業務規則和數據庫共同約束實現，緩存層面的數據就可以實現為弱一致性。

也就是說，在很小的一段時間內，允許緩存中的數據存在延遲，允許緩存中的數據與數據庫中的數據在短時間內的不一致，只要在可接受的時間范圍內最終達到一致即可。

充分發揮緩存的實際作用，即：緩存數據，提供系統的讀寫性能和抗系統流量。

七、緩存落地實現

在秒殺系統中本地緩存和分布式緩存相結合，能夠抗住進入秒殺系統內部的大部分流量。并且在技術選型上，假設本地緩存默認基于Guava Cache實現，分布式緩存默認基于Redis實現。

并且本地緩存不僅僅只是支持Guava Cache，分布式緩存不僅僅只是支持Redis，在代碼層面，都是面向接口編程，而非面向具體實現類編程，不管是本地緩存還是分布式緩存，都可以根據簡單的配置切換具體的實現方式。

7.1 擴展性描述

代碼具備良好的擴展性，后續維護和升級的成本就比較低。相反，如果代碼寫的雜亂無章，猶如“屎山”，那后期維護起來是相當痛苦的，誰也不想天天面對著一堆“屎山”，哪來有問題改哪里。

所以，從一開始寫的代碼就要有良好的擴展性，方便后期的維護和升級。

假設秒殺系統整體基于SpringBoot+SpringCloud Alibaba技術棧實現，那如何寫代碼具備良好的擴展性呢？

總體的原則就是面向接口編程，而非面向具體的實現類編程，具體業務邏輯里依賴的是接口，而非實現類，在接口不變的前提下，可以隨時切換具體的實現類，也可以隨時新增接口的實現類。業務中可以根據配置加載接口的某個具體實現類。

7.2 本地緩存落地實現

本地緩存的落地實現示意圖如圖8所示。

圖片

可以看到，具體秒殺業務中會依賴本地緩存的接口，而非具體的實現類。

本地緩存的接口可以有多個實現類，在秒殺業務中可以根據具體的配置項指定要加載并使用哪個實現類，也可以根據具體的需求和業務場景隨時新增本地接口的實現類，大大提高了程序的擴展性。

7.3 分布式緩存落地實現

分布式緩存的落地實現示意圖如圖9所示。

圖片

可以看到，分布式緩存在擴展性方面的設計與本地緩存類似，同樣是秒殺系統在具體業務中依賴分布式緩存的接口，而非分布式緩存的具體實現類。

分布式緩存的接口可以有多個實現類，在秒殺業務中可以根據具體的配置項加載并實例化具體的實現類，也可以根據具體的需求和業務場景新增分布式緩存接口的實現類，提高了實現分布式緩存程序的擴展性。

八、總結

緩存不僅僅可以用來存儲熱點數據，提升熱點數據的讀性能，還是業務系統中抗高并發、大流量的利器。

以秒殺系統為例，采用本地緩存+分布式緩存的混合型緩存方案時，如果整個秒殺系統前置的流量管控、流量清洗和限流等是秒殺系統流量洪峰的第一道防線，則本地緩存就是抗流量洪峰的第二道防線，而分布式緩存就是第三道防線，經過層層流量過濾，最終進入數據庫的流量就比較可控了。

同時，引入本地緩存+分布式緩存的混合型緩存方案后，要考慮緩存的刷新機制，數據一致性問題，在代碼落地的過程中，還要最大程度避免緩存穿透、擊穿和雪崩問題，并實現代碼的高度可擴展性。

在提供的開源方案中，已經解決了緩存穿透、擊穿和雪崩問題，開源地址如下：

• GitHub：https://github.com/binghe001/spring-redis
• Gitee：https://gitee.com/binghe001/spring-redis
• GitCode：https://gitcode.net/binghe001/spring-redis

如果開源方案對你有點幫助或者啟發，歡迎在代碼倉庫給個Star，讓更多的小伙伴看到它，互相學習，一起進步。