redis的分布式鎖是樂觀鎖嗎

簡單來說,redis使用樂觀鎖,相對于悲觀鎖,在實現(xiàn)中更加簡單,在某些場景中的性能也更好。redis作為一個輕量級的、快速的緩存引擎,而不是一個全功能的關系型數(shù)據(jù)庫,既沒有使用悲觀鎖的必要,也難以承受使用悲觀鎖的成本。

redis的分布式鎖是樂觀鎖嗎

樂觀鎖(Optimistic Lock),顧名思義,就是很樂觀,每次去拿數(shù)據(jù)的時候都認為別人不會修改,所以不會上鎖,但是在更新的時候回判斷一下再次期間別人有沒有去更新這個數(shù)據(jù),可以使用版本號等機制。樂觀鎖適用于多讀的應用類型,這樣可以提高吞吐量。

樂觀鎖策略:提交版本必須大于記錄當前版本才能執(zhí)行更新(推薦學習:Redis視頻教程

Redis對于事務只提供了非常有限的支持,其實更多地是試圖繞過問題。

首先,Redis對于同一事務中的一組操作,而不是立即執(zhí)行,而是放入一個queue中,當執(zhí)行到EXEC時,再一起執(zhí)行。事務執(zhí)行是全局獨占的,也就是同一時間只有一個事務被執(zhí)行,中途不能被其它事務打斷。Redis用這種最簡單的、也是性能最差的方式避免了race condition。

其次,在Redis的事務中,如果有一個或多個操作失敗,其它操作仍然會成功,也就是說它根本沒有回滾機制。

這種方式會帶來很多嚴重的問題,其中之一是,無法先讀取某個數(shù)值后再進行依賴這個值的操作,因為放在一個事務里會被在同一個瞬間執(zhí)行,不放在同一個事務里又會導致race condition。解決方法是使用WATCH,它會監(jiān)視一個或多個變量,如果變量的值在調(diào)用WATCH以后和事務提交之前被別的事務修改過了,整個事務都會失敗。這類似于操作系統(tǒng)中的CAS(Compare and Set)。我不知道WATCH具體是怎么實現(xiàn)的,但是我推測它監(jiān)控了指定變量的版本號。

即使有了WATCH,Redis的事務也是受到嚴重限制的。第一,它沒有實現(xiàn)讀數(shù)據(jù)時的一致性,因為WATCH對于讀操作不起作用。第二,它不支持回滾。第三,在對同一變量存在大量并發(fā)寫操作時,性能會非常差,因為每次提交事務時,WATCH監(jiān)控的變量都已經(jīng)被修改了,導致事務將多次提交失敗。但是,Redis本來就是一個KV類型的緩存引擎,要處理的是大量讀少量寫的場景,對一致性也沒有要求。

更多Redis相關技術文章,請訪問Redis視頻教程欄目進行學習!

? 版權聲明
THE END
喜歡就支持一下吧
點贊8 分享