最全面的緩存架構設計（全是幹貨）

程式員的日常那些事   2018-05-07 17:53:40

1：緩存技術和架構的重要性

網際網路的一些高并發，高性能的項目和系統中，緩存技術是起着功不可沒的作用。緩存不僅僅是key-value的簡單存取，它在具體的業務場景中，還是很複雜的，需要很強的架構設計能力。我曾經就遇到過因為緩存架構設計不到位，導緻了系統崩潰的案例。

2：緩存的技術方案分類

1）是做實時性比較高的那塊資料，比如說庫存，銷量之類的這種資料，我們采取的實時的緩存+資料庫雙寫的技術方案，雙寫一緻性保障的方案。

2）是做實時性要求不高的資料，比如說商品的基本資訊，等等，我們采取的是三級緩存架構的技術方案，就是說由一個專門的資料生産的服務，去擷取整個商品詳情頁需要的各種資料，經過處理後，将資料放入各級緩存中。

3：高并發以及高可用的複雜系統中的緩存架構都有哪些東西

1）在大型的緩存架構中，redis是最最基礎的一層。高并發，緩存架構中除了redis，還有其他的組成部分，但是redis至關重要。

• 如果你的資料量不大（10G以内），單master就可以。redis持久化+備份方案+容災方案+replication（主從+讀寫分離）+sentinal（哨兵叢集，3個節點，高可用性）
• 如果你的資料量很大（1T+），采用redis cluster。多master分布式存儲資料，水準擴容,自動進行master -> slave的主備切換。

2）最經典的緩存+資料庫讀寫的模式，cache aside pattern。讀的時候，先讀緩存，緩存沒有的話，那麼就讀資料庫。更新緩存分以下兩種方式：

• 資料發生變化時，先更新緩存，然後再更新資料庫。這種适用于緩存的值相對簡單，和資料庫的值一一對應，這樣更新比較快。
• 資料發生變化時，先删除緩存，然後再更新資料庫，讀資料的時候再設定緩存。這種适用于緩存的值比較複雜的場景。比如可能更新了某個表的一個字段，然後其對應的緩存，是需要查詢另外兩個表的資料，并進行運算，才能計算出緩存最新的值的。這樣更新緩存的代價是很高的。如果你頻繁修改一個緩存涉及的多個表，那麼這個緩存會被頻繁的更新，頻繁的更新緩存代價很高。而且這個緩存的值如果不是被頻繁通路，就得不償失了。

大部分情況下，建議适用删除更新的方式。其實删除緩存，而不是更新緩存，就是一個lazy計算的思想，不要每次都重新做複雜的計算，不管它會不會用到，而是讓它到需要被使用的時候再重新計算。

舉個例子，一個緩存涉及的表的字段，在1分鐘内就修改了20次，或者是100次，那麼緩存跟新20次，100次; 但是這個緩存在1分鐘内就被讀取了1次，有大量的冷資料。28黃金法則，20%的資料，占用了80%的通路量。實際上，如果你隻是删除緩存的話，那麼1分鐘内，這個緩存不過就重新計算一次而已，開銷大幅度降低。每次資料過來，就隻是删除緩存，然後修改資料庫，如果這個緩存，在1分鐘内隻是被通路了1次，那麼隻有那1次，緩存是要被重新計算的。

3）資料庫與緩存雙寫不一緻問題的解決方案

問題：并發請求的時候，資料發生了變更，先删除了緩存，然後要去修改資料庫，此時還沒修改。另一個請求過來，去讀緩存，發現緩存空了，去查詢資料庫，查到了修改前的舊資料，放到了緩存中。

方案：資料庫與緩存更新與讀取操作進行異步串行化。（引入隊列）

更新資料的時候，将相應操作發送到一個jvm内部的隊列中。讀取資料的時候，如果發現資料不在緩存中，那麼将重新讀取資料的操作也發送到同一個jvm内部的隊列中。隊列消費者串行拿到對應的操作，然後一條一條的執行。這樣的話，一個資料變更的操作，先執行删除緩存，然後再去更新資料庫，但是還沒完成更新。此時如果一個讀請求過來，讀到了空的緩存，那麼可以先将緩存更新的請求發送到隊列中，此時會在隊列中積壓，然後同步等待緩存更新完成。

這裡有兩個可以優化的點：

• 一個隊列中，其實多個讀緩存，更新緩存的請求串在一起是沒意義的，而且如果讀同一緩存的大量請求到來時，會依次進入隊列等待，這樣會導緻隊列最後一個的請求響應時間逾時。是以可以做過濾，如果發現隊列中已經有一個讀緩存，更新緩存的請求了，那麼就不用再放個新請求操作進去了，直接等待前面的更新操作請求完成即可。如果請求還在等待時間範圍内，不斷輪詢發現可以取到值了，那麼就直接傳回; 如果請求等待的時間超過一定時長，那麼這一次直接從資料庫中讀取目前的舊值。
• 如果請求量特别大的時候，可以用多個隊列，每個隊列對應一個線程。每個請求來時可以根據請求的辨別id進行hash路由進入到不同的隊列。

最後，一定要做根據實際業務系統的運作情況，去進行一些壓力測試，和模拟線上環境，去看看最繁忙的時候，記憶體隊列可能會擠壓多少更新操作，可能會導緻最後一個更新操作對應的讀請求，會hang多少時間，如果讀請求在200ms傳回，如果你計算過後，哪怕是最繁忙的時候，積壓10個更新操作，最多等待200ms，那還可以的。如果一個記憶體隊列可能積壓的更新操作特别多，那麼你就要加機器，讓每個機器上部署的服務執行個體處理更少的資料，那麼每個記憶體隊列中積壓的更新操作就會越少。其實根據之前的項目經驗，一般來說資料的寫頻率是很低的，是以實際上正常來說，在隊列中積壓的更新操作應該是很少的。

舉個例子：一秒就100個寫操作。單台機器，20個記憶體隊列，每個記憶體隊列，可能就積壓5個寫操作，每個寫操作性能測試後，一般在20ms左右就完成，那麼針對每個記憶體隊列中的資料的讀請求，也就最多hang一會兒，200ms以内肯定能傳回了。如果把寫QPS擴大10倍，但是經過剛才的測算，就知道，單機支撐寫QPS幾百沒問題，那麼就擴容機器，擴容10倍的機器，10台機器，每個機器20個隊列，200個隊列。大部分的情況下，應該是這樣的，大量的讀請求過來，都是直接走緩存取到資料的，少量情況下，可能遇到讀跟資料更新沖突的情況，如上所述，那麼此時更新操作如果先入隊列，之後可能會瞬間來了對這個資料大量的讀請求，但是因為做了去重的優化，是以也就一個更新緩存的操作跟在它後面。

4）大型緩存全量更新問題的解決方案

問題：緩存資料很大時，可能導緻redis的吞吐量就會急劇下降，網絡耗費的資源大。如果不次元化，就導緻多個次元的資料混合在一個緩存value中。而且不同次元的資料，可能更新的頻率都大不一樣。拿商品詳情頁來說，如果現在隻是将1000個商品的分類批量調整了一下，但是如果商品分類的資料和商品本身的資料混雜在一起。那麼可能導緻需要将包括商品在内的大緩存value取出來，進行更新，再寫回去，就會很坑爹，耗費大量的資源，redis壓力也很大

方案：緩存次元化。舉個例子：商品詳情頁分三個次元：商品次元，商品分類次元，商品店鋪次元。将每個次元的資料都存一份，比如說商品次元的資料存一份，商品分類的資料存一份，商品店鋪的資料存一份。那麼在不同的次元資料更新的時候，隻要去更新對應的次元就可以了。大大減輕了redis的壓力。

5）通過多級緩存，達到高并發極緻，同時給緩存架構最後的安全保護層。具體可以參照上一篇文章【億級流量的商品詳情頁架構分析】。

6）分布式并發緩存重建的沖突問題的解決方案

問題：假如資料在所有的緩存中都不存在了（LRU算法弄掉了），就需要重新查詢資料寫入緩存。對于分布式的重建緩存，在不同的機器上，不同的服務執行個體中，去做上面的事情，就會出現多個機器分布式重建去讀取相同的資料，然後寫入緩存中。

方案：分布式鎖：如果你有多個機器在通路同一個共享資源，那麼這個時候，如果你需要加個鎖，讓多個分布式的機器在通路共享資源的時候串行起來。分布式鎖當然有很多種不同的實作方案，redis分布式鎖，zookeeper分布式鎖。

zookeeper分布式鎖的解決并發沖突的方案

• （1）變更緩存重建以及空緩存請求重建，更新redis之前，都需要先擷取對應商品id的分布式鎖
• （2）拿到分布式鎖之後，需要根據時間版本去比較一下，如果自己的版本新于redis中的版本，那麼就更新，否則就不更新
• （3）如果拿不到分布式鎖，那麼就等待，不斷輪詢等待，直到自己擷取到分布式的鎖

7）緩存冷啟動的問題的解決方案

問題：新系統第一次上線，此時在緩存裡可能是沒有資料的。或者redis緩存全盤崩潰了，資料也丢了。導緻所有請求打到了mysql。導緻mysql直接挂掉。

方案：緩存預熱。

• 提前給redis中灌入部分資料，再提供服務
• 肯定不可能将所有資料都寫入redis，因為資料量太大了，第一耗費的時間太長了，第二根本redis容納不下所有的資料，需要根據當天的具體通路情況，實時統計出通路頻率較高的熱資料，然後将通路頻率較高的熱資料寫入redis中，肯定是熱資料也比較多，我們也得多個服務并行讀取資料去寫，并行的分布式的緩存預熱。

8）恐怖的緩存雪崩問題的解決方案

問題：緩存服務大量的資源全部耗費在通路redis和源服務無果，最後自己被拖死，無法提供服務。

方案：相對來說，考慮的比較完善的一套方案，分為事前，事中，事後三個層次去思考怎麼來應對緩存雪崩的場景。

• 事前：高可用架構。主從架構，操作主節點，讀寫，資料同步到從節點，一旦主節點挂掉，從節點跟上。
• 事中：多級緩存。redis cluster已經徹底崩潰了，緩存服務執行個體的ehcache的緩存還能起到作用。
• 事後：redis資料可以恢複，做了備份，redis資料備份和恢複，redis重新啟動起來。

9）緩存穿透問題的解決方案

問題：緩存中沒有這樣的資料，資料庫中也沒有這樣的資料。由于緩存是不命中時被動寫的，并且出于容錯考慮，如果從存儲層查不到資料則不寫入緩存，這将導緻這個不存在的資料每次請求都要到存儲層去查詢，失去了緩存的意義。在流量大時，可能DB就挂掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。

方案：有很多種方法可以有效地解決緩存穿透問題，最常見的則是采用布隆過濾器，将所有可能存在的資料哈希到一個足夠大的bitmap中，一個一定不存在的資料會被 這個bitmap攔截掉，進而避免了對底層存儲系統的查詢壓力。另外也有一個更為簡單粗暴的方法（我們采用的就是這種），如果一個查詢傳回的資料為空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。