分布式鎖為什么要選擇Zookeeper而不是Redis？
在分布式的應(yīng)用中，為了防止單點故障，保障高可用，通常會采用主從結(jié)構(gòu)，當主節(jié)點掛掉后，從節(jié)點可以代替主節(jié)點提供服務(wù)。
Redis通過復制 + sentinel哨兵來實現(xiàn)主從模式。
Zookeeper通過replicated mode復制模式來實現(xiàn)主從模式。
單從結(jié)構(gòu)上看，Redis和Zookeeper都是主從架構(gòu)，那Zookeeper的優(yōu)勢是什么？為什么要選擇Zookeeper？難道只是因為Zookeeper是目錄結(jié)構(gòu)，Redis是K-V結(jié)構(gòu)嗎？
同步機制的不同
Redis
Redis在給從節(jié)點同步數(shù)據(jù)時，正常情況是增量同步，也就是主節(jié)點的數(shù)據(jù)修改語句（DML）會異步的同步給從節(jié)點。Redis的數(shù)據(jù)同步?jīng)]有保障數(shù)據(jù)一致性的機制，也就是說，一條DML在主節(jié)點執(zhí)行成功時，不能保障其他從節(jié)點成功執(zhí)行了這條數(shù)據(jù)，這就會造成一個問題，如果在數(shù)據(jù)沒有同步到從節(jié)點時，主節(jié)點掛掉，就會產(chǎn)生數(shù)據(jù)丟失的情況。
Zookeeper
Zookeeper使用類paxos算法來保障數(shù)據(jù)的一致性。簡單的講，當一個DML語句發(fā)送給主節(jié)點時，Zookeeper需要保證一半以上的節(jié)點接收到數(shù)據(jù)，才會返回成功。并且當主節(jié)點掛掉，從節(jié)點重新選舉時，同步到最新的數(shù)據(jù)的節(jié)點會有優(yōu)先選舉權(quán)。
舉個例子：
一個4節(jié)點Zookeeper（A、B、C、D），A是主節(jié)點，當執(zhí)行一個create語句成功時，至少有3臺節(jié)點執(zhí)行成功（一半以上），例如A、C、D成功。此時如果A節(jié)點掛了，B、C、D進行選舉，由于C、D都執(zhí)行成功了create語句，B沒有執(zhí)行，C、D的數(shù)據(jù)更加新，具有優(yōu)先選舉權(quán)，再根據(jù)名稱排序，選擇C做為主節(jié)點。在整個選舉過程中，服務(wù)不可用，選舉完成后，C節(jié)點和A節(jié)點數(shù)據(jù)一致，不會出現(xiàn)丟失的情況。
分布式鎖
要實現(xiàn)分布式鎖，需要滿足一些要求：
只能有一個服務(wù)的一個線程能獲取鎖
一個持有鎖的線程掛掉后，鎖應(yīng)該被釋放，用來給其他線程用
一個持有鎖的線程沒執(zhí)行完，鎖不能釋放
鎖釋放后，其他等待者可以繼續(xù)爭搶
管理鎖的主節(jié)點（Redis或Zookeeper）掛了，重新選舉后，不影響鎖的持有情況
Redis解決方案
問題1、問題2：使用“SET key value EX seconds NX”語句獲取鎖并設(shè)置過期時間
問題3：另開一個監(jiān)控線程，監(jiān)控主線程執(zhí)行情況，用來延長過期時間
問題4：等待線程定時檢查鎖的持有情況
問題5：暫無或者解決成本很高，需要自己實現(xiàn)類paxos的算法
Zookeeper解決方案
通過創(chuàng)建臨時節(jié)點可以解決問題1，2，3
watch機制可以解決問題4，并且相比定時檢查，watch可以做到更高實時性
zookeeper的paxos同步機制保障了節(jié)點間數(shù)據(jù)一致性，即使主節(jié)點掛掉，也可以保障數(shù)據(jù)不丟，可以解決問題5
對比可以發(fā)現(xiàn)：
Zookeeper的機制可以保證分布式鎖實現(xiàn)業(yè)務(wù)代碼簡單，成本低。
Redis如果要解決分布式鎖的問題，對于一些復雜的情況，很難解決，成本較高。
騰訊、阿里、滴滴后臺面試題匯總總結(jié) — （含答案）
面試：史上最全多線程面試題 ！
最新阿里內(nèi)推Java后端面試題
JVM難學？那是因為你沒認真看完這篇文章
關(guān)注作者微信公眾號 —《JAVA爛豬皮》
了解更多java后端架構(gòu)知識以及最新面試寶典
看完本文記得給作者點贊+在看哦~~~大家的支持，是作者源源不斷出文的動力
作者：宇的季節(jié)
出處：https://www.cnblogs.com/chenkeyu/p/14793627.html