以下只是個人工作中的一點總結,如有問題歡迎指正。1.delete操作時,先刪資料庫還是先刪快取?
一般情況下應該先刪除資料庫。原因: 如果先刪快取,在刪完快取之後刪資料庫之前,另乙個讀請求可能將資料庫裡的資料讀出並寫到快取,造成快取和資料庫不一致(資料庫裡的被刪除了,快取裡還有乙份)。如果沒有超時設定,資料庫中被刪除的資料在快取中一直存在。
a先刪除資料,緊接著b獲取該條資料,可能發生的執行順序
a刪除快取;如果按照以上的順序,是不會有問題的。但是如果是下面這種順序,就會出問題a刪除資料庫;
b讀資料庫(返回null);
b寫快取(寫的也是空資料,防止快取穿透);
a刪除快取;當然,以上討論的是刪快取和刪資料庫這兩步操作都能成功的前提下。下面簡單考慮刪除操作可能失敗的情況:b讀資料庫;
b寫快取;
a刪除資料庫;
如果先刪資料庫成功後,刪快取失敗了,會造成資料庫和快取資料不一致(如果快取設定有超時時間,會達到最終一致)。
如果是採用先刪快取的方案,快取刪除成功,但是資料庫刪除失敗,讀請求會將資料庫的資料重新寫快取,不會有資料不一致的情況。
2.update操作時,應該刪除快取還是更新快取?應該先運算元據庫還是先操作快取?
先給結論: 應該先運算元據庫,然後刪除快取。
歸納一下,一共有四種可能的方案:
(1)、先刪除快取,然後更新資料庫
快取刪除後,更新資料庫前,資料庫的舊資料可能會被其他請求寫到快取。
(2)、先更新資料庫,然後更新快取
假如a進行更新操作,b緊接著對同一資料進行更新,最終結果應該以後一次操作為準。然而可能發生的操作順序是
a更新資料庫;這時資料庫和快取出現不一致,快取的是a更新的資料(髒資料),資料庫中是b更新的資料。b更新資料庫;
b更新快取;
a更新快取;
(3)、先更新快取,然後更新資料庫
如果快取更新成功,資料庫更新失敗,會造成資料不一致。可能想到的解決方法之一就是在資料庫更新失敗時,刪掉更新的快取,然而依然無法避免資料庫還未更新,更新的快取就被其他請求讀取的問題,因此不考慮該方案。
(4)、先更新資料庫,然後刪除快取
相對來說比較合適的方案。
綜合以上,刪除和更新時,應該首先運算元據庫,然後操作快取。當然如果併發請求不大的情況下,操作順序的不同一般是不會出現問題的(併發量低還用快取幹啥呢=。=
3. create操作時,應該操作快取嗎
為了防止快取穿透,在讀資料庫裡不存在的資料時,也需要寫快取。比如讀取id為10的使用者資訊,但是目前沒有該使用者,那麼快取裡存乙份key為10,value為空的資料。但是create操作後,id為10的資料可能就有了,為了保證資料一致性,在create操作成功後,刪除(或更新)對應key的快取。
快取使用總結
localcache memcache redis 區別對比 快取型別 使用場景 使用示例 優點缺點 localcache 少量資料,對應用程式唯讀或讀多寫少 後台配置,分割槽資訊 無需網路開銷,訪問速度最快 集群機器資料不同步 memcache 海量資料,高併發讀寫 記憶體占用相對redis少,適...
快取使用總結
作為乙個查詢系統,效率和穩定性是系統設計的重中之重,提公升效率最有效的方法無疑是快取。快取方式選取 1 本地快取 guva cache,map 2 分布式快取 tair 分布式環境下,採用分布式快取很好的解決了資料一致性問題,所有業務系統共享tair集群。但是增加了一次遠端tr呼叫。穩定性和效率相對...
使用redis快取的實踐總結
使用場景一 高頻率使用但不頻繁更新的業務資料。由於不頻繁更新,所以可以在系統啟動時,從資料庫中載入,放入redis。如果更新,需重啟服務,當然這比較笨。更好的做法下面會列出。使用場景二 高頻率使用更新還算頻繁的業務資料。由於有一定頻率的更新,所以可以在使用者訪問時,查詢快取,如果沒有值,則從資料庫中...