大型web系統中快取的使用

對於乙個規模很大的web系統，如pv在一億以上，快取就是乙個不可或缺的重要組成部分，它可以擋掉大部分的使用者訪問的衝擊，如果沒有它，系統很可能將迅速不可用直至崩潰。

但是快取帶來了另外一些棘手的問題：一致性和實時性。

乙個很直觀的場景就是，資料庫中的資料狀態已經改變，但是使用者在頁面上看到的仍然是快取的舊值。

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

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

----

什麼樣的資料可以放快取？

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

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

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

什麼時候不應該使用快取？

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

如何解決一致性的問題？

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

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

另外，在故障發生的時候，我們不能束手無策，換句話說，系統內部也要有可以直接觸發的清理快取的」介面「，這個介面可以是乙個特殊的url，或者乙個只有內部才能訪問的控制台等。

關於折衷的問題。。。

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

更加高階的快取。。。

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