排它鎖

（簡稱X鎖），又稱為寫鎖或獨佔鎖，是一種基本的鎖型別。如果事務T1對資料物件O1加上了排它鎖，那麼在整個加鎖期間，只允許事務T1對O1進行讀取和更新操作，其它任何事務都幫你再對這個資料物件進行任何型別的操作，——直到T1釋放了排它鎖。

從上邊講解的排它鎖的基本概念中，我們可以看到，排它鎖的核心是如何保證當前有且僅有一個事務獲得鎖，並且鎖被釋放後，所有等待獲取鎖的事務都能被通知到。

共享鎖

（簡稱S鎖），又稱為讀鎖，同樣是一種基本的鎖型別，如果事務T1對資料物件O1加上了共享鎖，那麼當前事務只能對O1進行讀取操作，其它事務也只能對這個資料物件加共享鎖——直到該資料物件上的所有共享鎖都被釋放。

共享鎖和排它鎖最根本的區別在於，加上排它鎖後，資料物件只對一個事務可見，而加上共享鎖後，資料對所有的事務可見。

在zookeeper中，對於共享鎖的使用和在SQL中略有不同。
在需要獲取共享鎖時，所有的客戶端都會到／shared-lock這個節點下邊建立一個臨時資料節點，如果當前請求是讀請求，那麼在命名臨時節點的時候要表明是讀的，如果是寫請求，在建立節點命名時要表明是寫的。
根據共享鎖的定義，不同的事務都可以同時對同一個資料物件進行讀取操作，而更新操作必須在當前沒有任何進行讀寫操作的情況下進行的。基於這個原則，下邊簡述如何通過zookeeper的節點來確定分散式讀寫順序，大致可以分為四步。
1. 建立完節點後，獲取共享鎖下邊的所有子節點，並且對該節點註冊子節點變更的Wacher監聽。
2. 確定自己的節點序號在所有子節點中的順序。
3. 對於讀請求：
如果沒有比自己序號小的子節點，或是所有比自己序號小的子節點都是讀請求，那麼表明自己已經成功的獲取到了共享鎖，同時開始執行讀取邏輯。
如果比自己序號小的子節點中有寫請求，那麼就需要進入等待。
對於寫請求：
如果自己不是序號最小的子節點，那麼就需要進入等待。
4.接收到Wacher通知後，重複步驟1。

但是這種情況會帶來羊群效應（驚群效應）。
改進： 建立完節點後，獲取共享鎖下邊的所有子節點，不在對該節點註冊子節點變更的Wacher監聽。
對於讀請求：向比自己序號小的最後一個寫請求節點註冊wacher監聽。
對於寫請求：向比自己序號小的最後一個節點註冊Wacher監聽。

悲觀鎖

又被稱作悲觀併發控制（PCC），是資料庫中一種非常典型且非常嚴格的併發控制策略，悲觀鎖有強烈的獨佔和排它性，能夠有效的避免不同事務對同一資料併發更新而造成的資料一致性問題。在悲觀鎖的實現原理中，如果一個事務（假定是事務A）正在對資料進行處理，那麼在整個資料處理過程中，都會將資料處於鎖定狀態。在這期間，其他事務無法對這個資料進行更新操作，直到事務A完成對該資料的處理，釋放了對應的鎖之後，其他事務才能夠重新競爭來對資料進行更新操作。

樂觀鎖

又被稱作樂觀併發控制（OCC），也是一中常見的樂觀併發控制策略。相對於悲觀鎖而言，樂觀鎖的機制顯得更加友好與寬鬆。從上邊的介紹可以看到，悲觀鎖假定不同的事務之間的處理一定會出現相互干擾，從而需要在一個事務從頭到尾的過程中對資料進行加鎖處理。而樂觀鎖正好相反，它假定多個事務在處理的過程中不會彼此影響，因此在事務處理的絕大部分時間裡不需要進行加鎖處理。當然，既然有併發，就一定存在資料更新衝突的可能。在樂觀鎖機制中，在更新請求提交之前，每個事務都會首先檢查當前事務讀取資料後，是否有其他事務對該資料進行了更改。如果其他事務有更新的話，那麼正在提交的事務就會回滾。樂觀鎖適合使用在資料迸發競爭不大、事務衝突較少的應用場景中。

其實，我們可以把一個樂觀鎖控制的事務分成三個階段：資料讀取、寫入校驗和資料寫入。其中寫入校驗是整個樂觀鎖控制的關鍵所在。在寫入校驗階段（根據版本號去判斷），事務會首先檢查資料在讀取階段後是否有其他事務對資料進行了更新，以保證資料更新的一致性。

樂觀鎖不是資料庫自帶的，需要我們自己去實現。樂觀鎖是指操作資料庫時(更新操作)，想法很樂觀，認為這次的操作不會導致衝突，在操作資料時，並不進行任何其他的特殊處理（也就是不加鎖），而在進行讀取後，再去判斷是否有衝突。

共享鎖和排它鎖是悲觀鎖的不同的實現，它倆都屬於悲觀鎖的範疇。