前言

在高併發場景下，需要通過快取來減少資料庫的壓力，使得大量的訪問進來能夠命中快取，只有少量的需要到資料庫層。由於快取基於記憶體，可支援的併發量遠遠大於基於硬碟的資料庫。所以對於高併發設計，快取的設計時必不可少的一環。

一、為什麼要使用快取

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

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

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

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

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

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

這麼貴的菜，一盤就這麼一點點，都吃不飽，就不能上一大盤麼。（您好，對面的蘭州拉麵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叢集有很大的風險。Java架構交流學習圈：681065582 面向具有Java開發經驗人群 幫助突破瓶頸 提升思維能力

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

 

 

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

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

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

三、基於快取的架構設計要點

所以基於快取的設計：

1、多層次

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

2、分場景

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

3、要分片

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

四、快取的使用場景

當你的應用扛不住，知道要使用快取了，應該怎麼做呢？

場景1：和資料庫中的資料結構保持一致，原樣快取

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

基本就是資料庫裡面啥樣，我快取也啥樣，資料庫裡面有商品資訊，快取裡面也放商品資訊，唯一不同的是，資料庫裡面是全量的商品資訊，快取裡面是最熱的商品資訊。

每當應用要查詢商品資訊的時候，先查快取，快取沒有就查資料庫，查出來的結果放入快取，從而下次就查到了。

這個是快取最最經典的更新流程。這種方式簡單，直觀，很多快取的庫都預設支援這種方式。

場景2：列表排序分頁場景的快取

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

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

在這種情況下，快取裡面的資料結構和資料庫裡面完全不一樣。

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

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

在快取裡面，就沒必要每行一個key了，而是可以使用Redis的列表方式進行儲存，當然列表的長短是有限制的，肯定放不下資料庫裡面這麼多，但是大家會發現其實對於所有的列表，使用者往往沒有耐心看個十頁八頁的，例如百度上搜個東西，也是有排序和分頁的，但是你每次都往後翻了嗎，每頁就十條，就算是十頁，或者一百頁，也就一千條資料，如果保持ID的話，完全放的下。Java架構交流學習圈：681065582 面向具有Java開發經驗人群 幫助突破瓶頸 提升思維能力

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

可以後臺有一個執行緒，非同步的初始化和重新整理快取，在快取裡面儲存一個時間戳，當有更新的時候，重新整理時間戳，非同步任務發現時間戳改變了，就重新整理快取。

場景3：計數快取

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

因此可以有一個計數服務，後端是一個快取，將計數作為結果放在快取裡面，當資料有改變的時候，呼叫計數服務增加或者減少計數，而非通過非同步資料庫count來更新快取。

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

場景4：重構維度快取

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

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

這需要寫入一個維度的時候，同時非同步通知，更新快取中的另一個維度。

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

場景5：較大的詳情內容資料快取

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

五、快取三大矛盾問題

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

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

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

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

為什麼會出現快取讀取不到的情況呢？

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

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

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

第四：資料被換出，由於快取記憶體是有限的，當使用快滿了的時候，就會使用類似LRU策略，將不經常使用的資料換出，所以也要訪問資料庫。

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

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

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

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

3、快取對資料庫高併發訪問：都來訪問資料庫咋辦？

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

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

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

六、解決快取三大矛盾的重新整理策略

1、實時策略

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

讀取的過程，應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。如果命中，應用程式從cache中取資料，取到後返回。Java架構交流學習圈：681065582 面向具有Java開發經驗人群 幫助突破瓶頸 提升思維能力

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

這種方式實時性好，使用者體驗好，是預設應該使用的策略。

2、非同步策略

相關推薦