大家好，我是冰河~~

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

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

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

一、前言

通過這位小伙伴的自述，我們明顯感受到這位小伙伴對緩存的認識還是停留在簡單的存儲數(shù)據(jù)上，沒有對使用緩存背后的場景和實現(xiàn)邏輯進行深層次的思考。

在互聯(lián)網(wǎng)大廠項目中，緩存也是一種必不可少的組件，那使用緩存僅僅是為了緩存熱點數(shù)據(jù)，提升讀性能嗎？如果你對緩存的認識只是停留在這里，那就未免太淺顯了。

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

二、秒殺系統(tǒng)緩存核心訴求

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

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

圖片

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

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

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

三、秒殺系統(tǒng)緩存使用場景

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

1.秒殺系統(tǒng)接口分析

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

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

2.秒殺系統(tǒng)緩存場景

盡管獲取秒殺商品列表和獲取秒殺商品詳情的接口QPS一般會高于獲取秒殺活動列表和秒殺活動詳情的接口，但是我們在設計緩存時，需要對這些接口一視同仁，都要以嚴格的高標準來設計這些接口，不然稍有不慎，一個接口出現(xiàn)問題，就可能導致整場秒殺活動以失敗告終。秒殺系統(tǒng)緩存的使用場景如圖2所示。

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

四、混合型緩存設計

總體來說，在設計秒殺系統(tǒng)的緩存過程中，會采用 本地緩存+分布式緩存的混合型緩存 設計方案。其中，本地緩存指的就是單機緩存，比如JVM內存緩存，單機Cache緩存。

分布式緩存指的是以分布式的方式集中管理的緩存，比如Memcached、Redis等，如圖3所示。

1.抗流量洪峰

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

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

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

2.緩存集群方案

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

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

本地緩存會承接剩余的大部分流量，構筑成流量洪峰的第二道防線，而分布式緩存則是流量洪峰的第三道防線。并且在緩存的設計上，分布式緩存的作用主要是協(xié)調和同步最新數(shù)據(jù)到本地緩存。

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

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

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

3.緩存交互流程

采用本地緩存+分布式緩存的混合型緩存架構設計方案時，在讀取緩存數(shù)據(jù)時，會優(yōu)先讀取本地緩存的數(shù)據(jù)，如果本地緩存未開啟，或者已經(jīng)失效，此時就會使用分布式緩存，也就是說，優(yōu)先讀取本地緩存中的數(shù)據(jù)，如果本地緩存未開啟或者緩存數(shù)據(jù)失效，則讀取分布式緩存中的數(shù)據(jù)，如圖6所示。

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

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

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

（3）讀取本地緩存數(shù)據(jù)，讀取緩存流程結束。

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

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

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

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

這里，有一個設計技巧需要大家注意：如果本地緩存失效，并且某個線程沒有獲取到更新本地緩存的機會，這個線程需要立即返回而不是在原地阻塞等待，這種方式可以最大限度的節(jié)省服務器資源和線程切換的成本。

尤其是像在秒殺系統(tǒng)這種承接瞬時高并發(fā)流量的系統(tǒng)中，這種設計能夠節(jié)省不少服務器資源。這種線程未獲取到更新數(shù)據(jù)的機會而快速返回的機制，需要客戶端配合在適配處理，也就是說，客戶端對這種情況需要進行靜默處理，不要提示錯誤信息，也不做其他處理，稍后重新調用接口進行重試即可。

4.混合型緩存設計的優(yōu)點

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

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

可以看到，一次請求會訪問5次分布式緩存，這在無形當中就增加了分布式緩存的IO成本，這對秒殺系統(tǒng)來說，是不容忽視的風險項，稍有不慎，則系統(tǒng)可能會由于IO瓶頸引發(fā)各種事故，最終造成系統(tǒng)崩潰或者宕機。

所以，在設計秒殺系統(tǒng)時，一定要注意這種放大效應帶來的風險。所以，在高并發(fā)大流量的場景下，很有必要精心的設計本地緩存。

五、緩存刷新機制

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

為此需要以一定的策略對緩存中的數(shù)據(jù)進行刷新操作，以防止緩存中的數(shù)據(jù)長時間過期而導致大部分流量直接打入數(shù)據(jù)庫。本節(jié)，就從本地緩存和分布式緩存兩個角度簡單聊聊緩存的生命周期。

1.本地緩存刷新機制

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

對于本地緩存會實現(xiàn)兩種刷新機制：

（1）主動刷新

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

（2）被動刷新

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

2.分布式緩存刷新機制

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

（1）主動刷新

業(yè)務數(shù)據(jù)變更驅動刷新分布式緩存數(shù)據(jù)。當業(yè)務數(shù)據(jù)發(fā)生變更時，會主動刷新分布式緩存中的數(shù)據(jù)。

（2）被動刷新

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

六、數(shù)據(jù)一致性

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

1.強一致性保證

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

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

2. 弱一致性保證

強一致性保證交由業(yè)務規(guī)則和數(shù)據(jù)庫共同約束實現(xiàn)，緩存層面的數(shù)據(jù)就可以實現(xiàn)為弱一致性。也就是說，在很小的一段時間內，允許緩存中的數(shù)據(jù)存在延遲，允許緩存中的數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)在短時間內的不一致，只要在可接受的時間范圍內最終達到一致即可。充分發(fā)揮緩存的實際作用，即：緩存數(shù)據(jù)，提供系統(tǒng)的讀寫性能和抗系統(tǒng)流量。

七、緩存落地實現(xiàn)

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

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

1. 擴展性描述

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

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

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

2. 本地緩存落地實現(xiàn)

本地緩存的落地實現(xiàn)示意圖如圖8所示。

可以看到，具體秒殺業(yè)務中會依賴本地緩存的接口，而非具體的實現(xiàn)類。本地緩存的接口可以有多個實現(xiàn)類，在秒殺業(yè)務中可以根據(jù)具體的配置項指定要加載并使用哪個實現(xiàn)類，也可以根據(jù)具體的需求和業(yè)務場景隨時新增本地接口的實現(xiàn)類，大大提高了程序的擴展性。

3.分布式緩存落地實現(xiàn)

分布式緩存的落地實現(xiàn)示意圖如圖9所示。

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

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

八、總結

緩存不僅僅可以用來存儲熱點數(shù)據(jù)，提升熱點數(shù)據(jù)的讀性能，還是業(yè)務系統(tǒng)中抗高并發(fā)、大流量的利器。

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

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

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

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