localcache
memcache
redis
區別對比
快取型別
使用場景
使用示例
優點缺點
localcache
少量資料，對應用程式唯讀或讀多寫少
後台配置，分割槽資訊
無需網路開銷，訪問速度最快
集群機器資料不同步
memcache
海量資料，高併發讀寫
記憶體占用相對redis少，適合大鍵儲存
資料結構單一,不支援備份及持久化，只支援客戶端操作
redis
海量資料，高併發讀寫
資料結構豐富，支援備份及持久化，支援伺服器操作
相對memcache記憶體效率低
先淘汰快取在更新資料庫。對於這種做法，如果淘汰了快取，此時剛好來了乙個請求，由於快取已經被淘汰，新來的請求將從資料庫讀取資訊重新load到快取，如果先前的寫操作還沒完成，讀操作讀到的將是舊的資料，此時重新load到快取的資料將是髒資料並且後續的請求將都讀到髒資料。
先更新資料庫在淘汰快取。更新db的時候剛好有請求到達，此時請求讀到的將是髒資料。db更新後將淘汰舊的快取，後續的請求讀到的將是新的資料。
先更新(淘汰)cache，後續db操作失敗。如果是更新快取，db操作失敗將導致快取中的資料是髒資料。如果是淘汰快取，db更新失敗會導致一次cache miss。
先更新了db，後續cache操作失敗，此時將會導致cache中的資料是髒資料。
在考慮了更新失敗的情況下，分布式服務中並沒有完美的解決方案，方法需要自己根據業務進行權衡,除非你願意犧牲效能使用事務強一致性
use hashes when possible
sortset
setredis底層**
快取使用總結
以下只是個人工作中的一點總結，如有問題歡迎指正。1.delete操作時，先刪資料庫還是先刪快取?一般情況下應該先刪除資料庫。原因 如果先刪快取，在刪完快取之後刪資料庫之前，另乙個讀請求可能將資料庫裡的資料讀出並寫到快取，造成快取和資料庫不一致 資料庫裡的被刪除了，快取裡還有乙份 如果沒有超時設定，資...
快取使用總結
作為乙個查詢系統，效率和穩定性是系統設計的重中之重，提公升效率最有效的方法無疑是快取。快取方式選取 1 本地快取 guva cache,map 2 分布式快取 tair 分布式環境下，採用分布式快取很好的解決了資料一致性問題，所有業務系統共享tair集群。但是增加了一次遠端tr呼叫。穩定性和效率相對...
使用redis快取的實踐總結
使用場景一 高頻率使用但不頻繁更新的業務資料。由於不頻繁更新，所以可以在系統啟動時，從資料庫中載入，放入redis。如果更新，需重啟服務，當然這比較笨。更好的做法下面會列出。使用場景二 高頻率使用更新還算頻繁的業務資料。由於有一定頻率的更新，所以可以在使用者訪問時，查詢快取，如果沒有值，則從資料庫中...