樂觀鎖（又名樂觀並發控制，Optimistic Concurrency Control，縮寫“OCC”），是一種並發控制的方法。它假設多用戶並發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分數據。在提交數據更新之前，每個事務會先檢查在該事務讀取數據後，有沒有其他事務又修改了該數據。

與樂觀所相對的，就是悲觀鎖（又名悲觀並發控制，Pessimistic Concurrency Control，縮寫“PCC”），它可以阻止一個事務以影響其他用戶的方式來修改數據。如果一個事務執行的操作都某行數據應用了鎖，那只有當這個事務把鎖釋放，其他事務才能夠執行與該鎖沖突的操作。

通俗的說，就是悲觀鎖就是“先取鎖在訪問”，因為悲觀鎖會“悲觀”地認為訪問會產生沖突，因此這種保守的策略雖然在數據處理的安全行上提供了保障，但是在效率方面會讓數據庫產生極大的開銷，而且還有可能出現死鎖的情況。

在Redis中WATCH命令的實現是基於樂觀鎖，即，假設訪問不會產生沖突，但是在提交數據之前會先檢查該事務該事物讀取數據後，其他事務是否修改數據，如果其他事務修改了數據，像MySQL提供了回滾操作，而Redis不支持回滾，因為antirez認為這與Redis簡單高效的設計主旨不相符，並且Redis事務執行時錯誤在開發環境時是可以避免的。

樂觀鎖控制的事務一般包括三個階段：

• 讀取：當執行完MULTI
  命令後，客戶端進入事務模式，客戶端接下來輸入的命令會讀入到事務隊列中，入隊過程中出錯會設置CLIENT_DIRTY_EXEC標識。
• 校驗：如果數據庫有鍵被修改，那麽會檢測被修改的鍵是否是被WATCH命令監視的命令，如果是則會設置對應的標識（CLIENT_DIRTY_CAS），並且在命令執行前會檢測這兩個標識，如果檢測到該標識，則會取消事務的執行。
• 寫入：如果沒有設置以上兩種標識，那麽會執行事務的命令，而Redis是單進程模型，因此可以避免執行事務命令時其他請求可能修改數據庫鍵的可能。

Redis的樂觀鎖不是通常實現樂觀鎖的一般方法：檢測版本號，而是在執行完一個寫命令後，會進行檢查，檢查是否是被WATCH

redis樂觀鎖