web項目實際應用中分布式鎖有什么用

這篇文章給大家分享的是有關web項目實際應用中分布式鎖有什么用的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

一、 表鎖

from update;

4、 排他鎖

        排他鎖又稱為寫鎖，和共享鎖的區別在于，其他線程既不能讀也不能修改。 

7、樂觀鎖

        樂觀鎖其實不會上鎖。顧名思義，很樂觀，它默認別的線程不會修改數據，所以不會上鎖。只是在更新前去判斷別的線程在此期間有沒有修改數據，如果修改了，會交給業務層去處理。

         目前幾乎很多大型網站及應用都是分布式部署的，分布式場景中的數據一致性問題一直是一個比較重要的話題。分布式的CAP理論告訴我們“任何一個分布式系統都無法同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance），最多只能同時滿足兩項。”所以，很多系統在設計之初就要對這三者做出取舍。在互聯網領域的絕大多數的場景中，都需要犧牲強一致性來換取系統的高可用性，系統往往只需要保證“最終一致性”，只要這個最終時間是在用戶可以接受的范圍內即可。

        在很多場景中，我們為了保證數據的最終一致性，需要很多的技術方案來支持，比如分布式事務、分布式鎖等。有的時候，我們需要保證一個方法在同一時間內只能被同一個線程執行。在單機環境中，Java中其實提供了很多并發處理相關的API，但是這些API在分布式場景中就無能為力了。也就是說單純的Java Api并不能提供分布式鎖的能力。所以針對分布式鎖的實現目前有多種方案：

                    基于數據庫實現分布式鎖

基于緩存（redis，memcached）實現分布式鎖

基于Zookeeper實現分布式鎖

在分析這幾種實現方案之前我們先來想一下，我們需要的分布式鎖應該是怎么樣的？（這里以方法鎖為例，資源鎖同理）

可以保證在分布式部署的應用集群中，同一個方法在同一時間只能被一臺機器上的一個線程執行。

這把鎖要是一把可重入鎖（避免死鎖）

這把鎖最好是一把阻塞鎖（根據業務需求考慮要不要這條）

有高可用的獲取鎖和釋放鎖功能

獲取鎖和釋放鎖的性能要好

  如下主要是針對悲觀鎖來介紹。

二、來實現boolean lock(){

            update;

null){

true;

catch(Exception e){

       sleep(1000);

return    緩存鎖

        相比較于基于數據庫實現分布式鎖的方案來說，基于緩存來實現在性能方面會表現的更好一點。而且很多緩存是可以集群部署的，可以解決單點問題。

   redis2.6之后，SET命令支持超時和key存在檢查，這是一個原子操作

獲取鎖并設置超時時間:

SET key value [EX seconds] [PX milliseconds] [NX|XX]

刪除鎖:

DEL key

EX:單位是秒

PX:單位是毫秒

NX:如果key存在，返回nil(失敗)，不存在返回ok

          XX:如果key存在，返回ok，不存在返回nil(失敗)

            緩存鎖優勢是性能出色，劣勢就是由于數據在內存中，一旦緩存服務宕機，鎖數據就丟失了。像redis自帶復制功能，可以對數據可靠性有一定的保證，但是由于復制也是異步完成的，因此依然可能出現master節點寫入鎖數據而未同步到slave節點的時候宕機，鎖數據丟失問題。

四、分布式鎖—zookeeper

        基于zookeeper臨時有序節點可以實現的分布式鎖。大致思想即為：每個客戶端對某個方法加鎖時，在zookeeper上的與該方法對應的指定節點的目錄下，生成一個唯一的瞬時有序節點。 判斷是否獲取鎖的方式很簡單，只需要判斷有序節點中序號最小的一個。 當釋放鎖的時候，只需將這個瞬時節點刪除即可。同時，其可以避免服務宕機導致的鎖無法釋放，而產生的死鎖問題。

來看下Zookeeper能不能解決前面提到的問題。

        鎖無法釋放:使用Zookeeper可以有效的解決鎖無法釋放的問題，因為在創建鎖的時候，客戶端會在ZK中創建一個臨時節點，一旦客戶端獲取到鎖之后突然掛掉（Session連接斷開），那么這個臨時節點就會自動刪除掉。其他客戶端就可以再次獲得鎖。

非阻塞鎖:使用Zookeeper可以實現阻塞的鎖，客戶端可以通過在ZK中創建順序節點，并且在節點上綁定監聽器，一旦節點有變化，Zookeeper會通知客戶端，客戶

端可以檢查自己創建的節點是不是當前所有節點中序號最小的，如果是，那么自己就獲取到鎖，便可以執行業務邏輯了。

不可重入:使用Zookeeper也可以有效的解決不可重入的問題，客戶端在創建節點的時候，把當前客戶端的主機信息和線程信息直接寫入到節點中，下次想要獲取鎖的

時候和當前最小的節點中的數據比對一下就可以了。如果和自己的信息一樣，那么自己直接獲取到鎖，如果不一樣就再創建一個臨時的順序節點，參與排隊。

單點問題:使用Zookeeper可以有效的解決單點問題，ZK是集群部署的，只要集群中有半數以上的機器存活，就可以對外提供服務。

感謝各位的閱讀！關于“web項目實際應用中分布式鎖有什么用”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！