簡單來說，Redis使用樂觀鎖，相對於悲觀鎖，在實作中更加簡單，在某些場景中的效能也更好。 Redis作為一個輕量級的、快速的快取引擎，而不是一個全功能的關係型資料庫，既沒有使用悲觀鎖的必要，也難以承受使用悲觀鎖的成本。
樂觀鎖（Optimistic Lock），顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候回判斷一下再次期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀取的應用類型，這樣可以提高吞吐量。
樂觀鎖定策略：提交版本必須大於記錄當前版本才能執行更新（建議學習：Redis視訊教學）
Redis對於交易只提供了非常有限的支持，其實更多是試圖繞過問題。
首先，Redis對於同一事務中的一組操作，而不是立即執行，而是放入一個queue中，當執行到EXEC時，再一起執行。事務執行是全域獨佔的，也就是同一時間只有一個事務被執行，中途不能被其它事務打斷。 Redis用這種最簡單的、也是性能最差的方式避免了race condition。
其次，在Redis的事務中，如果有一個或多個操作失敗，其它操作仍然會成功，也就是說它根本沒有回滾機制。
這種方式會帶來很多嚴重的問題，其中之一是，無法先讀取某個數值後再進行依賴這個值的操作，因為放在一個事務裡會被在同一個瞬間執行，不放在同一個事務裡又會導致race condition。解決方法是使用WATCH，它會監視一個或多個變量，如果變數的值在呼叫WATCH以後和交易提交之前被別的交易修改過了，整個交易都會失敗。這類似於作業系統中的CAS（Compare and Set）。我不知道WATCH具體是怎麼實現的，但是我推測它監控了指定變數的版本號。
即使有了WATCH，Redis的事務也是受到嚴重限制的。第一，它沒有實現讀取資料時的一致性，因為WATCH對於讀取操作不起作用。第二，它不支援回滾。第三，在對相同變數存在大量並發寫入操作時，效能會非常差，因為每次提交交易時，WATCH監控的變數都已經被修改了，導致交易將多次提交失敗。但是，Redis本來就是一個KV類型的快取引擎，要處理的是大量讀取少量寫的場景，對一致性也沒有要求。
更多Redis相關技術文章，請造訪Redis資料庫使用入門教學欄位學習！
以上是redis的分散式鎖是樂觀鎖嗎的詳細內容。更多資訊請關注PHP中文網其他相關文章！
