一、為什麽要使用緩存

為什麽要使用緩存呢？源於人類的一個夢想，就是多快好省的建設社會主義。

多快好省？很多客戶都這麽要求，但是作為具體做技術的你，當然知道，好就不能快，多就沒法省。

可是沒辦法，客戶都這樣要求：

這個能不能便宜一點，你咋這麽貴呀，你看人家都很便宜的。(您好，這種打折的房間比較靠裏，是不能面向大海的)

你們的性能怎麽這麽差啊，用你這個系統跑的這麽慢，你看人家廣告中說速度能達到多少多少。(您好，你如果買一個頂配的，我們也是有這種性能的)

你們服務不行啊，你就不能彬彬有禮，穿著整齊，送點水果瓜子啥的？(您好，我們蘭州拉面館沒有這項服務，可以去對面的俏江南看一下)

這麽貴的菜，一盤就這麽一點點，都吃不飽，就不能上一大盤麽。（您好，對面的蘭州拉面10塊錢一大碗）

怎麽辦呢？勞動人民還是很有智慧的，就是聚焦核心需求，讓最最核心的部分享用好和快，而非核心的部門就多和省就可以了。

你可以大部分時間住在公司旁邊的出租屋裏面，但是出去度假的一個星期，選一個面朝大海，春暖花開的五星級酒店。

你可以大部分時間都擠地鐵，擠公交，跋涉2個小時從北五環到南五環，但是有急事的時候，你可以打車，想旅遊的時候，可以租車。

你可以大部分時間都吃普通的餐館，而朋友來了，就去高級飯店裏面搓一頓。

在計算機世界也是這樣樣子的，如圖所示。

越是快的設備，存儲量越小，越貴，而越是慢的設備，存儲量越大，越便宜。

對於一家電商來講，我們既希望存儲越來越多的數據，因為數據將來就是資產，就是財富，只有有了數據，我們才知道用戶需要什麽，同時又希望當我想訪問這些數據的時候，能夠快速的得到，雙十一拼的就是速度和用戶體驗，要讓用戶有流暢的感覺。

所以我們要講大量的數據都保存下來，放在便宜的存儲裏面，同時將經常訪問的，放在貴的，小的存儲裏面，當然貴的快的往往比較資源有限，因而不能長時間被某些數據長期霸占，所以要大家輪著用，所以叫緩存，也就是暫時存著。

二、都有哪些類型的緩存

當一個應用剛開始的時候，架構比較簡單，往往就是一個Tomcat，後面跟著一個數據庫。

然而數據庫相當於我們應用的中軍大帳，是我們整個架構中最最關鍵的一部分，也是最不能掛，也最不能會被攻破的一部分，因而所有對數據庫的訪問都需要一道屏障來進行保護，常用的就是緩存。

我們以Tomcat為分界線，之外我們稱為接入層，接入層當然應該有緩存，還有CDN。

Tomcat之後，我們稱為應用層，應用層也應該有緩存，這是我們這一節討論的重點。

最簡單的方式就是Tomcat裏面有一層緩存，常稱為本地緩存LocalCache。

這類的緩存常見的有Ehcache和Guava Cache，由於這類緩存在Tomcat本地，因而訪問速度是非常快的。

但是本地緩存有個比較大的缺點，就是緩存是放在JVM裏面的，會面臨Full GC的問題，一旦出現了FullGC，就會對應用的性能和相應時間產生影響，當然也可以嘗試jemalloc的分配方式。

還有一種方式，就是在Tomcat和Mysql中間加了一層Cache，我們常稱為分布式緩存。

分布式緩存常見的有Memcached和Redis，兩者各有優缺點。

Memcached適合做簡單的key-value存儲，內存使用率比較高，而且由於是多核處理，對於比較大的數據，性能較好。

但是缺點也比較明顯，Memcached嚴格來講沒有集群機制，橫向擴展完全靠客戶端來實現。另外Memcached無法持久化，一旦掛了數據就都丟失了，如果想實現高可用，也是需要客戶端進行雙寫才可以。

所以可以看出Memcached真的是設計出來，簡簡單單為了做一個緩存的。

Redis的數據結構就豐富的多了，單線程的處理所有的請求，對於比較大的數據，性能稍微差一點。

Redis提供持久化的功能，包括RDB的全量持久化，或者AOF的增量持久化，從而使得Redis掛了，數據是有機會恢復的。

Redis提供成熟的主備同步，故障切換的功能，從而保證了高可用性。

所以很多地方管Redis稱為內存數據庫，因為他的一些特性已經有了數據庫的影子。

這也是很多人願意用Redis的原因，集合了緩存和數據庫的優勢，但是往往會濫用這些優勢，從而忽略了架構層面的設計，使得Redis集群有很大的風險。

很多情況下，會將Redis當做數據庫使用，開啟持久化和主備同步機制，以為就可以高枕無憂了。

然而Redis的持久化機制，全量持久化則往往需要額外較大的內存，而在高並發場景下，內存本來就很緊張，如果造成swap，就會影響性能。增量持久化也涉及到寫磁盤和fsync，也是會拖慢處理的速度，在平時還好，如果高並發場景下，仍然會影響吞吐量。

所以在架構設計角度，緩存就是緩存，要意識到數據會隨時丟失的，要意識到緩存的存著的目的是攔截到數據庫的請求。如果為了保證緩存的數據不丟失，從而影響了緩存的吞吐量，甚至穩定性，讓緩存響應不過來，甚至掛掉，所有的請求擊穿到數據庫，就是更加嚴重的事情了。

如果非常需要進行持久化，可以考慮使用levelDB此類的，對於隨機寫入性能較好的key-value持久化存儲，這樣只有部分的確需要持久化的數據，才進行持久化，而非無論什麽數據，通通往Redis裏面扔，同時統一開啟了持久化。

三、基於緩存的架構設計要點

所以基於緩存的設計：

1、多層次

這樣某一層的緩存掛了，還有另一層可以撐著，等待緩存的修復，例如分布式緩存因為某種原因掛了，因為持久化的原因，同步機制的原因，內存過大的原因等，修復需要一段時間，在這段時間內，至少本地緩存可以抗一陣，不至於一下子就擊穿數據庫。而且對於特別特別熱的數據，熱到導致集中式的緩存處理不過來，網卡也被打滿的情況，由於本地緩存不需要遠程調用，也是分布在應用層的，可以緩解這種問題。

2、分場景

到底要解決什麽問題，可以選擇不同的緩存。是要存儲大的無格式的數據，還是要存儲小的有格式的數據，還是要存儲一定需要持久化的數據。具體的場景下一節詳細談。

3、要分片

使得每一個緩存實例都不大，但是實例數目比較多，這樣一方面可以實現負載均衡，防止單個實例稱為瓶頸或者熱點，另一方面如果一個實例掛了，影響面會小很多，高可用性大大增強。分片的機制可以在客戶端實現，可以使用中間件實現，也可以使用Redis的Cluster的方式，分片的算法往往都是哈希取模，或者一致性哈希。

四、緩存的使用場景

當你的應用扛不住，知道要使用緩存了，應該怎麽做呢？

場景1：和數據庫中的數據結構保持一致，原樣緩存

這種場景是最常見的場景，也是很多架構使用緩存的適合，最先涉及到的場景。

基本就是數據庫裏面啥樣，我緩存也啥樣，數據庫裏面有商品信息，緩存裏面也放商品信息，唯一不同的是，數據庫裏面是全量的商品信息，緩存裏面是最熱的商品信息。

每當應用要查詢商品信息的時候，先查緩存，緩存沒有就查數據庫，查出來的結果放入緩存，從而下次就查到了。

這個是緩存最最經典的更新流程。這種方式簡單，直觀，很多緩存的庫都默認支持這種方式。

場景2：列表排序分頁場景的緩存

有時候我們需要獲得一些列表數據，並對這些數據進行排序和分頁。

例如我們想獲取點贊最多的評論，或者最新的評論，然後列出來，一頁一頁的翻下去。

在這種情況下，緩存裏面的數據結構和數據庫裏面完全不一樣。

如果完全使用數據庫進行實現，則按照某種條件將所有的行查詢出來，然後按照某個字段進行排序，然後進行分頁，一頁一頁的展示。

但是當數據量比較大的時候，這種方式往往成為瓶頸，首先涉及的數據庫行數比較多，而且排序也是個很慢的活，盡管可能有索引，分頁也是翻頁到最後，越是慢。

在緩存裏面，就沒必要每行一個key了，而是可以使用Redis的列表方式進行存儲，當然列表的長短是有限制的，肯定放不下數據庫裏面這麽多，但是大家會發現其實對於所有的列表，用戶往往沒有耐心看個十頁八頁的，例如百度上搜個東西，也是有排序和分頁的，但是你每次都往後翻了嗎，每頁就十條，就算是十頁，或者一百頁，也就一千條數據，如果保持ID的話，完全放的下。

如果已經排好序，放在Redis裏面，那取出列表，翻頁就非常快了。

可以後臺有一個線程，異步的初始化和刷新緩存，在緩存裏面保存一個時間戳，當有更新的時候，刷新時間戳，異步任務發現時間戳改變了，就刷新緩存。

場景3：計數緩存

計數對於數據庫來講，是一個非常繁重的工作，需要查詢大量的行，最後得出計數的結論，當數據改變的時候，需要重新刷一遍，非常影響性能。

因此可以有一個計數服務，後端是一個緩存，將計數作為結果放在緩存裏面，當數據有改變的時候，調用計數服務增加或者減少計數，而非通過異步數據庫count來更新緩存。

計數服務可以使用Redis進行單個計數，或者hash表進行批量計數

場景4：重構維度緩存

有時候數據庫裏面保持的數據的維度是為了寫入方便，而非為了查詢方便的，然而同時查詢過程，也需要處理高並發，因而需要為了查詢方便，將數據重新以另一個維度存儲一遍，或者說將多給數據庫的內容聚合一下，再存儲一遍，從而不用每次查詢的時候都重新聚合，如果還是放在數據庫，比較難維護，放在緩存就好一些。

例如一個商品的所有的帖子和帖子的用戶，以及一個用戶發表過的所有的帖子就是屬於兩個維度。

這需要寫入一個維度的時候，同時異步通知，更新緩存中的另一個維度。

在這種場景下，數據量相對比較大，因而單純用內存緩存memcached或者redis難以支撐，往往會選擇使用levelDB進行存儲，如果levelDB的性能跟不上，可以考慮在levelDB之前，再來一層memcached。

場景5：較大的詳情內容數據緩存

對於評論的詳情，或者帖子的詳細內容，屬於非結構化的，而且內容比較大，因而使用memcached比較好。

五、緩存三大矛盾問題

1、緩存實時性和一致性問題：當有了寫入後咋辦？

雖然使用了緩存，大家心裏都有一個預期，就是實時性和一致性得不到完全的保證，畢竟數據保存了多份，數據庫一份，緩存中一份，當數據庫中因寫入而產生了新的數據，往往緩存是不會和數據庫操作放在一個事務裏面的，如何將新的數據更新到緩存裏面，什麽時候更新到緩存裏面，不同的策略不一樣。

從用戶體驗角度，當然是越實時越好，用戶體驗越流暢，完全從這個角度出發，就應該有了寫入，馬上廢棄緩存，觸發一次數據庫的讀取，從而更新緩存。但是這和第三個問題，高並發就矛盾了，如果所有的都實時從數據庫裏面讀取，高並發場景下，數據庫往往受不了。

2、緩存的穿透問題：當沒有讀到咋辦？

為什麽會出現緩存讀取不到的情況呢？

第一：可能讀取的是冷數據，原來從來沒有訪問過，所以需要到數據庫裏面查詢一下，然後放入緩存，再返回給客戶。

第二：可能數據因為有了寫入，被實時的從緩存中刪除了，就如第一個問題中描述的那樣，為了保證實時性，當數據庫中的數據更新了之後，馬上刪除緩存中的數據，導致這個時候的讀取讀不到，需要到數據庫裏面查詢後，放入緩存，再返回給客戶。

第三：可能是緩存實效了，每個緩存數據都會有實效時間，過了一段時間沒有被訪問，就會失效，這個時候數據就訪問不到了，需要訪問數據庫後，再放入緩存。

第四：數據被換出，由於緩存內存是有限的，當使用快滿了的時候，就會使用類似LRU策略，將不經常使用的數據換出，所以也要訪問數據庫。

第五：後端確實也沒有，應用訪問緩存沒有，於是查詢數據庫，結果數據庫裏面也沒有，只好返回客戶為空，但是尷尬的是，每次出現這種情況的時候，都會面臨著一次數據庫的訪問，純屬浪費資源，常用的方法是，講這個key對應的結果為空的事實也進行緩存，這樣緩存可以命中，但是命中後告訴客戶端沒有，減少了數據庫的壓力。

無論哪種原因導致的讀取緩存讀不到的情況，該怎麽辦？是個策略問題。

一種是同步訪問數據庫後，放入緩存，再返回給客戶，這樣實時性最好，但是給數據庫的壓力也最大。

另一種方式就是異步的訪問數據庫，暫且返回客戶一個fallback值，然後同時觸發一個異步更新，這樣下次就有了，這樣數據庫壓力小很多，但是用戶就訪問不到實時的數據了。

3、緩存對數據庫高並發訪問：都來訪問數據庫咋辦？

我們本來使用緩存，是來攔截直接訪問數據庫請求的，從而保證數據庫大本營永遠處於健康的狀態。但是如果一遇到不命中，就訪問數據庫的話，平時沒有什麽問題，但是大促情況下，數據庫是受不了的。

一種情況是多個客戶端，並發狀態下，都不命中了，於是並發的都來訪問數據庫，其實只需要訪問一次就好，這種情況可以通過加鎖，只有一個到後端來實現。

另外就是即便采取了上述的策略，依然並發量非常大，後端的數據庫依然受不了，則需要通過降低實時性，將緩存攔在數據庫前面，暫且撐住，來解決。

六、解決緩存三大矛盾的刷新策略

1、實時策略

所謂的實時策略，是平時緩存使用的最常用的策略，也是保持實時性最好的策略。

讀取的過程，應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功後，放到緩存中。如果命中，應用程序從cache中取數據，取到後返回。

寫入的過程，把數據存到數據庫中，成功後，再讓緩存失效，失效後下次讀取的時候，會被寫入緩存。那為什麽不直接寫緩存呢？因為如果兩個線程同時更新數據庫，一個將數據庫改為10，一個將數據庫改為20，數據庫有自己的事務機制，可以保證如果20是後提交的，數據庫裏面改為20，但是回過頭來寫入緩存的時候就沒有事務了，如果改為20的線程先更新緩存，改為10的線程後更新緩存，於是就會長時間出現緩存中是10，但是數據庫中是20的現象。

這種方式實時性好，用戶體驗好，是默認應該使用的策略。

2、異步策略

所謂異步策略，就是當讀取的時候讀不到的時候，不直接訪問數據庫，而是返回一個fallback數據，然後往消息隊列裏面放入一個數據加載的事件，在背後有一個任務，收到事件後，會異步的讀取數據庫，由於有隊列的作用，可以實現消峰，緩沖對數據庫的訪問，甚至可以將多個隊列中的任務合並請求，合並更新緩存，提高了效率。

當更新的時候，異步策略總是先更新數據庫和緩存中的一個，然後異步的更新另一個。

一是先更新數據庫，然後異步更新緩存。當數據庫更新後，同樣生成一個異步消息，放入消息隊列中，等待背後的任務通過消息進行緩存更新，同樣可以實現消峰和任務合並。缺點就是實時性比較差，估計要過一段時間才能看到更新，好處是數據持久性可以得到保證。

一是先更新緩存，然後異步更新數據庫。這種方式讀取和寫入都用緩存，將緩存完全擋在了數據庫的前面，把緩存當成了數據庫在用。所以一般會使用有持久化機制和主備的redis，但是仍然不能保證緩存不丟數據，所以這種情況適用於並發量大，但是數據沒有那麽關鍵的情況，好處是實時性好。

在實時策略扛不住大促的時候，可以根據場景，切換到上面的兩種模式的一個，算是降級策略。

3、定時策略

如果並發量實在太大，數據量也大的情況，異步都難以滿足，可以降級為定時刷新的策略，這種情況下，應用只訪問緩存，不訪問數據庫，更新頻率也不高，而且用戶要求也不高，例如詳情，評論等。

這種情況下，由於數據量比較大，建議將一整塊數據拆分成幾部分進行緩存，而且區分更新頻繁的和不頻繁的，這樣不用每次更新的時候，所有的都更新，只更新一部分。並且緩存的時候，可以進行數據的預整合，因為實時性不高，讀取預整合的數據更快。

哦對了，喜歡就別忘了關註一下哦~

微服務該如何設計緩存？