緩存架構的理論分析

問題背景

略談服務端緩存設計 一文說到緩存不是必須的，由於數據庫自己就利用了內存。但實際狀況是緩存是大型網站的標配。

雖然經驗顯示RDBMS最快時只需0~1ms就能響應，不遜於專門的緩存，可是當壓力增大時，性能的降低也是飛快的。隨着業務的逐漸複雜、開發團隊的逐漸擴大，難以全面優化全部的SQL，數據庫內存的命中率不免降低。

數據庫的鏈接數是有限的、磁盤的併發能力也不好，所以當訪問量增大或數據庫內存命中率降低，平均響應速度會陡然降低；更糟的是，某些查詢致使大量的冷數據換入並佔用數據庫內存(例如全表掃描)，真正最須要的熱數據暫時被擋在內存外，等到1~100ms(或更久)以後才能從新被讀入數據庫內存，到這種時候，壓力可能爆棚了。

• MySQL的buffer pool hit rate指標統計了命中率。
• MySQL有相似於分代LRU的機制，按這個連接調優能有所緩解。

以上分析告訴咱們：緩存架構要知足冷熱分離的特徵——RDBMS不知足，由於冷數據可能擠走熱數據。

另外，衆所周知，緩存架構還要知足讀寫分離的特徵——RDBMS也不知足，由於寫操做會爭搶讀操做的資源。

鑑於這些侷限性，RDBMS終歸仍是頂不住，緩存成爲大型網站的標配就是瓜熟蒂落的了。

方案選擇

略談服務端緩存設計 一文還比較了本地緩存和分佈式緩存，首推分佈式緩存。那麼就要選擇一款緩存系統。並且強烈建議預先考慮水平擴展，若是先用了單機方案，以後很難不關機就在線遷移到基於sharding的集羣方案。

緩存系統的選擇，我隨手列一些典型方案(沒有每一個都用過)，分紅三系：
Memcached系：Twemproxy(手動rebalance)，Couchbase
Redis系：Twemproxy(手動rebalance)，Codis，官方的Redis Cluster
Java系：Apache Ignite(支持多種語言，兼容Memcached API)，基礎性能低於前兩系，但支持SQL查詢、事務和豐富的數據結構，還能遠程執行代碼、推送事件通知、對接本地緩存/數據庫/HDFS等。同類產品有Hazelcast、Gemfire。

應用代碼怎麼寫？一般是：讀操做先get緩存，若沒有，查數據庫，而且set緩存；寫操做直達數據庫，而且delete緩存。這種風格稱爲直寫式緩存。

• 爲避免重複代碼，能夠利用AOP：Java可用Spring Cache，另外Hibernate可自動管理緩存；支持高階函數的語言自帶AOP，把數據操做變成閉包，外層包一個處理緩存的函數。

還有一種風格稱爲寫回式緩存，讀寫操做都走緩存，由緩存來負責與數據庫同步。這種風格須要緩存系統的支持。

結語

以上對問題背景和方案選擇都作了分析，尤爲觸及一些知識盲點，然而這只是理論。
是的！鑑於實際環境的複雜性(即便是本篇文章也沒法反映真實狀況)，最推薦的作法仍然是實測！根據真實的應用場景來設計你的緩存架構！(並非只能線上實測，能夠在測試環境儘可能模擬。)

最後再推薦一些相關文章：

Pinterest談實戰經驗：如何在兩年內實現零到數百億的月訪問 http://www.qingjingjie.com/bl...

微博「異地多活」部署經驗談 http://www.infoq.com/cn/artic...

The Log: What every software engineer should know about real-time data's unifying abstraction https://engineering.linkedin....