接手一個(gè)需要多服務(wù)協(xié)作的項(xiàng)目時(shí)我踩過(guò)的第一個(gè)大坑就是所有節(jié)點(diǎn)各干各的沒(méi)有一套統(tǒng)一的協(xié)調(diào)機(jī)制。后來(lái)我把ZooKeeper引入整個(gè)架構(gòu)先后解決了配置同步、服務(wù)上下線感知和分布式鎖這幾個(gè)最頭疼的問(wèn)題。這篇文章就是我基于實(shí)際項(xiàng)目做的階段性總結(jié)寫(xiě)給正在學(xué)Java分布式、并且準(zhǔn)備把ZooKeeper用起來(lái)的開(kāi)發(fā)者尤其是那些剛看完理論、想知道怎么落地的朋友。我會(huì)從ZooKeeper的定位講起帶著你理解它的數(shù)據(jù)模型和會(huì)話機(jī)制然后給出Java客戶端選型的關(guān)鍵對(duì)比再手把手拆解節(jié)點(diǎn)CRUD、Watch監(jiān)聽(tīng)、分布式鎖和服務(wù)發(fā)現(xiàn)這些高頻實(shí)戰(zhàn)場(chǎng)景最后聊幾個(gè)我親身踩過(guò)的坑。整個(gè)內(nèi)容不求面面俱到但保證每一個(gè)步驟和代碼示例都能讓你直接抄作業(yè)改一改就能跑。1. 為什么分布式系統(tǒng)里需要ZooKeeper這個(gè)協(xié)調(diào)員分布式系統(tǒng)的難點(diǎn)往往不在功能實(shí)現(xiàn)而在多個(gè)進(jìn)程之間怎么達(dá)成一致。我剛接手項(xiàng)目X的時(shí)候服務(wù)數(shù)量從幾臺(tái)擴(kuò)展到幾十臺(tái)馬上就遇到三個(gè)問(wèn)題配置文件散落在各節(jié)點(diǎn)上、改了配置要一臺(tái)臺(tái)重啟、服務(wù)掛了其他調(diào)用方感知不到。這些問(wèn)題的共性就是缺少一個(gè)可以讓所有節(jié)點(diǎn)共同依賴的協(xié)調(diào)者。1.1 沒(méi)有協(xié)調(diào)框架時(shí)的混亂場(chǎng)景舉個(gè)例子項(xiàng)目X里有三個(gè)服務(wù)需要共享一份DB開(kāi)關(guān)配置。我最初的做法是把配置寫(xiě)在每個(gè)服務(wù)本地的properties文件里運(yùn)維改配置時(shí)用腳本批量推送。聽(tīng)起來(lái)簡(jiǎn)單但實(shí)際會(huì)發(fā)生兩種情況推送時(shí)部分節(jié)點(diǎn)成功、部分節(jié)點(diǎn)失敗失敗節(jié)點(diǎn)繼續(xù)跑舊邏輯新邏輯和舊邏輯并行。服務(wù)擴(kuò)容時(shí)新拉起來(lái)的機(jī)器如果配置文件不是最新版會(huì)帶著舊配置進(jìn)入生產(chǎn)環(huán)境。更麻煩的是分布式鎖。早期我用數(shù)據(jù)庫(kù)的唯一索引做鎖通過(guò)insert一條記錄來(lái)占用鎖最后delete釋放。在高并發(fā)下數(shù)據(jù)庫(kù)連接會(huì)被打滿而且鎖的續(xù)租、異常釋放、死鎖檢測(cè)全部要自己寫(xiě)。后來(lái)我決定徹底改造用ZooKeeper把這些分散的麻煩事統(tǒng)一收攏。1.2 ZooKeeper到底替我們解決了什么問(wèn)題ZooKeeper在架構(gòu)里扮演的角色簡(jiǎn)單說(shuō)就是一個(gè)帶強(qiáng)一致性的分布式文件系統(tǒng)同時(shí)具備通知機(jī)制。它讓你可以像操作目錄一樣存數(shù)據(jù)又能在數(shù)據(jù)變化時(shí)主動(dòng)告訴訂閱者。如果把這個(gè)模型放到業(yè)務(wù)場(chǎng)景里可以看到幾個(gè)核心能力統(tǒng)一配置存儲(chǔ)配置放ZooKeeper節(jié)點(diǎn)上集中修改所有客戶端實(shí)時(shí)收到變更通知。服務(wù)注冊(cè)和發(fā)現(xiàn)服務(wù)啟動(dòng)時(shí)注冊(cè)臨時(shí)節(jié)點(diǎn)服務(wù)掛掉后節(jié)點(diǎn)自動(dòng)消失調(diào)用方通過(guò)Watch感知上下線。分布式鎖利用ZooKeeper的臨時(shí)順序節(jié)點(diǎn)多個(gè)客戶端可以排隊(duì)獲取鎖避免了單點(diǎn)故障。這三類能力基本覆蓋了中小團(tuán)隊(duì)80%的協(xié)調(diào)需求。ZooKeeper之所以能承擔(dān)這些職責(zé)是因?yàn)樗澈蟮腪ab協(xié)議保證了寫(xiě)入順序的一致性和高可用。集群內(nèi)部通過(guò)選舉產(chǎn)生Leader所有寫(xiě)請(qǐng)求都交給Leader廣播給Follower超過(guò)半數(shù)確認(rèn)后返回成功保證數(shù)據(jù)不會(huì)因?yàn)楣?jié)點(diǎn)故障而分叉。1.3 它不是萬(wàn)能存儲(chǔ)適用邊界要先劃清楚我在團(tuán)隊(duì)內(nèi)部做技術(shù)分享時(shí)總強(qiáng)調(diào)一句話不要把ZooKeeper當(dāng)數(shù)據(jù)庫(kù)用。它默認(rèn)單個(gè)節(jié)點(diǎn)的數(shù)據(jù)大小限制通常是1MB不適合存業(yè)務(wù)大對(duì)象。它更適合存配置項(xiàng)、元數(shù)據(jù)、鎖標(biāo)識(shí)這類小而關(guān)鍵的信息。如果你發(fā)現(xiàn)某個(gè)ZNode里的數(shù)據(jù)超過(guò)幾十KB就要停下來(lái)想想是不是設(shè)計(jì)有問(wèn)題。ZooKeeper的強(qiáng)順序一致性也是有時(shí)機(jī)代價(jià)的寫(xiě)請(qǐng)求需要多數(shù)派確認(rèn)所以吞吐量跟Redis沒(méi)法比。業(yè)務(wù)向的高頻寫(xiě)操作建議放RedisZooKeeper只做協(xié)調(diào)類數(shù)據(jù)。把邊界劃清楚后面用起來(lái)才不別扭。2. 數(shù)據(jù)模型與會(huì)話機(jī)制入門ZooKeeper前必須搞懂的四個(gè)核心概念跳過(guò)這些底層概念直接寫(xiě)代碼很容易遇到各種摸不著頭腦的問(wèn)題。我見(jiàn)過(guò)不少同事在寫(xiě)節(jié)點(diǎn)操作時(shí)搞不清持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)的區(qū)別結(jié)果服務(wù)重啟后舊節(jié)點(diǎn)還掛在線上服務(wù)注冊(cè)信息一直重復(fù)。所以我想先把四個(gè)核心概念講透。2.1 樹(shù)形數(shù)據(jù)模型ZNode不是傳統(tǒng)的文件ZooKeeper的命名空間是一棵類似文件系統(tǒng)的樹(shù)每個(gè)節(jié)點(diǎn)叫ZNode。路徑比如 /config、/config/db_switch寫(xiě)法上和Linux目錄一樣訪問(wèn)某個(gè)ZNode就是直接按路徑定位。與傳統(tǒng)文件系統(tǒng)不同ZNode既可以有子節(jié)點(diǎn)本身也可以存數(shù)據(jù)這一點(diǎn)要特別注意。每個(gè)ZNode的數(shù)據(jù)量很小實(shí)際操作時(shí)一般存JSON字符串或特定業(yè)務(wù)標(biāo)識(shí)。ZNode上不僅有數(shù)據(jù)還附帶一系列元信息比如版本號(hào)、創(chuàng)建時(shí)間、數(shù)據(jù)長(zhǎng)度。這里最關(guān)鍵的一個(gè)元信息是版本號(hào)因?yàn)閆ooKeeper的并發(fā)改造成靠版本號(hào)來(lái)實(shí)現(xiàn)類似樂(lè)觀鎖的機(jī)制。2.2 節(jié)點(diǎn)類型持久、臨時(shí)、順序節(jié)點(diǎn)各自的使用場(chǎng)景ZooKeeper把ZNode分成幾種類型每個(gè)類型都對(duì)應(yīng)一個(gè)典型業(yè)務(wù)場(chǎng)景節(jié)點(diǎn)類型特點(diǎn)典型用途持久節(jié)點(diǎn)客戶端斷開(kāi)后節(jié)點(diǎn)依然存在保存配置數(shù)據(jù)、全局元信息持久順序節(jié)點(diǎn)持久節(jié)點(diǎn)基礎(chǔ)上帶全局自增序號(hào)記錄有序事件、任務(wù)編號(hào)臨時(shí)節(jié)點(diǎn)客戶端會(huì)話結(jié)束自動(dòng)刪除服務(wù)注冊(cè)、分布式鎖占位臨時(shí)順序節(jié)點(diǎn)臨時(shí)節(jié)點(diǎn)基礎(chǔ)上帶全局自增序號(hào)分布式鎖的排隊(duì)隊(duì)列我最初用過(guò)持久節(jié)點(diǎn)做服務(wù)注冊(cè)結(jié)果服務(wù)宕機(jī)后節(jié)點(diǎn)不會(huì)消失手動(dòng)清理又容易出錯(cuò)。后來(lái)改成臨時(shí)節(jié)點(diǎn)服務(wù)進(jìn)程退出、會(huì)話斷開(kāi)節(jié)點(diǎn)馬上被刪除整個(gè)上下線流程就自動(dòng)化了。順序節(jié)點(diǎn)雖然不常用但分布式鎖里它是核心因?yàn)殒i競(jìng)爭(zhēng)退出時(shí)可以利用序號(hào)的先后關(guān)系確定獲取順序避免驚群效應(yīng)。2.3 會(huì)話與心跳客戶端和服務(wù)器如何維持連接ZooKeeper客戶端和服務(wù)端之間的連接基于會(huì)話會(huì)話本質(zhì)是一個(gè)帶超時(shí)時(shí)間的TCP長(zhǎng)連接。客戶端通過(guò)發(fā)送心跳請(qǐng)求來(lái)?；罘?wù)端在會(huì)話超時(shí)時(shí)間內(nèi)收到心跳會(huì)話就保持有效超過(guò)時(shí)間還沒(méi)收到會(huì)話過(guò)期臨時(shí)節(jié)點(diǎn)隨之被清理。Java操作時(shí)我一般配置會(huì)話超時(shí)時(shí)間為3000到5000毫秒這個(gè)值既不能太大也不能太小。太大會(huì)話過(guò)期識(shí)別慢臨時(shí)節(jié)點(diǎn)殘留時(shí)間久太小網(wǎng)絡(luò)抖動(dòng)就會(huì)導(dǎo)致會(huì)話誤判超時(shí)服務(wù)頻繁掉線。再配合客戶端自動(dòng)重連機(jī)制即使網(wǎng)絡(luò)短暫異常原來(lái)創(chuàng)建的臨時(shí)節(jié)點(diǎn)也會(huì)在重連后恢復(fù)但這個(gè)恢復(fù)并不自動(dòng)需要代碼回滾業(yè)務(wù)邏輯。2.4 Watch通知機(jī)制一次性觸發(fā)循環(huán)注冊(cè)Watch是ZooKeeper最實(shí)用也最容易寫(xiě)錯(cuò)的機(jī)制?？蛻舳丝梢詫?duì)某個(gè)事務(wù)操作注冊(cè)監(jiān)聽(tīng)比如節(jié)點(diǎn)數(shù)據(jù)變化、子節(jié)點(diǎn)列表變化、節(jié)點(diǎn)刪除只要事件發(fā)生客戶端會(huì)收到一次通知。注意是“一次”因?yàn)槊看瓮ㄖ曛蟊O(jiān)聽(tīng)就失效了想繼續(xù)監(jiān)聽(tīng)必須重新注冊(cè)。這個(gè)一次性規(guī)則讓很多初學(xué)者困惑為什么第一次修改配置能收到通知第二次就不行原因就是沒(méi)做再次注冊(cè)。后面的代碼示例里我會(huì)專門封裝一個(gè)帶循環(huán)注冊(cè)的工具類把每次收到通知后重新設(shè)置Watch這個(gè)動(dòng)作固化進(jìn)去。3. 客戶端選型原生API、ZkClient與Curator的取舍Java操作ZooKeeper時(shí)選型直接影響開(kāi)發(fā)效率和后期維護(hù)。我在這部分有比較明確的答案但為了讓你做技術(shù)決策時(shí)有依據(jù)我先把三種方案的實(shí)際體驗(yàn)都列出來(lái)。3.1 三種客戶端方案的橫向?qū)Ρ染S度原生ZooKeeper APIZkClientCurator依賴程度JDK自帶輕量封裝完整框架Watch處理手動(dòng)循環(huán)注冊(cè)自動(dòng)監(jiān)聽(tīng)自動(dòng)監(jiān)聽(tīng)重連機(jī)制需自己實(shí)現(xiàn)簡(jiǎn)單封裝完善分布式鎖需要手寫(xiě)需要手寫(xiě)內(nèi)置實(shí)現(xiàn)維護(hù)活躍度保持更新基本停滯活躍學(xué)習(xí)曲線較陡平滑中間原生API最大的問(wèn)題不是功能不夠而是重復(fù)代碼太多。每次操作都要處理連接狀態(tài)、重連邏輯、Watch重新注冊(cè)這些都是極其容易出錯(cuò)的邊角料。ZkClient曾經(jīng)流行過(guò)一段但封裝程度有限遇到復(fù)雜會(huì)話事件處理比較吃力。如果你問(wèn)我現(xiàn)在的建議我會(huì)直接推薦Curator它在國(guó)內(nèi)項(xiàng)目里已經(jīng)積累了足夠的驗(yàn)證文檔也相對(duì)齊全。3.2 為什么我建議直接上CuratorCurator把ZooKeeper客戶端做成了可以開(kāi)箱即用的框架提供了連接狀態(tài)監(jiān)聽(tīng)、自動(dòng)重連、Watch管理器還內(nèi)置了InterProcessMutex這類分布式鎖實(shí)現(xiàn)。引入Curator之后代碼量對(duì)比原生API至少減少一半同時(shí)可讀性和健壯性明顯提升。當(dāng)然這不意味著原生API不值得學(xué)。我建議你先把原生API的基本操作跑一遍理解它怎么建立連接、怎么注冊(cè)Watch、怎么處理回調(diào)然后切到Curator你會(huì)更清楚框架替你做了什么遇到問(wèn)題時(shí)也能定位到ZooKeeper底層還是框架封裝層。這種學(xué)習(xí)路徑比直接上手Curator更扎實(shí)。3.3 環(huán)境準(zhǔn)備單機(jī)部署和偽集群搭建本地開(kāi)發(fā)時(shí)單機(jī)模式就夠用。下載解壓后修改配置文件zoo.cfg設(shè)置dataDir和clientPort默認(rèn)2181端口然后執(zhí)行啟動(dòng)腳本。確認(rèn)啟動(dòng)成功的命令是連接2181端口并輸入stat能看到ZooKeeper版本信息就說(shuō)明通了。如果需要模擬生產(chǎn)環(huán)境的故障轉(zhuǎn)移我建議用偽集群模式也就是在同一臺(tái)機(jī)器上跑三個(gè)ZooKeeper實(shí)例。三個(gè)實(shí)例分別監(jiān)聽(tīng)2181、2182、2183端口dataDir也分成三份并且在每個(gè)實(shí)例的data目錄中都要新建myid文件內(nèi)容分別是1、2、3。配置文件里通過(guò)server.1127.0.0.1:2888:3888這樣的格式聲明集群成員。偽集群能驗(yàn)證選舉和會(huì)話轉(zhuǎn)移對(duì)理解ZooKeeper高可用機(jī)制幫助很大。4. 手寫(xiě)Java操作ZooKeeper從連接、CRUD到Watch監(jiān)聽(tīng)這一章是實(shí)操的重點(diǎn)。我會(huì)同時(shí)給出原生API和Curator兩套代碼方便你根據(jù)項(xiàng)目實(shí)際情況選用。所有代碼我都基于實(shí)際跑通的示例整理你復(fù)制到自己的項(xiàng)目里改幾個(gè)參數(shù)就能用。4.1 基礎(chǔ)依賴與連接建立如果用Curator需要在pom.xml中加入dependency groupIdorg.apache.curator/groupId artifactIdcurator-framework/artifactId version5.5.0/version /dependency dependency groupIdorg.apache.curator/groupId artifactIdcurator-recipes/artifactId version5.5.0/version /dependency如果只是想體驗(yàn)原生API只需要引入ZooKeeper官方客戶端依賴。不過(guò)下文除了最基礎(chǔ)的連接示例用原生API后面的業(yè)務(wù)操作我都用Curator因?yàn)镃urator的API設(shè)計(jì)更適合工程落地。原生API建立連接的方式ZooKeeper zooKeeper new ZooKeeper(127.0.0.1:2181, 3000, event - { System.out.println(收到事件 event.getType()); });原生API的構(gòu)造函數(shù)中第一個(gè)參數(shù)是連接串第二個(gè)是會(huì)話超時(shí)時(shí)間第三個(gè)是Watcher回調(diào)。連接本身是異步的所以構(gòu)造完成后要等待一下確認(rèn)連接穩(wěn)定再繼續(xù)執(zhí)行后續(xù)操作。用Curator建立連接的代碼會(huì)更直觀RetryPolicy retryPolicy new ExponentialBackoffRetry(1000, 3); CuratorFramework client CuratorFramework.builder() .connectString(127.0.0.1:2181) .sessionTimeoutMs(3000) .connectionTimeoutMs(3000) .retryPolicy(retryPolicy) .build(); client.start();ExponentialBackoffRetry設(shè)置了初始重試間隔1000毫秒、最多重試3次。Curator啟動(dòng)后不是馬上連上實(shí)際操作前最好調(diào)用blockUntilConnected等待連接建立避免在未連接狀態(tài)執(zhí)行命令拋異常。4.2 節(jié)點(diǎn)的增刪改查與版本控制用Curator操作節(jié)點(diǎn)非常方便。創(chuàng)建持久節(jié)點(diǎn)的代碼client.create().creatingParentContainersIfNeeded() .withMode(CreateMode.PERSISTENT) .forPath(/config/db_switch, on.getBytes(StandardCharsets.UTF_8));creatingParentContainersIfNeeded會(huì)自動(dòng)創(chuàng)建父節(jié)點(diǎn)這個(gè)特性很實(shí)用避免手動(dòng)判斷父路徑是否存在。withMode指定節(jié)點(diǎn)類型CreateMode.PERSISTENT是持久節(jié)點(diǎn)如果做服務(wù)注冊(cè)就換成EPHEMERAL。讀取節(jié)點(diǎn)數(shù)據(jù)byte[] data client.getData().forPath(/config/db_switch); String value new String(data, StandardCharsets.UTF_8);更新節(jié)點(diǎn)有兩種情況。第一種直接覆蓋用setData第二種是帶版本號(hào)的更新。ZooKeeper里的setData可以指定期望版本如果當(dāng)前版本和期望版本不一致會(huì)拋出BadVersionException。這種機(jī)制適合保證多人同時(shí)改配置時(shí)不覆蓋別人的修改client.setData() .withVersion(0) .forPath(/config/db_switch, off.getBytes(StandardCharsets.UTF_8));刪除節(jié)點(diǎn)也有版本控制并且刪除有子節(jié)點(diǎn)的節(jié)點(diǎn)會(huì)失敗需要先遞歸刪除子節(jié)點(diǎn)。Curator的刪除方法支持guaranteed和deletingChildrenIfNeeded前者保證網(wǎng)絡(luò)異常時(shí)后臺(tái)重試刪除后者自動(dòng)清理子節(jié)點(diǎn)client.delete().guaranteed().deletingChildrenIfNeeded().forPath(/config);4.3 一個(gè)能落地的Watch監(jiān)聽(tīng)循環(huán)Watch是ZooKeeper最核心的機(jī)制代碼也最容易出錯(cuò)。原生API的寫(xiě)法是注冊(cè)Watcher但一次觸發(fā)后失效所以要在回調(diào)里再次注冊(cè)。下面是封裝好的循環(huán)監(jiān)聽(tīng)工具public class ConfigWatcher { private final ZooKeeper zooKeeper; public ConfigWatcher(ZooKeeper zooKeeper) { this.zooKeeper zooKeeper; } public void watch(String path) throws Exception { // 用getData注冊(cè)監(jiān)聽(tīng)監(jiān)聽(tīng)的事件是節(jié)點(diǎn)數(shù)據(jù)變化 byte[] data zooKeeper.getData(path, event - { System.out.println(配置發(fā)生變化 event.getPath()); try { // 實(shí)際業(yè)務(wù)處理比如刷新本地緩存 handleConfigChange(path); // 重點(diǎn)重新注冊(cè)監(jiān)聽(tīng) watch(path); } catch (Exception ex) { ex.printStackTrace(); } }, null); System.out.println(當(dāng)前配置值 new String(data)); } }這段代碼的關(guān)鍵點(diǎn)就在watch方法末尾再次調(diào)用自己注冊(cè)下一次監(jiān)聽(tīng)。漏掉這一步監(jiān)聽(tīng)只會(huì)觸發(fā)一次。我在項(xiàng)目里看到過(guò)很多次這個(gè)問(wèn)題造成的現(xiàn)象是配置第一次修改生效以后再也收不到通知。用Curator時(shí)可以借助CuratorCache或者NodeCache來(lái)簡(jiǎn)化監(jiān)聽(tīng)邏輯。NodeCache在節(jié)點(diǎn)數(shù)據(jù)變化時(shí)觸發(fā)支持再次監(jiān)聽(tīng)不需要手動(dòng)循環(huán)NodeCache nodeCache new NodeCache(client, /config/db_switch); nodeCache.getListenable().addListener(() - { String newValue new String(nodeCache.getCurrentData().getData()); System.out.println(最新配置 newValue); }); nodeCache.start();NodeCache啟動(dòng)后內(nèi)部自己處理了Watch重新注冊(cè)你只需要關(guān)心業(yè)務(wù)邏輯。這也是我更推薦Curator的原因把最容易錯(cuò)的邊角料封住了。4.4 關(guān)于序列化傳數(shù)據(jù)到底傳什么操作ZNode時(shí)雖然接口接收的是byte[]但實(shí)際傳什么內(nèi)容我建議先約定好。寫(xiě)項(xiàng)目X時(shí)我統(tǒng)一用JSON字符串把配置項(xiàng)封裝成對(duì)象后序列化存儲(chǔ)到節(jié)點(diǎn)里。讀取時(shí)再反序列化回對(duì)象。如果直接用Java原生序列化雖然類實(shí)現(xiàn)了Serializable就能存但跨語(yǔ)言調(diào)用會(huì)很痛苦而且序列化內(nèi)容體積大浪費(fèi)ZooKeeper有限的存儲(chǔ)空間。所以我的建議是存量小字段直接用字符串比如開(kāi)關(guān)狀態(tài)寫(xiě)on/off。結(jié)構(gòu)化成組配置用JSON字符串。切勿存大對(duì)象或大數(shù)組。深度思考一下ZooKeeper節(jié)點(diǎn)的數(shù)據(jù)是給所有客戶端看的用通用的JSON格式意味著不同語(yǔ)言的服務(wù)也能解析這比綁定Java序列化的方案通用性強(qiáng)很多。5. 實(shí)戰(zhàn)分布式鎖、服務(wù)發(fā)現(xiàn)、配置下發(fā)這三個(gè)場(chǎng)景怎么拆掌握基礎(chǔ)操作后關(guān)鍵是把它們組合成真正的業(yè)務(wù)解決方案。這一章我會(huì)挑三個(gè)最有代表性的實(shí)戰(zhàn)場(chǎng)景完整說(shuō)明設(shè)計(jì)思路和實(shí)現(xiàn)步驟。5.1 用臨時(shí)順序節(jié)點(diǎn)實(shí)現(xiàn)分布式鎖項(xiàng)目X里有個(gè)定時(shí)任務(wù)需要保證集群里只有一個(gè)實(shí)例在執(zhí)行。最初用數(shù)據(jù)庫(kù)鎖后來(lái)切到ZooKeeper后穩(wěn)定很多。原理很簡(jiǎn)單多個(gè)客戶端在同一個(gè)鎖路徑下創(chuàng)建臨時(shí)順序節(jié)點(diǎn)序號(hào)最小的獲得鎖其他客戶端監(jiān)聽(tīng)序號(hào)比自己小的節(jié)點(diǎn)等它刪除后再嘗試獲得鎖。用Curator內(nèi)置的InterProcessMutex代碼幾乎沒(méi)有門檻InterProcessMutex lock new InterProcessMutex(client, /lock/order_task); boolean acquired lock.acquire(5, TimeUnit.SECONDS); if (acquired) { try { // 執(zhí)行定時(shí)任務(wù) doTask(); } finally { lock.release(); } }acquire方法第二個(gè)參數(shù)是獲取鎖的超時(shí)時(shí)間超過(guò)則放棄避免線程長(zhǎng)時(shí)間卡死。release方法必須在finally里調(diào)用否則鎖不會(huì)釋放其他實(shí)例會(huì)一直阻塞。還要注意如果進(jìn)程崩潰鎖節(jié)點(diǎn)因?yàn)槭桥R時(shí)節(jié)點(diǎn)會(huì)自動(dòng)被ZooKeeper清除這也是這個(gè)方案比數(shù)據(jù)庫(kù)鎖穩(wěn)的原因之一。如果不用Curator也可以基于原生API自己實(shí)現(xiàn)分布式鎖核心代碼邏輯是創(chuàng)建臨時(shí)順序節(jié)點(diǎn)然后獲取父節(jié)點(diǎn)下所有子節(jié)點(diǎn)列表判斷自己序號(hào)是否最小。不過(guò)這部分代碼要處理監(jiān)聽(tīng)和重試細(xì)節(jié)我強(qiáng)烈建議直接用InterProcessMutex。5.2 服務(wù)注冊(cè)與發(fā)現(xiàn)沒(méi)有注冊(cè)中心時(shí)怎么辦服務(wù)注冊(cè)與發(fā)現(xiàn)是ZooKeeper非常經(jīng)典的場(chǎng)景。服務(wù)啟動(dòng)時(shí)在 /services/服務(wù)名下創(chuàng)建臨時(shí)節(jié)點(diǎn)節(jié)點(diǎn)里存服務(wù)地址。調(diào)用方監(jiān)聽(tīng) /services/服務(wù)名 下的子節(jié)點(diǎn)列表變化就能實(shí)時(shí)感知服務(wù)的上下線。服務(wù)端注冊(cè)的示例String servicePath /services/order-service; String instancePath servicePath /instance- UUID.randomUUID(); String address 192.168.1.10:8080; client.create().creatingParentContainersIfNeeded() .withMode(CreateMode.EPHEMERAL) .forPath(instancePath, address.getBytes(StandardCharsets.UTF_8));客戶端訂閱服務(wù)列表的示例PathChildrenCache cache new PathChildrenCache(client, /services/order-service, true); cache.getListenable().addListener((curator, event) - { System.out.println(服務(wù)列表發(fā)生變化 event.getType()); cache.getCurrentData().forEach(data - { String address new String(data.getData()); System.out.println(可用實(shí)例 address); }); }); cache.start();PathChildrenCache是Curator提供的子節(jié)點(diǎn)監(jiān)聽(tīng)工具啟動(dòng)后監(jiān)聽(tīng)子節(jié)點(diǎn)新增、刪除、數(shù)據(jù)修改。服務(wù)上下線時(shí)監(jiān)聽(tīng)回調(diào)會(huì)收到事件客戶端就可以更新本地服務(wù)列表。配合臨時(shí)節(jié)點(diǎn)能夠?qū)崿F(xiàn)服務(wù)宕機(jī)自動(dòng)摘除整個(gè)過(guò)程不需要人工介入。5.3 配置中心動(dòng)態(tài)下發(fā)與App內(nèi)熱更新配置中心是ZooKeeper比較容易上手的場(chǎng)景。我把項(xiàng)目X的數(shù)據(jù)庫(kù)連接池參數(shù)、功能開(kāi)關(guān)、限流閾值全部放到了 /config 路徑下每個(gè)子節(jié)點(diǎn)對(duì)應(yīng)一個(gè)配置項(xiàng)。服務(wù)啟動(dòng)時(shí)讀取一次然后注冊(cè)監(jiān)聽(tīng)配置更新后應(yīng)用自動(dòng)刷新對(duì)應(yīng)組件。一個(gè)典型的配置模型// 啟動(dòng)加載 byte[] data client.getData().forPath(/config/db_pool_max_active); String maxActive new String(data); // 修改數(shù)據(jù)庫(kù)連接池 dataSource.setMaxActive(Integer.parseInt(maxActive)); // 啟動(dòng)監(jiān)聽(tīng)后續(xù)變化實(shí)時(shí)更新 NodeCache cache new NodeCache(client, /config/db_pool_max_active); cache.getListenable().addListener(() - { String newMaxActive new String(cache.getCurrentData().getData()); dataSource.setMaxActive(Integer.parseInt(newMaxActive)); }); cache.start();這套配置中心實(shí)現(xiàn)上非常簡(jiǎn)單比引入完整的配置中心中間件輕量得多。如果你只是需要十幾個(gè)配置項(xiàng)的熱更新ZooKeeper是性價(jià)比極高的方案。但要注意配置項(xiàng)應(yīng)該集中在一個(gè)路徑下方便管理還要為沒(méi)有經(jīng)驗(yàn)的運(yùn)維同學(xué)準(zhǔn)備好配置變更的操作文檔避免改錯(cuò)數(shù)據(jù)格式導(dǎo)致應(yīng)用啟動(dòng)時(shí)解析失敗。5.4 三個(gè)場(chǎng)景的通用套路總結(jié)拆完三個(gè)場(chǎng)景你能發(fā)現(xiàn)它們共享同一套設(shè)計(jì)模式選定ZNode路徑、確定節(jié)點(diǎn)類型、注冊(cè)Watch。服務(wù)注冊(cè)用臨時(shí)節(jié)點(diǎn)是因?yàn)橐詣?dòng)清理配置存儲(chǔ)用持久節(jié)點(diǎn)是因?yàn)橐L(zhǎng)期保存分布式鎖用臨時(shí)順序節(jié)點(diǎn)是因?yàn)橐抨?duì)和自動(dòng)釋放。所以學(xué)習(xí)ZooKeeper時(shí)不需要死記硬背API關(guān)鍵是能把業(yè)務(wù)需求翻譯成“節(jié)點(diǎn)類型 監(jiān)聽(tīng)事件”的二元組。翻譯對(duì)了代碼只是時(shí)間問(wèn)題。6. 生產(chǎn)環(huán)境必須面對(duì)的幾個(gè)硬骨頭把ZooKeeper放到生產(chǎn)環(huán)境之前有幾個(gè)問(wèn)題必須提前想清楚。我在項(xiàng)目X推進(jìn)的過(guò)程中就踩過(guò)不少坑這里挑影響最大的幾個(gè)說(shuō)。6.1 會(huì)話超時(shí)與心跳假死ZooKeeper客戶端會(huì)話超時(shí)機(jī)制是它高可用的基礎(chǔ)但也容易造成假死?，F(xiàn)象是服務(wù)進(jìn)程還在但ZooKeeper服務(wù)端判斷會(huì)話過(guò)期把臨時(shí)節(jié)點(diǎn)清掉了其他客戶端看到你的服務(wù)已經(jīng)下線實(shí)際你的進(jìn)程還在運(yùn)行。我遇到過(guò)一次比較典型的情況某服務(wù)因?yàn)镕ull GC暫停了幾秒心跳沒(méi)發(fā)出去ZooKeeper判定會(huì)話超時(shí)把臨時(shí)節(jié)點(diǎn)刪了。Full GC恢復(fù)后服務(wù)還在處理業(yè)務(wù)下游已經(jīng)把流量切走了。這個(gè)問(wèn)題靠代碼很難完全規(guī)避但可以通過(guò)調(diào)大sessionTimeout來(lái)降低誤判概率。我線上一般設(shè)sessionTimeoutMs為10秒比本地開(kāi)發(fā)時(shí)大不少。處理方式是在客戶端加上ConnectionStateListener監(jiān)聽(tīng)會(huì)話的重連和過(guò)期事件。Curator里這個(gè)Listener會(huì)告訴你RECONNECTED或者LOST。收到LOST事件時(shí)業(yè)務(wù)側(cè)必須主動(dòng)檢查自己的臨時(shí)節(jié)點(diǎn)是否還存在不存在就需要重新注冊(cè)。6.2 Watch風(fēng)暴與重復(fù)注冊(cè)Watch機(jī)制雖然好用但用不好會(huì)造成嚴(yán)重問(wèn)題。如果幾百個(gè)客戶端對(duì)同一個(gè)父節(jié)點(diǎn)注冊(cè)子節(jié)點(diǎn)監(jiān)聽(tīng)那么這個(gè)節(jié)點(diǎn)一變化幾百個(gè)客戶端全部被打醒同時(shí)執(zhí)行后續(xù)邏輯這就是Watch風(fēng)暴。我在項(xiàng)目X早期犯過(guò)這個(gè)錯(cuò)誤所有服務(wù)實(shí)例都在監(jiān)聽(tīng)同一個(gè)服務(wù)列表節(jié)點(diǎn)導(dǎo)致服務(wù)上下線時(shí)通知量爆炸。優(yōu)化方案是把監(jiān)聽(tīng)改為客戶端主動(dòng)輪詢或者說(shuō)改變數(shù)據(jù)組織方式讓每個(gè)客戶端只關(guān)心自己需要的那部分節(jié)點(diǎn)。比如把子節(jié)點(diǎn)按租戶分隔客戶端只監(jiān)聽(tīng)自己租戶的路徑。這個(gè)調(diào)整之后通知量降了一個(gè)數(shù)量級(jí)效果立竿見(jiàn)影。另外就是重復(fù)注冊(cè)的坑。在緩存框架里一個(gè)節(jié)點(diǎn)被多個(gè)模塊同時(shí)監(jiān)聽(tīng)很容易產(chǎn)生重復(fù)的Watcher。釋放節(jié)點(diǎn)緩存時(shí)必須調(diào)用close清理監(jiān)聽(tīng)否則舊監(jiān)聽(tīng)會(huì)一直駐留不僅浪費(fèi)內(nèi)存還會(huì)造成重復(fù)通知。6.3 單機(jī)模式的坑與集群容錯(cuò)本地開(kāi)發(fā)用單機(jī)模式?jīng)]問(wèn)題但生產(chǎn)環(huán)境千萬(wàn)不能只部署一個(gè)ZooKeeper實(shí)例。一旦這個(gè)單點(diǎn)宕機(jī)依賴它的配置中心和分布式鎖全部癱瘓整個(gè)系統(tǒng)都被卡住。我建議生產(chǎn)環(huán)境至少部署三個(gè)實(shí)例并且滿足奇數(shù)個(gè)。這是ZooKeeper選舉機(jī)制決定的3個(gè)實(shí)例允許掛1個(gè)5個(gè)允許掛2個(gè)。如果只部署2個(gè)掛1個(gè)就達(dá)不到多數(shù)派條件集群直接不可用還不如單機(jī)。部署時(shí)還要注意ZooKeeper和業(yè)務(wù)應(yīng)用盡量分離部署不要圖省事混在同一個(gè)宿主機(jī)上否則宿主機(jī)資源被業(yè)務(wù)占滿時(shí)ZooKeeper的磁盤和端口也會(huì)受影響容易產(chǎn)生連鎖故障。6.4 ACL權(quán)限不要讓ZNode裸奔很多團(tuán)隊(duì)搭建ZooKeeper后節(jié)點(diǎn)默認(rèn)不設(shè)任何權(quán)限所有人都能讀寫(xiě)。在開(kāi)發(fā)環(huán)境可以容忍但生產(chǎn)環(huán)境這樣做風(fēng)險(xiǎn)很大。如果有誤操作或者在從節(jié)點(diǎn)路徑上亂寫(xiě)數(shù)據(jù)可能導(dǎo)致線上配置被覆蓋。ZooKeeper的ACL不像Linux文件權(quán)限那么簡(jiǎn)單它包含scheme、id和permission三層。我目前用的是digest認(rèn)證給節(jié)點(diǎn)設(shè)置用戶名密碼客戶端訪問(wèn)時(shí)必須攜帶認(rèn)證信息。雖然MultiDocker內(nèi)部的網(wǎng)絡(luò)環(huán)境相對(duì)可控但加上認(rèn)證至少能擋住誤操作和弱安全要求的臨時(shí)腳本訪問(wèn)。設(shè)置認(rèn)證的示例client.setACL().withACL(ZooDefs.Ids.CREATOR_ALL_ACL).forPath(/config);同時(shí)客戶端連接后要調(diào)用addAuthInfoclient.getZookeeperClient().getZooKeeper() .addAuthInfo(digest, admin:password.getBytes());ACL的好處是防止未授權(quán)客戶端亂寫(xiě)數(shù)據(jù)代價(jià)是每次連接多一步認(rèn)證但這對(duì)生產(chǎn)安全是有價(jià)值的。如果你所在團(tuán)隊(duì)安全要求比較高建議一開(kāi)始就按這套方式設(shè)計(jì)節(jié)點(diǎn)權(quán)限體系。作為Java開(kāi)發(fā)者在項(xiàng)目中落地ZooKeeper我從最開(kāi)始的只會(huì)寫(xiě)CRUD到后來(lái)能獨(dú)立完成分布式鎖、服務(wù)發(fā)現(xiàn)和配置中心整個(gè)過(guò)程中最大的體會(huì)是ZooKeeper的API并不難難的是把“節(jié)點(diǎn)類型 Watch事件”這兩個(gè)概念靈活組合出正確的解決方案。我在項(xiàng)目X里真正穩(wěn)定運(yùn)行之后才慢慢把之前踩過(guò)的坑變成團(tuán)隊(duì)內(nèi)部的排查手冊(cè)。最后分享一個(gè)小技巧排查ZooKeeper相關(guān)問(wèn)題時(shí)可以先用命令行客戶端連接上去手動(dòng)執(zhí)行g(shù)et和ls操作確認(rèn)數(shù)據(jù)狀態(tài)是否和預(yù)期一致再回頭查代碼邏輯這樣能快速縮小問(wèn)題范圍比直接翻代碼有效率得多。