接手一個(gè)需要多服務(wù)協(xié)作的項(xiàng)目時(shí)我踩過的第一個(gè)大坑就是所有節(jié)點(diǎn)各干各的沒有一套統(tǒng)一的協(xié)調(diào)機(jī)制。后來我把ZooKeeper引入整個(gè)架構(gòu)先后解決了配置同步、服務(wù)上下線感知和分布式鎖這幾個(gè)最頭疼的問題。這篇文章就是我基于實(shí)際項(xiàng)目做的階段性總結(jié)寫給正在學(xué)Java分布式、并且準(zhǔn)備把ZooKeeper用起來的開發(fā)者尤其是那些剛看完理論、想知道怎么落地的朋友。我會(huì)從ZooKeeper的定位講起帶著你理解它的數(shù)據(jù)模型和會(huì)話機(jī)制然后給出Java客戶端選型的關(guān)鍵對(duì)比再手把手拆解節(jié)點(diǎn)CRUD、Watch監(jiān)聽、分布式鎖和服務(wù)發(fā)現(xiàn)這些高頻實(shí)戰(zhàn)場(chǎng)景最后聊幾個(gè)我親身踩過的坑。整個(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è)問題配置文件散落在各節(jié)點(diǎn)上、改了配置要一臺(tái)臺(tái)重啟、服務(wù)掛了其他調(diào)用方感知不到。這些問題的共性就是缺少一個(gè)可以讓所有節(jié)點(diǎn)共同依賴的協(xié)調(diào)者。1.1 沒有協(xié)調(diào)框架時(shí)的混亂場(chǎng)景舉個(gè)例子項(xiàng)目X里有三個(gè)服務(wù)需要共享一份DB開關(guān)配置。我最初的做法是把配置寫在每個(gè)服務(wù)本地的properties文件里運(yùn)維改配置時(shí)用腳本批量推送。聽起來簡(jiǎn)單但實(shí)際會(huì)發(fā)生兩種情況推送時(shí)部分節(jié)點(diǎn)成功、部分節(jié)點(diǎn)失敗失敗節(jié)點(diǎn)繼續(xù)跑舊邏輯新邏輯和舊邏輯并行。服務(wù)擴(kuò)容時(shí)新拉起來的機(jī)器如果配置文件不是最新版會(huì)帶著舊配置進(jìn)入生產(chǎn)環(huán)境。更麻煩的是分布式鎖。早期我用數(shù)據(jù)庫的唯一索引做鎖通過insert一條記錄來占用鎖最后delete釋放。在高并發(fā)下數(shù)據(jù)庫連接會(huì)被打滿而且鎖的續(xù)租、異常釋放、死鎖檢測(cè)全部要自己寫。后來我決定徹底改造用ZooKeeper把這些分散的麻煩事統(tǒng)一收攏。1.2 ZooKeeper到底替我們解決了什么問題ZooKeeper在架構(gòu)里扮演的角色簡(jiǎn)單說就是一個(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)用方通過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é)議保證了寫入順序的一致性和高可用。集群內(nèi)部通過選舉產(chǎn)生Leader所有寫請(qǐng)求都交給Leader廣播給Follower超過半數(shù)確認(rèn)后返回成功保證數(shù)據(jù)不會(huì)因?yàn)楣?jié)點(diǎn)故障而分叉。1.3 它不是萬能存儲(chǔ)適用邊界要先劃清楚我在團(tuán)隊(duì)內(nèi)部做技術(shù)分享時(shí)總強(qiáng)調(diào)一句話不要把ZooKeeper當(dāng)數(shù)據(jù)庫用。它默認(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ù)超過幾十KB就要停下來想想是不是設(shè)計(jì)有問題。ZooKeeper的強(qiáng)順序一致性也是有時(shí)機(jī)代價(jià)的寫請(qǐng)求需要多數(shù)派確認(rèn)所以吞吐量跟Redis沒法比。業(yè)務(wù)向的高頻寫操作建議放RedisZooKeeper只做協(xié)調(diào)類數(shù)據(jù)。把邊界劃清楚后面用起來才不別扭。2. 數(shù)據(jù)模型與會(huì)話機(jī)制入門ZooKeeper前必須搞懂的四個(gè)核心概念跳過這些底層概念直接寫代碼很容易遇到各種摸不著頭腦的問題。我見過不少同事在寫節(jié)點(diǎn)操作時(shí)搞不清持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)的區(qū)別結(jié)果服務(wù)重啟后舊節(jié)點(diǎn)還掛在線上服務(wù)注冊(cè)信息一直重復(fù)。所以我想先把四個(gè)核心概念講透。2.1 樹形數(shù)據(jù)模型ZNode不是傳統(tǒng)的文件ZooKeeper的命名空間是一棵類似文件系統(tǒng)的樹每個(gè)節(jié)點(diǎn)叫ZNode。路徑比如 /config、/config/db_switch寫法上和Linux目錄一樣訪問某個(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)來實(shí)現(xiàn)類似樂觀鎖的機(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)客戶端斷開后節(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ì)列我最初用過持久節(jié)點(diǎn)做服務(wù)注冊(cè)結(jié)果服務(wù)宕機(jī)后節(jié)點(diǎn)不會(huì)消失手動(dòng)清理又容易出錯(cuò)。后來改成臨時(shí)節(jié)點(diǎn)服務(wù)進(jìn)程退出、會(huì)話斷開節(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)連接。客戶端通過發(fā)送心跳請(qǐng)求來?；罘?wù)端在會(huì)話超時(shí)時(shí)間內(nèi)收到心跳會(huì)話就保持有效超過時(shí)間還沒收到會(huì)話過期臨時(shí)節(jié)點(diǎn)隨之被清理。Java操作時(shí)我一般配置會(huì)話超時(shí)時(shí)間為3000到5000毫秒這個(gè)值既不能太大也不能太小。太大會(huì)話過期識(shí)別慢臨時(shí)節(jié)點(diǎn)殘留時(shí)間久太小網(wǎng)絡(luò)抖動(dòng)就會(huì)導(dǎo)致會(huì)話誤判超時(shí)服務(wù)頻繁掉線。再配合客戶端自動(dòng)重連機(jī)制即使網(wǎng)絡(luò)短暫異常原來創(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í)用也最容易寫錯(cuò)的機(jī)制。客戶端可以對(duì)某個(gè)事務(wù)操作注冊(cè)監(jiān)聽比如節(jié)點(diǎn)數(shù)據(jù)變化、子節(jié)點(diǎn)列表變化、節(jié)點(diǎn)刪除只要事件發(fā)生客戶端會(huì)收到一次通知。注意是“一次”因?yàn)槊看瓮ㄖ曛蟊O(jiān)聽就失效了想繼續(xù)監(jiān)聽必須重新注冊(cè)。這個(gè)一次性規(guī)則讓很多初學(xué)者困惑為什么第一次修改配置能收到通知第二次就不行原因就是沒做再次注冊(cè)。后面的代碼示例里我會(huì)專門封裝一個(gè)帶循環(huán)注冊(cè)的工具類把每次收到通知后重新設(shè)置Watch這個(gè)動(dòng)作固化進(jìn)去。3. 客戶端選型原生API、ZkClient與Curator的取舍Java操作ZooKeeper時(shí)選型直接影響開發(fā)效率和后期維護(hù)。我在這部分有比較明確的答案但為了讓你做技術(shù)決策時(shí)有依據(jù)我先把三種方案的實(shí)際體驗(yàn)都列出來。3.1 三種客戶端方案的橫向?qū)Ρ染S度原生ZooKeeper APIZkClientCurator依賴程度JDK自帶輕量封裝完整框架Watch處理手動(dòng)循環(huán)注冊(cè)自動(dòng)監(jiān)聽自動(dòng)監(jiān)聽重連機(jī)制需自己實(shí)現(xiàn)簡(jiǎn)單封裝完善分布式鎖需要手寫需要手寫內(nèi)置實(shí)現(xiàn)維護(hù)活躍度保持更新基本停滯活躍學(xué)習(xí)曲線較陡平滑中間原生API最大的問題不是功能不夠而是重復(fù)代碼太多。每次操作都要處理連接狀態(tài)、重連邏輯、Watch重新注冊(cè)這些都是極其容易出錯(cuò)的邊角料。ZkClient曾經(jīng)流行過一段但封裝程度有限遇到復(fù)雜會(huì)話事件處理比較吃力。如果你問我現(xiàn)在的建議我會(huì)直接推薦Curator它在國(guó)內(nèi)項(xiàng)目里已經(jīng)積累了足夠的驗(yàn)證文檔也相對(duì)齊全。3.2 為什么我建議直接上CuratorCurator把ZooKeeper客戶端做成了可以開箱即用的框架提供了連接狀態(tài)監(jiān)聽、自動(dòng)重連、Watch管理器還內(nèi)置了InterProcessMutex這類分布式鎖實(shí)現(xiàn)。引入Curator之后代碼量對(duì)比原生API至少減少一半同時(shí)可讀性和健壯性明顯提升。當(dāng)然這不意味著原生API不值得學(xué)。我建議你先把原生API的基本操作跑一遍理解它怎么建立連接、怎么注冊(cè)Watch、怎么處理回調(diào)然后切到Curator你會(huì)更清楚框架替你做了什么遇到問題時(shí)也能定位到ZooKeeper底層還是框架封裝層。這種學(xué)習(xí)路徑比直接上手Curator更扎實(shí)。3.3 環(huán)境準(zhǔn)備單機(jī)部署和偽集群搭建本地開發(fā)時(shí)單機(jī)模式就夠用。下載解壓后修改配置文件zoo.cfg設(shè)置dataDir和clientPort默認(rèn)2181端口然后執(zhí)行啟動(dòng)腳本。確認(rèn)啟動(dòng)成功的命令是連接2181端口并輸入stat能看到ZooKeeper版本信息就說明通了。如果需要模擬生產(chǎn)環(huán)境的故障轉(zhuǎn)移我建議用偽集群模式也就是在同一臺(tái)機(jī)器上跑三個(gè)ZooKeeper實(shí)例。三個(gè)實(shí)例分別監(jiān)聽2181、2182、2183端口dataDir也分成三份并且在每個(gè)實(shí)例的data目錄中都要新建myid文件內(nèi)容分別是1、2、3。配置文件里通過server.1127.0.0.1:2888:3888這樣的格式聲明集群成員。偽集群能驗(yàn)證選舉和會(huì)話轉(zhuǎn)移對(duì)理解ZooKeeper高可用機(jī)制幫助很大。4. 手寫Java操作ZooKeeper從連接、CRUD到Watch監(jiān)聽這一章是實(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官方客戶端依賴。不過下文除了最基礎(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)聽循環(huán)Watch是ZooKeeper最核心的機(jī)制代碼也最容易出錯(cuò)。原生API的寫法是注冊(cè)Watcher但一次觸發(fā)后失效所以要在回調(diào)里再次注冊(cè)。下面是封裝好的循環(huán)監(jiān)聽工具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)聽監(jiān)聽的事件是節(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)聽 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)聽。漏掉這一步監(jiān)聽只會(huì)觸發(fā)一次。我在項(xiàng)目里看到過很多次這個(gè)問題造成的現(xiàn)象是配置第一次修改生效以后再也收不到通知。用Curator時(shí)可以借助CuratorCache或者NodeCache來簡(jiǎn)化監(jiān)聽邏輯。NodeCache在節(jié)點(diǎn)數(shù)據(jù)變化時(shí)觸發(fā)支持再次監(jiān)聽不需要手動(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àng)目X時(shí)我統(tǒng)一用JSON字符串把配置項(xiàng)封裝成對(duì)象后序列化存儲(chǔ)到節(jié)點(diǎn)里。讀取時(shí)再反序列化回對(duì)象。如果直接用Java原生序列化雖然類實(shí)現(xiàn)了Serializable就能存但跨語言調(diào)用會(huì)很痛苦而且序列化內(nèi)容體積大浪費(fèi)ZooKeeper有限的存儲(chǔ)空間。所以我的建議是存量小字段直接用字符串比如開關(guān)狀態(tài)寫on/off。結(jié)構(gòu)化成組配置用JSON字符串。切勿存大對(duì)象或大數(shù)組。深度思考一下ZooKeeper節(jié)點(diǎn)的數(shù)據(jù)是給所有客戶端看的用通用的JSON格式意味著不同語言的服務(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)景完整說明設(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ù)庫鎖后來切到ZooKeeper后穩(wěn)定很多。原理很簡(jiǎn)單多個(gè)客戶端在同一個(gè)鎖路徑下創(chuàng)建臨時(shí)順序節(jié)點(diǎn)序號(hào)最小的獲得鎖其他客戶端監(jiān)聽序號(hào)比自己小的節(jié)點(diǎn)等它刪除后再嘗試獲得鎖。用Curator內(nèi)置的InterProcessMutex代碼幾乎沒有門檻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í)間超過則放棄避免線程長(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ù)庫鎖穩(wěn)的原因之一。如果不用Curator也可以基于原生API自己實(shí)現(xiàn)分布式鎖核心代碼邏輯是創(chuàng)建臨時(shí)順序節(jié)點(diǎn)然后獲取父節(jié)點(diǎn)下所有子節(jié)點(diǎn)列表判斷自己序號(hào)是否最小。不過這部分代碼要處理監(jiān)聽和重試細(xì)節(jié)我強(qiáng)烈建議直接用InterProcessMutex。5.2 服務(wù)注冊(cè)與發(fā)現(xiàn)沒有注冊(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)聽 /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)聽工具啟動(dòng)后監(jiān)聽子節(jié)點(diǎn)新增、刪除、數(shù)據(jù)修改。服務(wù)上下線時(shí)監(jiān)聽回調(diào)會(huì)收到事件客戶端就可以更新本地服務(wù)列表。配合臨時(shí)節(jié)點(diǎn)能夠?qū)崿F(xiàn)服務(wù)宕機(jī)自動(dòng)摘除整個(gè)過程不需要人工介入。5.3 配置中心動(dòng)態(tài)下發(fā)與App內(nèi)熱更新配置中心是ZooKeeper比較容易上手的場(chǎng)景。我把項(xiàng)目X的數(shù)據(jù)庫連接池參數(shù)、功能開關(guān)、限流閾值全部放到了 /config 路徑下每個(gè)子節(jié)點(diǎn)對(duì)應(yīng)一個(gè)配置項(xiàng)。服務(wù)啟動(dòng)時(shí)讀取一次然后注冊(cè)監(jiān)聽配置更新后應(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ù)庫連接池 dataSource.setMaxActive(Integer.parseInt(maxActive)); // 啟動(dòng)監(jiān)聽后續(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è)路徑下方便管理還要為沒有經(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)聽事件”的二元組。翻譯對(duì)了代碼只是時(shí)間問題。6. 生產(chǎn)環(huán)境必須面對(duì)的幾個(gè)硬骨頭把ZooKeeper放到生產(chǎn)環(huán)境之前有幾個(gè)問題必須提前想清楚。我在項(xiàng)目X推進(jìn)的過程中就踩過不少坑這里挑影響最大的幾個(gè)說。6.1 會(huì)話超時(shí)與心跳假死ZooKeeper客戶端會(huì)話超時(shí)機(jī)制是它高可用的基礎(chǔ)但也容易造成假死?，F(xiàn)象是服務(wù)進(jìn)程還在但ZooKeeper服務(wù)端判斷會(huì)話過期把臨時(shí)節(jié)點(diǎn)清掉了其他客戶端看到你的服務(wù)已經(jīng)下線實(shí)際你的進(jìn)程還在運(yùn)行。我遇到過一次比較典型的情況某服務(wù)因?yàn)镕ull GC暫停了幾秒心跳沒發(fā)出去ZooKeeper判定會(huì)話超時(shí)把臨時(shí)節(jié)點(diǎn)刪了。Full GC恢復(fù)后服務(wù)還在處理業(yè)務(wù)下游已經(jīng)把流量切走了。這個(gè)問題靠代碼很難完全規(guī)避但可以通過調(diào)大sessionTimeout來降低誤判概率。我線上一般設(shè)sessionTimeoutMs為10秒比本地開發(fā)時(shí)大不少。處理方式是在客戶端加上ConnectionStateListener監(jiān)聽會(huì)話的重連和過期事件。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)重問題。如果幾百個(gè)客戶端對(duì)同一個(gè)父節(jié)點(diǎn)注冊(cè)子節(jié)點(diǎn)監(jiān)聽那么這個(gè)節(jié)點(diǎn)一變化幾百個(gè)客戶端全部被打醒同時(shí)執(zhí)行后續(xù)邏輯這就是Watch風(fēng)暴。我在項(xiàng)目X早期犯過這個(gè)錯(cuò)誤所有服務(wù)實(shí)例都在監(jiān)聽同一個(gè)服務(wù)列表節(jié)點(diǎn)導(dǎo)致服務(wù)上下線時(shí)通知量爆炸。優(yōu)化方案是把監(jiān)聽改為客戶端主動(dòng)輪詢或者說改變數(shù)據(jù)組織方式讓每個(gè)客戶端只關(guān)心自己需要的那部分節(jié)點(diǎn)。比如把子節(jié)點(diǎn)按租戶分隔客戶端只監(jiān)聽自己租戶的路徑。這個(gè)調(diào)整之后通知量降了一個(gè)數(shù)量級(jí)效果立竿見影。另外就是重復(fù)注冊(cè)的坑。在緩存框架里一個(gè)節(jié)點(diǎn)被多個(gè)模塊同時(shí)監(jiān)聽很容易產(chǎn)生重復(fù)的Watcher。釋放節(jié)點(diǎn)緩存時(shí)必須調(diào)用close清理監(jiān)聽否則舊監(jiān)聽會(huì)一直駐留不僅浪費(fèi)內(nèi)存還會(huì)造成重復(fù)通知。6.3 單機(jī)模式的坑與集群容錯(cuò)本地開發(fā)用單機(jī)模式?jīng)]問題但生產(chǎn)環(huá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)限所有人都能讀寫。在開發(fā)環(huán)境可以容忍但生產(chǎn)環(huán)境這樣做風(fēng)險(xiǎn)很大。如果有誤操作或者在從節(jié)點(diǎn)路徑上亂寫數(shù)據(jù)可能導(dǎo)致線上配置被覆蓋。ZooKeeper的ACL不像Linux文件權(quán)限那么簡(jiǎn)單它包含scheme、id和permission三層。我目前用的是digest認(rèn)證給節(jié)點(diǎn)設(shè)置用戶名密碼客戶端訪問時(shí)必須攜帶認(rèn)證信息。雖然MultiDocker內(nèi)部的網(wǎng)絡(luò)環(huán)境相對(duì)可控但加上認(rèn)證至少能擋住誤操作和弱安全要求的臨時(shí)腳本訪問。設(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)客戶端亂寫數(shù)據(jù)代價(jià)是每次連接多一步認(rèn)證但這對(duì)生產(chǎn)安全是有價(jià)值的。如果你所在團(tuán)隊(duì)安全要求比較高建議一開始就按這套方式設(shè)計(jì)節(jié)點(diǎn)權(quán)限體系。作為Java開發(fā)者在項(xiàng)目中落地ZooKeeper我從最開始的只會(huì)寫CRUD到后來能獨(dú)立完成分布式鎖、服務(wù)發(fā)現(xiàn)和配置中心整個(gè)過程中最大的體會(huì)是ZooKeeper的API并不難難的是把“節(jié)點(diǎn)類型 Watch事件”這兩個(gè)概念靈活組合出正確的解決方案。我在項(xiàng)目X里真正穩(wěn)定運(yùn)行之后才慢慢把之前踩過的坑變成團(tuán)隊(duì)內(nèi)部的排查手冊(cè)。最后分享一個(gè)小技巧排查ZooKeeper相關(guān)問題時(shí)可以先用命令行客戶端連接上去手動(dòng)執(zhí)行g(shù)et和ls操作確認(rèn)數(shù)據(jù)狀態(tài)是否和預(yù)期一致再回頭查代碼邏輯這樣能快速縮小問題范圍比直接翻代碼有效率得多。