一、快取的成本和收益是什麼：
既然要討論是否真的需要快取這個問題，就要知道快取帶來的成本與收益（好處、壞處）是什麼？
收益成本
快取 + 後端儲存(資源)
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鏈的相應時間。
附圖一張：
快取系列文章 4 快取的粒度控制
一 什麼是快取粒度 下面這個圖是很多專案關於快取使用最常用的乙個抽象，那麼我們假設storage層為mysql,cache層為redis。其實這個問題就是快取粒度問題，我們在快取設計應該佮預估和考慮呢？下面我們將從通用性 空間 維護三個角度進行說明。二 全部資料和部分資料比較 1.兩者的特點是顯而易...
iOS開發是否需要快取UIColor
import 獲取時間點，精確到微秒 double getcurrenttime 向快取中新增顏色 ibaction createacolor uibutton sender 搜尋顏色 ibaction searchcolor uibutton sender double end self getc...
快取系列文章 3 快取常用更新策略對比 一致性
從下面的 看，快取的更新策略大概氛圍三種 本文將從一致性和維護成本兩個方面對於三種快取更新策略進行簡要說明，因為這些東西比較理論和抽象 入 說得不對，歡迎拍磚注 1 一致性 快取和真實資料來源 例如mysql,hbase,elasticsearch等等 是否存在一段時間資料的不一致。2 維護成本 開...