Redis實作分布式鎖與Zookeeper實作分布式鎖差別

**# Redis實作分布式鎖與Zookeeper實作分布式鎖差別

**

**前言:

在學習過程中，簡單的整理了一些redis跟zookeeper實作分布式鎖的差別，有需要改正跟補充的地方，希望各位大佬及時指出

Redis實作分布式鎖思路

基于Redis實作分布式鎖（setnx）setnx也可以存入key，如果存入key成功傳回1，如果存入的key已經存在了，傳回0.

Zookeeper實作分布式鎖思路

基于Zookeeper實作分布式鎖 Zookeeper是一個分布式協調工具，在分布式解決方案中。

多個用戶端（jvm），同時在zookeeper上建立相同的一個臨時節點，因為臨時節點路徑是保證唯一，隻要誰能夠建立節點成功，誰就能夠擷取到鎖，沒有建立成功節點，就會進行等待，當釋放鎖的時候，采用事件通知給用戶端重新擷取鎖的資源。

Redis實作分布式鎖與Zookeeper實作分布式鎖差別

相同點

實作分布式鎖最終是通過什麼方式？

在叢集環境下，保證隻允許有一個jvm進行執行。

不同點

從技術上分析

Redis 是nosql資料，主要特點緩存；

Zookeeper是分布式協調工具，主要用于分布式解決方案。

實作思路

核心通過擷取鎖、釋放鎖、死鎖問題

擷取鎖

Zookeeper

多個用戶端（jvm），會在Zookeeper上建立同一個臨時節點，因為Zookeeper節點命名路徑保證唯一，不允許出現重複，隻要誰能夠先建立成功，誰能夠擷取到鎖。

Redis

多個用戶端（jvm），會在Redis使用setnx指令建立相同的一個key，因為Redis的key保證唯一，不允許出現重複，隻要誰能夠先建立成功，誰能夠擷取到鎖。

釋放鎖

Zookeeper使用直接關閉臨時節點session會話連接配接，因為臨時節點生命周期與session會話綁定在一塊，如果session會話連接配接關閉的話，該臨時節點也會被删除。

這時候用戶端使用事件監聽，如果該臨時節點被删除的話，重新進入盜擷取鎖的步驟。

Redis在釋放鎖的時候，為了確定是鎖的一緻性問題，在删除的redis 的key時候，需要判斷同一個鎖的id，才可以删除。

共同特征：如何解決死鎖現象問題

Zookeeper使用會話有效期方式解決死鎖現象。

Redis 是對key設定有效期解決死鎖現象

性能角度考慮

因為Redis是NoSQL資料庫，相對比來說Redis比Zookeeper性能要好。

可靠性

從可靠性角度分析，Zookeeper可靠性比Redis更好。

因為Redis有效期不是很好控制，可能會産生有效期延遲；

Zookeeper就不一樣，因為Zookeeper臨時節點先天性可控的有效期，是以相對來說Zookeeper比Redis更好

總結下兩者差別

Redis分布式鎖，必須使用者自己間隔時間輪詢去嘗試加鎖，當鎖被釋放後，存在多線程去争搶鎖，并且可能每次間隔時間去嘗試鎖的時候，都不成功，對性能浪費很大。

Zookeeper分布鎖，首先建立加鎖标志檔案，如果需要等待其他鎖，則添加監聽後等待通知或者逾時，當有鎖釋放，無須争搶，按照節點順序，依次通知使用者。