大家好，關于redis分布式鎖怎么實現(xiàn)很多朋友都還不太明白，不過沒關系，因為今天小編就來為大家分享關于基于redis的分布式鎖的知識點，相信應該可以解決大家的一些困惑和問題，如果碰巧可以解決您的問題，還望關注下本站哦，希望對各位有所幫助！

redis與zookeeper分布式鎖區(qū)別

您好，Redis與Zookeeper的分布式鎖的區(qū)別如下：

1.實現(xiàn)方式不同：Redis分布式鎖是基于Redis單機實現(xiàn)的，而Zookeeper分布式鎖是基于Zookeeper集群實現(xiàn)的。

2.鎖的粒度不同：Redis分布式鎖的鎖粒度是基于某個具體的業(yè)務邏輯實現(xiàn)的，而Zookeeper分布式鎖的鎖粒度是基于Zookeeper節(jié)點實現(xiàn)的。

3.鎖的可靠性不同：Redis分布式鎖在單機故障或網(wǎng)絡故障時可能會出現(xiàn)鎖失效的情況，而Zookeeper分布式鎖在Zookeeper集群中有多個節(jié)點存儲鎖信息，所以具有更高的可靠性。

4.性能不同：Redis分布式鎖的性能較高，因為它是基于內存實現(xiàn)的，而Zookeeper分布式鎖的性能相對較低，因為它需要進行網(wǎng)絡通信。

5.應用場景不同：Redis分布式鎖適用于鎖持有時間較短，競爭鎖的客戶端數(shù)量較少的場景，而Zookeeper分布式鎖適用于鎖持有時間較長，競爭鎖的客戶端數(shù)量較多的場景。

Redis分布式鎖的原理是什么如何續(xù)期

分布式鎖的需求產(chǎn)生

分布式鎖的需求是伴隨著應用分布式部署而來的，在單體應用，且只部署一臺服務器的情況下，通過java的同步鎖即可實現(xiàn)。同步鎖，即是一個原子性的操作。

那么當應用進行了分布式部署，應用有多個服務，這個時候應用服務端就沒有一個可提供原子性操作的地方了，Redis性能高，且是單線程，因此可提供一個原子性操作的地方，利用它，就可以實現(xiàn)分布式鎖。

用場景說話，使用Redis分布式鎖的場景如下圖所示：

如下圖所示，隨后會根據(jù)場景說明分布式鎖及續(xù)期相關問題的來龍去脈。

圖中序號1：進來一個請求，這個請求要求我們保存一個“訂單A”；圖中序號2：2.1步，請求進來，首先去嘗試設置一個Redis值，他的鍵就是訂單號“訂單A”，如果嘗試成功，則代表我這個線程是第一次設置，相當于我拿到了這個鎖；如果嘗試失敗，那么，可以拋出異?；蛘叩却欢螘r候后再次重試，這里可以根據(jù)業(yè)務場景的不同采取不同的策略。這里的關鍵是在Redis中的操作是單線程的，因此該操作是原子性的。2.2步，為了防止應用服務意外中斷，Redis中的數(shù)據(jù)一直存活，消耗資源，需要設置一個超時時間。（如果為了嚴謹，可以將2.1,2.2兩步封裝成一個lua腳本部署在Redis服務器上）圖中序號3：情況A，這個時候是當Redis的key還未失效，程序就已經(jīng)執(zhí)行完成，且刪除了Redis中的數(shù)據(jù)，一切正常；情況B：就是需要續(xù)期的場景，如果要避免這個場景的出現(xiàn)，可以將Rediskey的失效時間設置長一點，可以應對大多數(shù)業(yè)務。如果要徹底解決，可以在應用端添加一個Redis鎖的注冊中心，然后起一個監(jiān)聽線程去監(jiān)聽這個注冊中心，發(fā)現(xiàn)有鎖還在被持有，但是Redis已經(jīng)快過期了，則修改相應key的失效時間，進行續(xù)期。

Java語言如何正確實現(xiàn)Redis分布式鎖

和大家分享我的經(jīng)驗，如何用redis提供的一個簡單接口，輕松實現(xiàn)redis分布式鎖。

在開始之前，我先簡單介紹下redis的性能。

高效的Redis

Redis本身是單線程的，這樣帶來的好處是能夠提高讀寫效率。多線程通常來說會有上下文切換帶來的時間損耗，而redis通過綁定單個CPU到某塊內存，實現(xiàn)了上下文切換的最小開銷，因此這種場景反而比多線程還要高效。

不安全的Redis

但是，如果有不同的節(jié)點同時要對Redis中的同一個數(shù)據(jù)進行操作，由于是來自不同Redis服務器，就會發(fā)生線程不安全的情況。

舉例有兩個功能函數(shù)X和Y（也可以看做是兩個服務器節(jié)點），二者功能相同，都要執(zhí)行讀取Redis中變量P，并且對其加一的操作。如果是線程安全的，那么X和Y分別執(zhí)行完之后，P的值應該比原來增加2，但是由于函數(shù)XY互相獨立，那就可能發(fā)生下面這種情況：

1X讀取P

2Y讀取P

3X將P+1寫回Redis

4Y將P+1寫回Redis

執(zhí)行結束后，P的值卻變成了P+1，而不是P+2。

這就是線程不安全導致的結果。

redis的分布式鎖

那么如何用Redis來避免上面的情況呢。

Redis對外開放了一個非常厲害的api，目前經(jīng)常被大家用來做分布式鎖，是絕對的線程安全，這個函數(shù)就是SETkeyfieldvalue加上NX參數(shù)。這個NX參數(shù)可是了不得，通常來說，set函數(shù)是不管field字段是否存在，只要寫入成功就會返回1，但是如果增加了NX參數(shù)，那么如果field值在redis中已經(jīng)存在，就會返回nil，否則才返回1。因此可以通過這個函數(shù)來執(zhí)行加鎖操作，如果返回值不為nil，則加鎖成功，否則代表有其他線程在操作數(shù)據(jù)，當前請求需要等待。

不僅如此，為了避免死鎖，SET還有一個參數(shù)為EX，即EX毫秒后，field會自動清空。

此外，還有PX，XX參數(shù)，具體含義見如下文檔。

以上就是我在工作中總結的防止redis并發(fā)的方式，如果你有其他想法，歡迎在下方評論區(qū)與我溝通。

我是蘇蘇思量，來自BAT的java開發(fā)工程師，每天分享技術見聞，歡迎關注我，與我共同進步。

關于redis分布式鎖怎么實現(xiàn)的內容到此結束，希望對大家有所幫助。