許多大型互聯網系統，如電商、社交、新聞等App或網站，動輒日活千萬甚至上億，每分鐘的峰值流量在數十萬以上，架構上如何應對如此高的流量峰值呢？

本文介紹如何通過“緩存”技術來給系統減壓。流量峰值給系統帶來的主要危害在于，它會瞬間產生大量對磁盤數據的讀取和搜索，通常數據源是數據庫或文件系統，當數據訪問次數增大時，過多的磁盤讀取可能會最終成為整個系統的性能瓶頸，甚至壓垮整個數據庫，導致系統卡死、服務不可用等嚴重后果。

常規的應用系統通常會在需要的時候對數據庫進行查找，因此系統的大致結構如下。

當數據量較大時，需要減少對數據庫磁盤的讀寫操作，因此通常都會選擇在業務系統和數據庫之間加入一層緩存（Cache），從而減少數據庫的訪問壓力，結構如下。?

緩存在實際的應用中并非如此簡單，下面通過幾個比較經典的緩存應用場景來看一些問題。

▊ 緩存和數據庫之間的數據一致性問題

常用的緩存處理機制有如下幾種。

Cache Aside 模式

種模式通常都先從數據庫緩存開始查找，如果緩存沒有命中，則從數據庫中查找。該模式會發生如下三種情況。

● 緩存命中：當查找的時候發現緩存中存在查找的數據，那么直接從緩存中提取。

● 緩存失效：當緩存中沒有數據的時候，則從數據庫里面讀取源數據，再同步到緩存中。

● 緩存更新：當有新的寫操作去修改數據庫里面的數據時，需要在寫操作完成之后，讓緩存里面對應的數據失效，做緩存同步。

Cache Aside模式是在實際應用開發中最常用的模式，但這種模式的緩存處理并不完美。

例如，一個讀操作沒有命中緩存，然后到數據庫中取數據，此時發生一個寫操作，在數據庫中完成寫操作后，讓緩存失效，然后之前的讀操作再把老的數據放進去，就會出現臟數據。

分布式環境中要想完全保證數據一致性是一件極為困難的事情，只能夠盡可能地減少數據不一致性問題。

Read?Through模式

指應用程序始終從緩存中請求數據，如果緩存中沒有數據，則它負責使用底層提供的程序插件從數據庫中檢索數據，檢索數據后，緩存會自行更新并將數據返回給調用的應用程序。

使用Read Through模式有一個好處，由于總是使用key從緩存中檢索數據，調用的應用程序不知道數據庫，而由存儲方來負責自己的緩存處理，這使得代碼更具可讀性，更清晰。

但Read Through模式也有相應的缺陷，開發人員需要編寫相關的程序插件，增加了開發的難度。

Write Through模式

和Read Through模式類似，當數據進行更新時，先去緩存中進行更新，如果命中，則先更新緩存再由緩存方來更新數據庫。如果沒有命中，就直接更新緩存里面的數據。

Write Behind Caching模式

這種模式通常先將數據寫入緩存，再異步地寫入數據庫進行數據同步。

這樣的設計既可以減少對數據庫的直接訪問，降低壓力，同時對數據庫的多次修改可以合并操作，極大地提升了系統的承載能力。

但是使用Write Behind Caching模式處理緩存數據有一定的風險，如當緩存機器出現宕機時，數據有丟失的可能。

▊ 緩存在高并發場景中存在的問題

緩存過期后請求將嘗試從后端數據庫獲取數據，這是一個看似合理的流程。但是，在高并發場景下，有可能多個請求并發地從數據庫獲取數據，會對后端數據庫造成極大的沖擊，甚至導致“雪崩”。

此外，當某個緩存key被更新時，也可能被大量請求獲取，這也會導致一致性問題。那么如何避免類似問題呢？可以使用類似“鎖”的機制，在緩存更新或者過期的情況下，先嘗試獲取鎖，當更新或者從數據庫獲取完成后再釋放鎖，其他請求只需要一定的等待時間即可直接從緩存中繼續獲取數據。

緩存穿透問題

緩存穿透也稱為“緩存擊穿”。很多朋友對緩存穿透的理解是：由于緩存故障或者緩存過期導致大量請求穿透到后端數據庫服務器，從而對數據庫造成巨大沖擊。

這其實是一種誤解。真正的緩存穿透應該是：在高并發場景下，如果某個key被高并發訪問，沒有命中，出于容錯性考慮，會嘗試從后端數據庫中獲取數據，從而導致大量請求到達數據庫，而當該key對應的數據本身為空時，就會導致數據庫中并發地執行很多不必要的查詢操作，從而給數據庫帶來巨大的沖擊和壓力。

可以通過如下常用方式來避免緩存穿透問題。

●?緩存空對象

對查詢結果為空的對象也進行緩存，如果是集合，則可以緩存一個空的集合（非null），如果是單個對象，則可以通過字段標識來區分。這樣可以避免請求穿透到后端數據庫，保證緩存數據的時效性。

這種方式實現起來成本較低，比較適合命中率不高但可能被頻繁更新的數據。

●?單獨過濾處理

對所有對應數據可能為空的key進行統一存放，并在請求前做攔截，可以避免請求穿透到后端數據庫。

這種方式實現起來相對復雜，比較適合命中率不高但是更新不頻繁的數據。

緩存顛簸問題

也被稱為“緩存抖動”，可以看作一種比“雪崩”更輕微的故障，但是也會在一段時間內對系統造成沖擊和性能影響，一般是由緩存節點故障導致的。業內推薦的做法是通過一致性Hash算法來解決問題。

緩存的雪崩

由于緩存的原因，導致大量請求到達后端數據庫，從而導致數據庫崩潰，進而整個系統崩潰，發生災難。原因有很多種，上文提到的“緩存并發”“緩存穿透”“緩存顛簸”等問題，都可能導致緩存的雪崩。這些問題還可能被惡意攻擊者利用。

還有一種情況，例如在某個時間點，系統預加載的緩存周期性地集中失效了，也可能會導致雪崩。為了避免緩存周期性地集中失效，可以通過設置不同的過期時間來錯開緩存過期時間。

從應用架構的角度，可以通過限流、降級、熔斷等手段來降低緩存雪崩的影響，也可以通過多級緩存來避免這種災難。

此外，從整個研發體系流程的角度，應該加強壓力測試，盡量模擬真實場景，盡早地暴露問題，從而加以防范。

緩存是大型互聯網系統架構中常用的一種技術，在設計緩存架構的過程中，要根據業務場景進行有針對性的設計，避免緩存延遲、臟數據、緩存雪崩等問題，提高系統的高可用性和健壯性。

本文節選自《技術人修煉之道：從程序員到百萬高管的72項技能》一書。

這本書按照技術職場人的成長軌跡，首先關注技術人的職場定位、思維方式升級、職場溝通、架構思維、學習能力和創新能力。然后介紹從技術轉管理會踩的坑、有效管理的原則、打造高效組織架構、團隊高效執行力、技術人才的選用育留、管理者的自我修養、管理者的商業思維。全書總結了從程序員到技術高管，所需的72項技能。這些技能來自50多位一線互聯網公司從業者的經驗總結，以及作者將近20年的職場經驗。

贈書福利

大家可以在留言中就自己對于 [技術人學習、成長、管理]話題進行分享~

我們會在留言中選出點贊前5名粉絲，包郵送出電子工業出版社博文視點贊助的《技術人修煉之道：從程序員到百萬高管的72項技能》新書一本！

快來參與吧！

- EOF -想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信 申請備注（姓名+公司+技術方向）才能通過哦！END ? ?? #架構師必備#點分享點點贊點在看 新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的黄哲铿：妙用“缓存”，应对亿级流量峰值（文末赠书）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。