分布式鎖

多個(gè)系統(tǒng)同時(shí)操作一個(gè)redis，因?yàn)閖vm鎖是線程級別的，所以沒有辦法鎖住多個(gè)系統(tǒng)。

Redis鎖實(shí)現(xiàn)：

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

SETNX 和 EXPIRE 非原子性

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

鎖誤解除

本質(zhì)上就是redis自動刪除鎖和主動刪除鎖的重復(fù)沖突

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

在 value 中設(shè)置一個(gè) UUID 標(biāo)識當(dāng)前線程

每次解鎖前判斷一下鎖的value是否為當(dāng)前線程的UUID

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

超時(shí)解鎖導(dǎo)致并發(fā)

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

解決方案：

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

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

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

鎖等待

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

整理來源

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

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

RedLock

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

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

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

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

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

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

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

更新緩存 VS 刪除緩存

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。