緩存系列文章--2.是否真的需要緩存？轉載請注明出處哈:http://carlosfu.iteye.com/blog/2269678

轉載請注明出處哈: http://carlosfu.iteye.com/blog/2269678

一、緩存的成本和收益是什麼：

  既然要讨論是否真的需要緩存這個問題，就要知道緩存帶來的成本與收益（好處、壞處）是什麼？

收益	成本
緩存 + 後端存儲(資源)	1. 加速讀寫 2. 降低後端負載	1. 資料不一緻性 2. 代碼維護成本 3. 架構複雜度

  上面的表格應該清楚的表達了使用緩存後的收益和成本分别是什麼。下面将進行詳細的解析

二、緩存成本與收益詳解：

  1. 收益是很明顯的，通常來說一個設計還不錯的緩存系統，能夠幫助你的業務實作加速讀寫，同時幫助降低了後端負載。

   (1) 加速讀寫：通常來說加速是明顯的，因為緩存通常都是全記憶體的系統，而後端（可能是mysql、甚至是别人的HTTP, RPC接口）都有速度慢和抗壓能力差的特性，通過緩存的使用可以有效的提高使用者的通路速度同時優化了使用者的體驗。

   (2) 降低後端負載：通過緩存的添加，如果程式沒有什麼問題，在命中率還可以的情況下，可以幫助後端減少通路量和複雜計算(join、或者無法在優化的sql等)，在很大程度降低了後端的負載。

  2. 成本：

   (1) 資料不一緻性：無論你的設計做的多麼好，緩存資料與權威資料源（可以了解成真實或者後端資料源）一定存在着一定時間視窗的資料不一緻性，這個時間視窗的大小可大可小，具體多大還要看一下你的業務允許多大時間視窗的不一緻性。

   (2) 代碼維護成本：加入緩存後，代碼就會在原資料源基礎上加入緩存的相關代碼，例如原來隻是一些sql, 現在要加入k-v緩存，必然增加了代碼的維護成本。

   (3) 架構複雜度：加入緩存後，例如加入了redis-cluster，一般來說緩存不會像Mysql有專門的DBA，很有可能沒有專職的管理人員，是以也增加了架構的複雜度和維護成本。

三、如何選擇？

  如果目前系統的通路速度和通路量能夠滿足現有的要求，就不必增加緩存，其實像mysql并沒有那麼差，一台運作良好的Mysql，扛個QPS=1000沒什麼問題。

  如果要加入選擇了緩存，一定要能給出足夠的理由，不是為了簡單的show技術和想當然，最好的方法就是用資料說話：加速比有多少、後端負載降低了多少。

四、什麼樣的場景需要緩存？

    在公司裡，據我觀察，無論怎麼更新架構，使用各種新技術，但是80%的項目還是離不開SQL的，下面我們以SQL作為後端資料源、以Redis作為緩存層，說一下哪些場景是需要緩存的。

1、複雜開銷大的計算、降低後端負載

    以Mysql為例子，一些複雜的操作或者計算(例如大量聯表操作、一些分組計算)，如果不加

緩存，大量流量将在這些複雜計算的執行。

2. 加速請求響應

    即使單條後端資料足夠快（例如select * from table where id=?），那麼依然可以利用redis/memcache将這些操作進行merge做優化(例如：cache(select * from table where id in(id1,id10....idK)))，進而優化整個IO鍊的相應時間。

附圖一張：