緩存可以是本地緩存，也可以是分布式緩存；可以自己寫個簡單的程序，也可以搞個復雜的獨立系統作為緩存；可以使用各種復雜的算法，也可以只使用簡單的全量緩存；可以使用各種失效機制，也可以只支持人工刷新。緩存重點在於技術，但緩存的難點在於分析哪些數據可以緩存，以什么樣的策略緩存。有些數據一看就是可以緩存的，比如參數數據；但如果給參數加個限制條件，比如雖然參數修改很少，但一旦修改就需要在系統調用時實時生效，那這種情況下是否還可以緩存？下面試着選擇一些常用的場景來分析是否可以使用緩存。
1、系統參數數據，修改頻率非常低，一般由開發人員修改
系統參數是由開發人員修改的參數，開發人員每次修改后，可通過人工刷新緩存參數即可，只需要提供一個手工刷新的頁面，讓開發人員在更改了系統參數后手工刷新即可。
2、業務參數數據，很少修改，修改后一定時限內生效（比如一小時后生效，或隔日生效等）
這種場景下，除非系統無性能要求，一般都會對參數數據進行緩存。參數數據因為有個特點就是數據量較小，故一般就是全量緩存，一次刷新，無需設置失效時間。緩存的刷新機制也相對比較簡單，一般可以通過寫一個定時刷新程序每一小時或每天全量刷新一次緩存。或者也可以通過設置失效時間，直接在刷新緩存數據時設置緩存數據的失效時間是一個小時以后或當天23點59分59秒，這樣當一小時后或第二天查詢參數時發現已經失效就自動刷新一次。
3、業務參數數據，很少修改，修改后必須立即生效
這種場景下，如果沒有性能瓶頸，那就不做緩存了，系統設計越簡單越好。但如果確實存在性能瓶頸，那就必須做緩存了。這種情況乍一看沒法緩存，但我們分析一下，業務參數是會修改且立即生效，但修改的是很少的參數，絕大部分參數還是不會被修改的，在很長時間內是不變的，是可以緩存的。在這種情況下，失效時間和定時刷新機制已經不適合了，需要引入新的實時刷新機制，可以考慮消息機制來通知緩存的刷新。當業務參數改變后，發送消息通知緩存系統或緩存功能立即刷新緩存，這樣做當然是侵入了業務代碼，但為了提升性能也只能這樣了。
4、多個傳入參數計算后的結果數據
這些數據一般由多個傳入參數經過較為復雜的業務邏輯計算后得到結果，這些結果數據是后續業務的傳入參數，比如策略計算結果。這種情景中，如果存在性能問題，則需要對計算結果進行緩存，可以將傳入參數組合的hash值或MD5值作為key緩存計算結果，這樣當下次同樣的傳入參數組合就只需要從緩存中獲取計算結果即可，這樣的緩存一般情況下量會比較大，可以考慮使用分布式緩存系統或者使用在本地使用替換算法來控制緩存的數量。這種緩存數據在計算邏輯不變更的情況下是不需要更新的，只有當計算邏輯變更的情況下，需要刷新緩存，如果全量比較大，可以考慮給這類數據按照計算邏輯編制成組，在計算邏輯變更后刷新此計算邏輯影響到的組的緩存數據即可。還有一種辦法就是預熱，一般業務計算邏輯變更就需要上線，會有足夠的時間預熱緩存。
5、部分業務數據的緩存
業務數據要緩存，這個看起來是不可能的。但有時候系統性能硬逼着必須使用緩存，比如並發性非常的高，數據庫訪問性能已經無法跟上，否則會導致數據庫的崩潰。這種情況下，必須對業務數據進行分析，可能對所有的業務數據緩存不太可能，但是否可以緩存部分，這需要細致的分析。比如業務進度查詢這個功能，我們來分析一下，進度查詢功能對客戶來講，一般是查詢最近一段時間內的進件的進度，這種查詢量可能占到了查詢量的絕大部分，那么我們可以將最近這段時間的進度信息緩存起來，以提升查詢的性能。但最近時間的進件，其進度信息也是修改頻率最高的，那么如何在這種矛盾下提升這些數據的查詢性能？這就是難點所在。業務和數據分析以及對數據分類處理是解決這種矛盾的一個有用手段，通過業務和數據的分析，肯定能找到這個平衡點。