作為乙個查詢系統，效率和穩定性是系統設計的重中之重，提公升效率最有效的方法無疑是快取。
快取方式選取：
1：本地快取 （guva cache, map ）
2：分布式快取（tair）
分布式環境下，採用分布式快取很好的解決了資料一致性問題，所有業務系統共享tair集群。但是增加了一次遠端tr呼叫。穩定性和效率相對於本地快取來說會低一些。
而本地快取雖然可以減少一次tr呼叫,但是各伺服器擁有自己的快取資料，不是共享的，資料一致性的問題很難解決。
快取的服務方式：
1：近端快取 業務系統-> 遠端tair
2：遠端快取 業務系統->查詢系統->tair
近端遠端
近端快取相對於遠端快取可以減少一次遠端的tr呼叫，但是資料一致性的保證相對於遠端快取來說會有一定的困難。
據上來看快取最重要的問題是如何做到快取資料與db資料的一致性：
快取資料一致性解決方案：
（1）可以採用在本伺服器啟動定時任務，定時重新整理來保證資料的一致性。
定時任務實現:
（2）可以在快取資料中新增時間戳，每次讀取資料之後根據時間判斷是否有效然後進行重新整理。
（3）當db資料發生變化時，可以通過drm方式讓快取及時重新整理，保證資料的一致性。
快取使用總結
localcache memcache redis 區別對比 快取型別 使用場景 使用示例 優點缺點 localcache 少量資料，對應用程式唯讀或讀多寫少 後台配置，分割槽資訊 無需網路開銷，訪問速度最快 集群機器資料不同步 memcache 海量資料，高併發讀寫 記憶體占用相對redis少，適...
快取使用總結
以下只是個人工作中的一點總結，如有問題歡迎指正。1.delete操作時，先刪資料庫還是先刪快取?一般情況下應該先刪除資料庫。原因 如果先刪快取，在刪完快取之後刪資料庫之前，另乙個讀請求可能將資料庫裡的資料讀出並寫到快取，造成快取和資料庫不一致 資料庫裡的被刪除了，快取裡還有乙份 如果沒有超時設定，資...
使用redis快取的實踐總結
使用場景一 高頻率使用但不頻繁更新的業務資料。由於不頻繁更新，所以可以在系統啟動時，從資料庫中載入，放入redis。如果更新，需重啟服務，當然這比較笨。更好的做法下面會列出。使用場景二 高頻率使用更新還算頻繁的業務資料。由於有一定頻率的更新，所以可以在使用者訪問時，查詢快取，如果沒有值，則從資料庫中...