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

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

一、 表鎖

from update;

4、 排他鎖

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

7、樂觀鎖

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

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

        在很多場景中，我們?yōu)榱吮ＷC數(shù)據(jù)的最終一致性，需要很多的技術方案來支持，比如分布式事務、分布式鎖等。有的時候，我們需要保證一個方法在同一時間內(nèi)只能被同一個線程執(zhí)行。在單機環(huán)境中，Java中其實提供了很多并發(fā)處理相關的API，但是這些API在分布式場景中就無能為力了。也就是說單純的Java Api并不能提供分布式鎖的能力。所以針對分布式鎖的實現(xiàn)目前有多種方案：

                    基于數(shù)據(jù)庫實現(xiàn)分布式鎖

基于緩存（redis，memcached）實現(xiàn)分布式鎖

基于Zookeeper實現(xiàn)分布式鎖

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

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

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

這把鎖最好是一把阻塞鎖（根據(jù)業(yè)務需求考慮要不要這條）

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

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

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

二、來實現(xiàn)boolean lock(){

            update;

null){

true;

catch(Exception e){

       sleep(1000);

return    緩存鎖

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

   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(失敗)

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

四、分布式鎖—zookeeper

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

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

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

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

端可以檢查自己創(chuàng)建的節(jié)點是不是當前所有節(jié)點中序號最小的，如果是，那么自己就獲取到鎖，便可以執(zhí)行業(yè)務邏輯了。

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

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

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

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