大型web系統中緩存的使用

        對于一個規模很大的web系統，如PV在一億以上，緩存就是一個不可或缺的重要組成部分，它可以擋掉大部分的使用者通路的沖擊，如果沒有它，系統很可能将迅速不可用直至崩潰。

但是緩存帶來了另外一些棘手的問題： 一緻性和實時性。

一個很直覺的場景就是，資料庫中的資料狀态已經改變，但是使用者在頁面上看到的仍然是緩存的舊值。

一般來說，緩存資料本身都是保持在記憶體中的，例如淘寶内部大量使用的tair系統（已開源）。tair擁有若幹伺服器，這些伺服器記憶體都很大，可以存放大量資料。當然，考慮到記憶體的易失性，tair一般來說不能存放重要的資料。

什麼樣的資料可以放緩存，什麼樣的場景适合使用緩存，什麼場景不應該使用，這幾個問題是系統設計之初必須考慮的問題。

----

什麼樣的資料可以放緩存？

1，不需要實時更新但是又極其消耗資料庫的資料。比如網站上商品銷售排行榜，這種資料一天統計一次就可以了，使用者不會關注其是否是實時的。

2，需要實時更新，但是更新頻率不高的資料。比如一個使用者的訂單清單，他肯定希望能夠實時看到自己下的訂單，但是大部分使用者不會頻繁下單（炒信用之類的除外）。

3，在某個時刻通路量極大而且更新也很頻繁的資料。這種資料有一個很典型的例子就是秒殺，在秒殺那一刻，可能有N倍于平時的流量進來，系統壓力會很大。但是這種資料使用的緩存不能和普通緩存一樣，這種緩存必須保證不丢失，否則會有大問題。

什麼時候不應該使用緩存？

實際上在一個web站點中，大部分資料都是可以緩存的，反而不能使用緩存的是很小一部分。這類資料包括比如涉及到錢、密鑰、業務關鍵性核心資料等。有一個經驗之談就是，如果在設計web系統的時候，發現大部分資料都不能使用緩存，則說明設計或者架構本身出了問題，此時需要考慮設計的合理性了。

如何解決一緻性的問題？

一個總的原則就是：一旦資料庫更新了，就必須把原來的緩存失效掉。

有的時候要做到這一點是很困難的，似乎聽起來很可笑，但是當系統規模達到一定程度的時候，這個問題就會凸顯。在一個大的團隊中，每個開發都在系統裡面送出自己的代碼，很可能某段代碼修改了資料庫，但是忘了清緩存，造成生産環境發生故障。對于這種問題，主要得靠代碼review來解決。

另外，在故障發生的時候，我們不能束手無策，換句話說，系統内部也要有可以直接觸發的清理緩存的”接口“，這個接口可以是一個特殊的url，或者一個隻有内部才能通路的控制台等。

關于折衷的問題。。。

假設有一個資料，它更新頻繁，通路量很高，我們将其緩存，但是由于更新頻繁，是以可能會頻繁觸發清緩存操作，這樣緩存實際上就成了擺設。如果業務允許，我們不需要每次都清緩存，簡而言之，就是允許系統存在一小段時間的資料顯示不一緻的情況。這是一個比較折衷的方法，對使用者體驗而言，也無大礙。

更加進階的緩存。。。

以上說的緩存，都是資料緩存，還有一種更加進階的緩存，即把動态頁面（如JSP）進行靜态化處理，這個比資料緩存複雜的多。目前有一些開源的架構可以支援，比如varnish，性能很高，當然學習成本也很高。關于varnish的使用，本文就不贅述了，有興趣的可以自行去其官方網站查閱。

本文轉自 kevx 51CTO部落格，原文連結：http://blog.51cto.com/spinlock/851646，如需轉載請自行聯系原作者