分布式鎖

多個系統(tǒng)同時操作一個redis，因為jvm鎖是線程級別的，所以沒有辦法鎖住多個系統(tǒng)。

Redis鎖實現(xiàn)：

• setnx key value 只有在key不存在時設置key的值
  • 此時key相當于鎖的唯一標識，若key存在則會返回失敗
• EXPIRE key timeout 設置帶過期時間的key，動態(tài)設置
  • 保證即使鎖沒有被顯式釋放，鎖也可以在一定時間后自動釋放，避免資源被永遠鎖住(萬一拿到鎖之后掛了就不會被顯式釋放)。

SETNX 和 EXPIRE 非原子性

• 如果 SETNX 成功，在設置鎖超時時間后，服務器掛掉、重啟或網絡問題等，導致 EXPIRE 命令沒有執(zhí)行，鎖沒有設置超時時間變成死鎖。
• 使用 lua 腳本保證原子性

鎖誤解除

本質上就是redis自動刪除鎖和主動刪除鎖的重復沖突

如果線程 A 成功獲取到了鎖，并且設置了過期時間 30 秒，但線程 A 執(zhí)行時間超過了 30 秒，鎖過期自動釋放，此時線程 B 獲取到了鎖；隨后 A 執(zhí)行完成，線程 A 使用 DEL 命令來釋放鎖，但此時線程 B 加的鎖還沒有執(zhí)行完成，線程 A 實際釋放的線程 B 加的鎖。

在 value 中設置一個 UUID 標識當前線程

每次解鎖前判斷一下鎖的value是否為當前線程的UUID

獲取鎖的value和刪除鎖通過Lua腳本變成原子操作

超時解鎖導致并發(fā)

如果線程 A 成功獲取鎖并設置過期時間 30 秒，但線程 A 執(zhí)行時間超過了 30 秒，鎖過期自動釋放，此時線程 B 獲取到了鎖，線程 A 和線程 B 并發(fā)執(zhí)行。

解決方案：

將過期時間設置足夠長，確保代碼邏輯在鎖釋放之前能夠執(zhí)行完成。

為獲取鎖的線程增加守護線程，為將要過期但未釋放的鎖增加有效時間

• 保證鎖不會自動過期自動刪除，就算程序掛了，依然是有過期時間不會造成死鎖。
• 這個線程必須是主線程的守護線程，如果主線程掛了，定時任務也會掛了

鎖等待

• 可以通過客戶端輪詢的方式解決該問題，當未獲取到鎖時，等待一段時間重新獲取鎖，直到成功獲取鎖或等待超時。這種方式比較消耗服務器資源，當并發(fā)量比較大時，會影響服務器的效率。
• 另一種方式是使用 Redis 的發(fā)布訂閱功能，當獲取鎖失敗時，訂閱鎖釋放消息，獲取鎖成功后釋放時，發(fā)送鎖釋放消息。

整理來源

分布式鎖的實現(xiàn)之 redis 篇

《吊打面試官》系列-Redis終章_凜冬將至 FPX_新王登基

RedLock

基于 Redis 的分布式鎖到底安全嗎？ 待整理

Redis與Mysql雙寫一致性方案解析

根據(jù)緩存是刪除還是更新，以及操作順序大概是可以分為下面四種情況

先更新數(shù)據(jù)庫，再更新緩存

先更新緩存，再更新數(shù)據(jù)庫

先刪除緩存，再更新數(shù)據(jù)庫

先更新數(shù)據(jù)庫，再刪除緩存

更新緩存 VS 刪除緩存

• 更新緩存的優(yōu)點: 緩存不會增加一次Miss，命中率高
• 刪除緩存的優(yōu)點: 操作簡單，能防止更新出現(xiàn)的線程安全問題

通常場景下刪除緩存操作簡單，并且?guī)淼母弊饔弥皇窃黾恿艘淮蜟ache Miss，建議作為通用的處理方式，因為：

• 更新緩存的代價可能很高，因為可能摻雜復雜的數(shù)據(jù)計算，而且頻繁的更新緩存并不代表它會被頻繁的訪問到。舉個栗子：一個緩存涉及的表的字段，在 1 分鐘內就修改了 20 次，或者是 100 次，那么緩存更新 20 次、100 次；但是這個緩存在 1 分鐘內只被讀取了 1 次，有大量的冷數(shù)據(jù)。
• 刪除緩存，而不是更新緩存，就是一個 Lazy 計算的思想，不要每次都重新做復雜的計算，不管它會不會用到，而是讓它到需要被使用的時候再重新計算。

Redis與數(shù)據(jù)庫一致性 | 筆記 詳情

總結

以上是生活随笔為你收集整理的redis订阅执行一段时间自动停止_面试系列 redis 分布式锁amp;数据一致性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。