架構之緩存設計

緩存能夠是本地緩存，也能夠是分佈式緩存；能夠本身寫個簡單的程序，也能夠搞個複雜的獨立系統做爲緩存；可使用各類複雜的算法，也能夠只使用簡單的全量緩存；可使用各類失效機制，也能夠只支持人工刷新。緩存重點在於技術，但緩存的難點在於分析哪些數據能夠緩存，以什麼樣的策略緩存。有些數據一看就是能夠緩存的，好比參數數據；但若是給參數加個限制條件，好比雖然參數修改不多，但一旦修改就須要在系統調用時實時生效，那這種狀況下是否還能夠緩存？下面試着選擇一些經常使用的場景來分析是否可使用緩存。

一、系統參數數據，修改頻率很是低，通常由開發人員修改

系統參數是由開發人員修改的參數，開發人員每次修改後，可經過人工刷新緩存參數便可，只須要提供一個手工刷新的頁面，讓開發人員在更改了系統參數後手工刷新便可。

二、業務參數數據，不多修改，修改後必定時限內生效（好比一小時後生效，或隔日生效等）

這種場景下，除非系統無性能要求，通常都會對參數數據進行緩存。參數數據由於有個特色就是數據量較小，故通常就是全量緩存，一次刷新，無需設置失效時間。緩存的刷新機制也相對比較簡單，通常能夠經過寫一個定時刷新程序每一小時或天天全量刷新一次緩存。或者也能夠經過設置失效時間，直接在刷新緩存數據時設置緩存數據的失效時間是一個小時之後或當天23點59分59秒，這樣當一小時後或次日查詢參數時發現已經失效就自動刷新一次。

三、業務參數數據，不多修改，修改後必須當即生效

這種場景下，若是沒有性能瓶頸，那就不作緩存了，系統設計越簡單越好。但若是確實存在性能瓶頸，那就必須作緩存了。這種狀況乍一看無法緩存，但咱們分析一下，業務參數是會修改且當即生效，但修改的是不多的參數，絕大部分參數仍是不會被修改的，在很長時間內是不變的，是能夠緩存的。在這種狀況下，失效時間和定時刷新機制已經不適合了，須要引入新的實時刷新機制，能夠考慮消息機制來通知緩存的刷新。當業務參數改變後，發送消息通知緩存系統或緩存功能當即刷新緩存，這樣作固然是侵入了業務代碼，但爲了提高性能也只能這樣了。

四、多個傳入參數計算後的結果數據

這些數據通常由多個傳入參數通過較爲複雜的業務邏輯計算後獲得結果，這些結果數據是後續業務的傳入參數，好比策略計算結果。這種情景中，若是存在性能問題，則須要對計算結果進行緩存，能夠將傳入參數組合的hash值或MD5值做爲key緩存計算結果，這樣當下次一樣的傳入參數組合就只須要從緩存中獲取計算結果便可，這樣的緩存通常狀況下量會比較大，能夠考慮使用分佈式緩存系統或者使用在本地使用替換算法來控制緩存的數量。這種緩存數據在計算邏輯不變動的狀況下是不須要更新的，只有當計算邏輯變動的狀況下，須要刷新緩存，若是全量比較大，能夠考慮給這類數據按照計算邏輯編製成組，在計算邏輯變動後刷新此計算邏輯影響到的組的緩存數據便可。還有一種辦法就是預熱，通常業務計算邏輯變動就須要上線，會有足夠的時間預熱緩存。

五、部分業務數據的緩存

業務數據要緩存，這個看起來是不可能的。但有時候系統性能硬逼着必須使用緩存，好比並發性很是的高，數據庫訪問性能已經沒法跟上，不然會致使數據庫的崩潰。這種狀況下，必須對業務數據進行分析，可能對全部的業務數據緩存不太可能，可是否能夠緩存部分，這須要細緻的分析。好比業務進度查詢這個功能，咱們來分析一下，進度查詢功能對客戶來說，通常是查詢最近一段時間內的進件的進度，這種查詢量可能佔到了查詢量的絕大部分，那麼咱們能夠將最近這段時間的進度信息緩存起來，以提高查詢的性能。但最近時間的進件，其進度信息也是修改頻率最高的，那麼如何在這種矛盾下提高這些數據的查詢性能？這就是難點所在。業務和數據分析以及對數據分類處理是解決這種矛盾的一個有用手段，經過業務和數據的分析，確定能找到這個平衡點。

 

點擊連接加入羣【.NET大型網站架構】433685124QQ羣