如果你維護(hù)過基于 ZooKeeper 的配置中心大概率遇到過這種場景本地緩存里的配置已經(jīng)變了但內(nèi)存里還是舊值。加日志一看Watcher 事件確實(shí)觸發(fā)了可事件回調(diào)里重新getData拿到的數(shù)據(jù)又比預(yù)期慢半拍。我今年接手的一個(gè)老服務(wù)就是這副樣子代碼里散落著十幾個(gè)原生 Watcher每個(gè)都自己管理事件注冊、會(huì)話恢復(fù)和異常吞掉改了三次配置總有一兩次監(jiān)聽會(huì)掉線。所以我干脆花了兩個(gè)迭代把所有監(jiān)聽邏輯統(tǒng)一遷移到 Apache Curator 上順便把團(tuán)隊(duì)里的監(jiān)聽代碼規(guī)范成了一套模板。這篇文章就從原生 Watcher 的痛點(diǎn)開始講清楚 Curator 到底幫你解決了什么問題以及 NodeCache、PathChildrenCache、TreeCache、CuratorCache 在實(shí)現(xiàn) Watcher 機(jī)制時(shí)各自適合什么場景。很多人以為用了 Curator 就是把ZooKeeper客戶端換了個(gè)連接池其實(shí) Curator 至少在兩個(gè)層面影響了你的 Watcher 代碼第一它把連接狀態(tài)、重試和會(huì)話恢復(fù)做了統(tǒng)一管理第二它提供了緩存型監(jiān)聽器讓「監(jiān)聽事件 維護(hù)本地快照」這個(gè)動(dòng)作變成一件幾乎不用動(dòng)腦的事情。但如果你不理解底層為什么這么做照樣會(huì)在線上踩坑。下面按我的理解從頭拆開講。1. 原生 Watcher 的三塊硬傷一次性、會(huì)話綁定、手工重建1.1 “事件觸發(fā)完就要重新注冊”的這個(gè)窗口期ZooKeeper 原生 Watcher 是一次性的這一點(diǎn)是后面所有問題的根源。當(dāng)服務(wù)端檢測到節(jié)點(diǎn)數(shù)據(jù)變化它會(huì)生成一個(gè)WatchedEvent發(fā)給客戶端然后立刻把這個(gè) Watcher 從服務(wù)端移除。也就是說你收到的不是「以后每次變化都會(huì)通知你」而是「這次變化通知你一下下次你還得重新報(bào)名」。所以原生代碼幾乎都是下面這個(gè)套路Watcher watcher new Watcher() { Override public void process(WatchedEvent event) { if (event.getType() Event.EventType.NodeDataChanged) { try { // 這里必須重新注冊否則下次變化不會(huì)再通知 byte[] data zk.getData(event.getPath(), this, null); handleData(event.getPath(), data); } catch (Exception e) { // 典型的“誰注冊誰處理”邏輯散落各處 } } } }; zk.getData(/config/service, watcher, null);問題在于從事件觸發(fā)到你在process里重新調(diào)用getData之間存在一個(gè)無守護(hù)窗口期。這段時(shí)間里如果節(jié)點(diǎn)又發(fā)生了變更這次變更不會(huì)觸發(fā)任何 Watcher。如果你的事件回調(diào)邏輯是「收到事件后再去讀數(shù)據(jù)」那你最終讀到的是當(dāng)前最新值問題不大但如果你的業(yè)務(wù)邏輯是「每收到一次事件就累加一個(gè)本地計(jì)數(shù)」那多次變更折疊成一次事件計(jì)數(shù)一定會(huì)錯(cuò)。我曾經(jīng)給同事打過一個(gè)比方原生 Watcher 就像銀行柜臺(tái)的叫號(hào)單你取到一張?zhí)栔辉谀憬刑?hào)的那一刻有效等你辦完業(yè)務(wù)想繼續(xù)等下一個(gè)號(hào)必須重新取號(hào)。你取號(hào)之前的任何新號(hào)碼你都約不到。1.2 會(huì)話狀態(tài)、None 事件與節(jié)點(diǎn)消失之前原生 Watcher 還有一個(gè)很多人忽略的細(xì)節(jié)Watcher 不只是路徑綁定的它還是會(huì)話綁定的?？蛻舳藬嗑€重連Watcher 可能還在但 session 過期服務(wù)端會(huì)把這個(gè) session 上注冊的所有 Watcher 全部清掉。這時(shí)候你收到的不是NodeDataChanged而是一個(gè)EventType.None事件具體狀態(tài)可能是Disconnected、Expired或者SyncConnected。新手最容易犯的錯(cuò)是在全局Watcher.process里只處理NodeDataChanged遇到None事件就return完全不做狀態(tài)判斷。結(jié)果就是客戶端明明已經(jīng)斷線重連了重新注冊的getData又因?yàn)槁窂讲淮嬖趻伋鯪oNodeException整個(gè)監(jiān)聽鏈路就斷了。另外Watcher 事件本身不帶數(shù)據(jù)內(nèi)容它只告訴你「哪個(gè)路徑的哪種事件發(fā)生了」。如果你想知道當(dāng)前值必須重新發(fā)起一次讀操作。這意味著每一次事件通知背后都至少跟著一次網(wǎng)絡(luò)請求。當(dāng)節(jié)點(diǎn)很多、變更頻繁時(shí)這種「事件 重新讀」的模式會(huì)放大成不小的流量。1.3 手工重建 Watcher 的業(yè)務(wù)復(fù)雜度如果只是監(jiān)聽一個(gè)固定節(jié)點(diǎn)原生 Watcher 的代碼量還能忍。一旦你面對的是動(dòng)態(tài)節(jié)點(diǎn)列表比如注冊中心里的/services下面隨時(shí)有新實(shí)例上線、舊實(shí)例下線事情就完全失控了。你需要在getChildren上掛一個(gè) Watcher收到子節(jié)點(diǎn)變化后重新拉取子節(jié)點(diǎn)列表然后對每個(gè)新的子節(jié)點(diǎn)再掛一個(gè)getDataWatcher某個(gè)子節(jié)點(diǎn)刪除后還要手動(dòng)把對應(yīng) Watcher 摘掉。這個(gè)邏輯我跟你說任何手寫版本上線后都會(huì)漏要么漏了新增節(jié)點(diǎn)的數(shù)據(jù)監(jiān)聽要么漏了getChildren本身的重注冊。更麻煩的是這些代碼分散在業(yè)務(wù)類里排查問題時(shí)你根本不知道哪個(gè) Watcher 還活著。這也是為什么業(yè)內(nèi)幾乎所有基于 ZooKeeper 的框架都會(huì)把 Watcher 封裝成「緩存 監(jiān)聽回調(diào)」的形式。你先有一個(gè)本地快照再通過事件去刷新它而不是裸接事件流去還原狀態(tài)。2. Curator 連接層到底替你重寫了什么2.1 CuratorFramework 與 ZooKeeper 客戶端的關(guān)系A(chǔ)pache Curator 并沒有改 ZooKeeper 服務(wù)端協(xié)議它是在原生客戶端之上做了一層 Java API 封裝。Curator 的核心是CuratorFramework它把連接創(chuàng)建、重試策略、命名空間、后臺(tái)操作和狀態(tài)監(jiān)聽都收斂到一個(gè)對象里。dependency groupIdorg.apache.curator/groupId artifactIdcurator-recipes/artifactId version5.5.0/version /dependencyRetryPolicy retryPolicy new ExponentialBackoffRetry(1000, 3); CuratorFramework client CuratorFrameworkFactory.builder() .connectString(127.0.0.1:2181) .sessionTimeoutMs(60000) .retryPolicy(retryPolicy) .build(); client.start();有一個(gè)細(xì)節(jié)值得注意client.start()之后Curator 會(huì)啟動(dòng)自己的連接狀態(tài)管理器這跟 ZK 原生客戶端的addAuthInfo、register不是一回事。Curator 的重試策略會(huì)自動(dòng)處理瞬時(shí)網(wǎng)絡(luò)異常你不需要在每個(gè)getData外面包一層while(true)重試。對于 Watcher 機(jī)制來說最大的好處是你終于有了一個(gè)統(tǒng)一的、可靠的連接狀態(tài)回調(diào)入口。2.2 連接狀態(tài)監(jiān)聽器比原生 Watcher 更可靠Curator 提供了getConnectionStateListenable()你可以注冊一個(gè)ConnectionStateListener它會(huì)把連接狀態(tài)映射成幾個(gè)明確的狀態(tài)CONNECTED、SUSPENDED、RECONNECTED、LOST。client.getConnectionStateListenable().addListener((clientFramework, state) - { if (state ConnectionState.LOST) { // session 已失效本地緩存全部標(biāo)記不可信 localCache.clear(); } else if (state ConnectionState.RECONNECTED) { // 連接恢復(fù)了觸發(fā)一次全量補(bǔ)償 rebuildCache(); } });這個(gè)監(jiān)聽器解決了我前面說的「None 事件處理不統(tǒng)一」的痛點(diǎn)。你不需要在每個(gè)業(yè)務(wù) Watcher 里判斷連接狀態(tài)而是集中在一處處理。注意RECONNECTED并不保證 watch 一定還在因?yàn)?session 可能雖然沒有過期但之前的 Watcher 在斷線期間因?yàn)楦鞣N原因已經(jīng)失效所以我個(gè)人會(huì)把RECONNECTED當(dāng)作「需要補(bǔ)償一次數(shù)據(jù)」的信號(hào)而不是「一切恢復(fù)正?！沟男盘?hào)。2.3 usingWatcher、CuratorWatcher 和 watched() 的取舍即使換成 Curator如果你還是用最底層的usingWatcher寫監(jiān)聽本質(zhì)上沒有跳出原生 Watcher 的坑。Curator 提供CuratorWatcher接口只是幫你省掉了一些異常模板client.getData() .usingWatcher((CuratorWatcher) event - { // 這里依然要手動(dòng)重新注冊 client.getData().usingWatcher(this).forPath(event.getPath()); }) .forPath(/config/service);Curator 的讀操作 builder 上也有watched()這種簡便寫法但 Watcher 一次性觸發(fā)的語義沒有改變。我的判斷是如果你只需要一次性等待某個(gè)事件比如等一個(gè)臨時(shí)節(jié)點(diǎn)出現(xiàn)那用原生 Watcher 甚至usingWatcher都行如果要做長期監(jiān)聽并維護(hù)本地狀態(tài)請直接用 Curator 的緩存型監(jiān)聽器。這是遷移過程中最重要的一條分界線不要因?yàn)?Curator 好用就把回調(diào)式監(jiān)聽寫得到處都是。3. 用緩存型監(jiān)聽器替代裸 Watcher三類 Cache 的選擇與實(shí)現(xiàn)3.1 NodeCache監(jiān)控單節(jié)點(diǎn)數(shù)據(jù)變化NodeCache是 Curator 提供的最簡單緩存監(jiān)聽器。它監(jiān)聽一個(gè)固定節(jié)點(diǎn)的數(shù)據(jù)變化內(nèi)部替你完成了「事件觸發(fā) - 重新注冊 - 更新本地緩存」的循環(huán)。NodeCache nodeCache new NodeCache(client, /config/service); nodeCache.getListenable().addListener(() - { ChildData childData nodeCache.getCurrentData(); if (childData ! null) { String value new String(childData.getData(), StandardCharsets.UTF_8); localConfig.put(service, value); } else { localConfig.remove(service); } }); nodeCache.start();用NodeCache之后你再也不用關(guān)心「當(dāng)前節(jié)點(diǎn)是否存在」這件事了。節(jié)點(diǎn)被刪掉時(shí)getCurrentData()會(huì)返回null回調(diào)里自己判斷即可。最實(shí)用的一點(diǎn)是NodeCache會(huì)幫你處理NoNodeException節(jié)點(diǎn)被刪除后如果又重新創(chuàng)建它也能重新掛上監(jiān)聽。這個(gè)場景在配置中心里非常常見某個(gè)服務(wù)的配置項(xiàng)被運(yùn)維刪掉了后來又重建如果用手寫 Watcher重建后的數(shù)據(jù)十有八九會(huì)漏。3.2 PathChildrenCache子節(jié)點(diǎn)列表的動(dòng)態(tài)同步PathChildrenCache監(jiān)聽某個(gè)路徑下的直接子節(jié)點(diǎn)適合注冊中心、任務(wù)分組這類場景。它維護(hù)的是子節(jié)點(diǎn)列表和對應(yīng)數(shù)據(jù)事件類型分為CHILD_ADDED、CHILD_UPDATED、CHILD_REMOVED。PathChildrenCache childrenCache new PathChildrenCache(client, /services, true); childrenCache.getListenable().addListener((clientFramework, event) - { switch (event.getType()) { case CHILD_ADDED: case CHILD_UPDATED: case CHILD_REMOVED: ChildData data event.getData(); if (data ! null) { // data.getPath()、data.getData() 都有 refreshServiceList(); } break; default: break; } }); childrenCache.start(PathChildrenCache.StartMode.POST_INITIALIZED_EVENT);這里重點(diǎn)說下StartMode。NORMAL表示啟動(dòng)時(shí)就直接構(gòu)建緩存不發(fā)初始化事件BUILD_INITIAL_CACHE是啟動(dòng)時(shí)先構(gòu)建緩存再返回但監(jiān)聽器不會(huì)收到初始化的全量事件POST_INITIALIZED_EVENT會(huì)在初始數(shù)據(jù)構(gòu)建完成后發(fā)送一個(gè)INITIALIZED初始化事件方便你拿到「第一份可靠快照」后再對外提供服務(wù)。我強(qiáng)烈建議在需要對外提供服務(wù)的場景使用POST_INITIALIZED_EVENT。否則可能出現(xiàn)服務(wù)剛啟動(dòng)還沒拿到完整子節(jié)點(diǎn)列表就有請求進(jìn)來查詢查到一半數(shù)據(jù)。PathChildrenCache只監(jiān)聽直接子節(jié)點(diǎn)不會(huì)遞歸到孫節(jié)點(diǎn)這個(gè)邊界一定要記住。3.3 TreeCache整棵配置樹的遞歸監(jiān)聽如果配置是按目錄組織的比如/config/db、/config/cache、/config/feature/xxx用TreeCache最省事。它本質(zhì)上是整合了多層PathChildrenCache遞歸監(jiān)聽傳入路徑下的所有節(jié)點(diǎn)。TreeCache treeCache new TreeCache(client, /configTree); treeCache.getListenable().addListener((clientFramework, event) - { ChildData data event.getData(); if (data ! null) { System.out.println(event.getPath() - new String(data.getData(), StandardCharsets.UTF_8)); } }); treeCache.start();注意TreeCache的遞歸意味著它會(huì)給每個(gè)子節(jié)點(diǎn)都維護(hù)存儲(chǔ)和數(shù)據(jù)當(dāng)子樹很深、節(jié)點(diǎn)很多時(shí)內(nèi)存和事件量都會(huì)上漲。如果你只需要某幾層路徑別圖省事一把梭整棵樹否則后期一個(gè)/configTree/app1/env/prod/detail低頻變化都會(huì)引起整棵樹的緩存刷新任務(wù)。3.4 三張表的對比與我的默認(rèn)選擇緩存類型監(jiān)聽范圍典型場景主要注意點(diǎn)NodeCache單個(gè)節(jié)點(diǎn)單個(gè)配置項(xiàng)、開關(guān)、版本號(hào)節(jié)點(diǎn)刪除后返回 null業(yè)務(wù)側(cè)要處理PathChildrenCache直接子節(jié)點(diǎn)注冊中心、服務(wù)列表、分布式任務(wù)列表不遞歸孫節(jié)點(diǎn)TreeCache遞歸子樹配置中心、權(quán)限樹、規(guī)則目錄子樹規(guī)模會(huì)影響內(nèi)存和事件量我的默認(rèn)選擇很固定單點(diǎn)配置用NodeCache動(dòng)態(tài)列表用PathChildrenCache目錄樹配置用TreeCache或者下一節(jié)說的CuratorCache。如果你在猶豫用哪個(gè)先回答一個(gè)問題「我需要維護(hù)的本地視圖是單個(gè)值、一層列表還是一棵樹」回答完基本上就有答案了。4. CuratorCache比 TreeCache 更貼近需求的下一代方案4.1 為什么 TreeCache 會(huì)和事件堆積扯上關(guān)系Curator 官方在發(fā)展了幾年之后開始意識(shí)到 TreeCache 這類實(shí)現(xiàn)有一個(gè)結(jié)構(gòu)性痛點(diǎn)監(jiān)聽器回調(diào)線程和緩存內(nèi)部事件處理線程耦合在一起。當(dāng)業(yè)務(wù)回調(diào)里做了耗時(shí)操作比如寫數(shù)據(jù)庫、調(diào)遠(yuǎn)程接口內(nèi)部的事件消費(fèi)線程被拖住后面的事件就會(huì)堆積。ZooKeeper 的監(jiān)聽本質(zhì)上是高吞吐的輕量通知如果你把重邏輯直接塞在回調(diào)里高并發(fā)瞬間就能讓 Curator 內(nèi)部線程池打滿。另外TreeCache 畢竟是為了「緩存整棵樹」設(shè)計(jì)的如果你只是監(jiān)聽某個(gè)節(jié)點(diǎn)的變化卻要承擔(dān)整棵子樹的數(shù)據(jù)維護(hù)成本這個(gè)開銷不劃算。Curator 后來的新接口CuratorCache就是在這種背景下出現(xiàn)的它把「緩存數(shù)據(jù)」和「監(jiān)聽事件」解耦提供更細(xì)粒度的事件類型過濾也更方便配合獨(dú)立線程池。4.2 CuratorCache 與 CacheListener 的完整用法CuratorCache可以理解為覆蓋面更廣、設(shè)計(jì)更現(xiàn)代的緩存監(jiān)聽器?；A(chǔ)用法如下CuratorCache cache CuratorCache.build(client, /config/service); cache.listenable().addListener(new CuratorCacheListener() { Override public void event(Type type, ChildData oldData, ChildData data) { String path (data ! null) ? data.getPath() : oldData.getPath(); System.out.println(type - path); } }); cache.start();事件類型里有NODE_CREATED、NODE_CHANGED、NODE_DELETED、INITIALIZED等。和TreeCache相比CuratorCache更強(qiáng)調(diào)「你能明確知道自己想要哪些事件」。如果你只關(guān)心新增和刪除不關(guān)心數(shù)據(jù)內(nèi)容變化可以在監(jiān)聽器里直接過濾掉NODE_CHANGED從而減少很多無謂的回調(diào)次數(shù)。CuratorCache還有個(gè)關(guān)鍵改進(jìn)監(jiān)聽器可以掛到獨(dú)立的ExecutorService上。ExecutorService executor Executors.newFixedThreadPool(4); cache.listenable().addListener(listener, executor);這樣業(yè)務(wù)回調(diào)無論如何慢都不會(huì)阻塞 Curator 內(nèi)部處理 ZooKeeper 事件的線程。這比你把業(yè)務(wù)邏輯直接丟在默認(rèn)回調(diào)里要安全得多。需要提醒的是獨(dú)立線程池一方面解決了卡死問題另一方面也讓事件順序變得不可控如果業(yè)務(wù)上對順序有要求請?jiān)诨卣{(diào)里自己做好版本號(hào)比對不要假設(shè)線程池會(huì)按提交順序執(zhí)行。4.3 異步通知、緩存校驗(yàn)與性能調(diào)優(yōu)使用CuratorCache時(shí)我最常做的一件事是把事件當(dāng)作刷新提示而不是唯一數(shù)據(jù)源。也就是說本地緩存有一個(gè)全量快照收到事件后觸發(fā)一次補(bǔ)償刷新但在刷新完成之前服務(wù)可以繼續(xù)用舊的本地快照對外提供服務(wù)。這樣事件偶爾丟失也不會(huì)造成長時(shí)間不一致因?yàn)槟憧梢悦扛粢欢螘r(shí)間做一次定時(shí)全量對賬。性能調(diào)優(yōu)方面我一般關(guān)注兩點(diǎn)事件過濾只監(jiān)聽真正關(guān)注的事件類型減少回調(diào)次數(shù)。線程池大小如果CuratorCache監(jiān)聽量比較大建議專門命名一個(gè)線程池比如curator-cache-listener方便排查線程問題。如果你需要單節(jié)點(diǎn)模式可以在build時(shí)傳入Options相關(guān)參數(shù)不同版本的具體命名可能有差異建議看一眼當(dāng)前 Curator 版本的 javadoc。這個(gè) API 在 4.x 到 5.x 之間有調(diào)整不要拿著網(wǎng)上的舊代碼直接抄。5. 實(shí)際項(xiàng)目中監(jiān)聽不生效的定位鏈路三個(gè)事故復(fù)盤5.1 事故一監(jiān)聽回調(diào)里做數(shù)據(jù)庫操作導(dǎo)致 ZooKeeper 線程卡死當(dāng)時(shí)有個(gè)服務(wù)用PathChildrenCache監(jiān)聽任務(wù)列表回調(diào)里直接調(diào)用了數(shù)據(jù)庫批量刷新。上線后第一周沒問題到了高峰時(shí)段發(fā)現(xiàn)所有任務(wù)變更都延遲十幾分鐘才生效。查日志發(fā)現(xiàn) ZooKeeper 客戶端的 event thread 一直在等一個(gè)數(shù)據(jù)庫連接池的獲取操作而這個(gè)連接池本身已經(jīng)耗盡了。問題本質(zhì)不是 PathChildrenCache 不好而是我把業(yè)務(wù)重邏輯放到了默認(rèn)回調(diào)里。后來的修復(fù)很簡單給PathChildrenCache的getListenable().addListener(listener, executor)傳了一個(gè)單獨(dú)線程池把任務(wù)刷新丟進(jìn)去執(zhí)行。線程池內(nèi)部做降級(jí)如果任務(wù)積壓超過閾值直接丟棄舊的刷新請求只保留最新的一個(gè)。事故給我的經(jīng)驗(yàn)是監(jiān)聽回調(diào)是通知通道不是業(yè)務(wù)執(zhí)行通道。任何可能阻塞的操作都不要放在默認(rèn)回調(diào)里。5.2 事故二Session 過期后所有監(jiān)聽像被拔了線另一個(gè)服務(wù)因?yàn)?Full GC 停頓了 20 多秒ZooKeeper 客戶端 session 過期?；謴?fù)后發(fā)現(xiàn)配置中心推過來的變更完全不生效本地緩存一直是舊值。排查時(shí)先在ConnectionStateListener里打了日志發(fā)現(xiàn)狀態(tài)確實(shí)經(jīng)過了SUSPENDED到LOST但那段期間業(yè)務(wù)代碼沒有任何響應(yīng)。根因是session 過期后服務(wù)端把注冊的 Watcher 全部清空了而NodeCache內(nèi)部雖然會(huì)嘗試重建但如果應(yīng)用進(jìn)程在這個(gè)狀態(tài)下繼續(xù)對外服務(wù)它讀到的是已經(jīng)標(biāo)記為不可信的本地緩存。修復(fù)手段分兩層第一LOST狀態(tài)下直接把本地緩存標(biāo)記為「降級(jí)」拒絕外部讀取或者只讀舊值并打告警第二RECONNECTED后主動(dòng)全量刷新一次配置不要等下一個(gè)事件來補(bǔ)救。5.3 事故三TreeCache 事件丟失導(dǎo)致配置不同步這是我在使用TreeCache時(shí)遇到的比較隱蔽的問題。某次發(fā)布腳本在配置樹根路徑下創(chuàng)建了一個(gè)新分支TreeCache需要遞歸地為每個(gè)新節(jié)點(diǎn)掛監(jiān)聽但業(yè)務(wù)方在INITIALIZED事件到達(dá)之后立刻讀取了本地緩存此時(shí)新分支的數(shù)據(jù)還沒被完整構(gòu)建進(jìn)來結(jié)果讀到一半的值。嚴(yán)格來說這不完全是事件丟失而是初始化快照與應(yīng)用開始讀取之間存在時(shí)間差。TreeCache的INITIALIZED只代表「啟動(dòng)時(shí)已建立的初始緩存完成」不代表后續(xù)增量事件都已經(jīng)應(yīng)用完。對這種場景我的習(xí)慣是用CuratorCache里更細(xì)粒度的初始化事件配合版本號(hào)做二次確認(rèn)。生產(chǎn)環(huán)境里如果對一致性要求高不要在啟動(dòng)流程里賭「先收到初始化事件再讀緩存」而是顯式調(diào)用一次同步讀取。5.4 通用的監(jiān)聽健康檢查手段經(jīng)歷過上面幾個(gè)事故后我在每個(gè)項(xiàng)目里都會(huì)做三件固定動(dòng)作在監(jiān)聽器入口打結(jié)構(gòu)化日志包含事件類型、路徑、當(dāng)前節(jié)點(diǎn)數(shù)量至少能確認(rèn)事件在流動(dòng)。給本地緩存加一個(gè)lastRefreshTime指標(biāo)每次刷新更新它監(jiān)控這個(gè)指標(biāo)超過閾值直接告警。每個(gè)緩存型監(jiān)聽器都掛獨(dú)立線程池并給線程池命名這樣看線程 dump 時(shí)一眼就能區(qū)分是 ZooKeeper 內(nèi)部線程還是業(yè)務(wù)監(jiān)聽線程。這套組合拳打下來監(jiān)聽不生效的問題基本都能在 10 分鐘內(nèi)定位到而不是靠人肉對日志。6. 遷移到 Curator 之后我長期保留的幾條習(xí)慣如果讓我總結(jié)這幾輪改造后沉淀下來的習(xí)慣最重要的一條是不要試圖用 Curator 改變 ZooKeeper 的 Watcher 語義而是用緩存型監(jiān)聽器去規(guī)避它。原生 Watcher 的一次性觸發(fā)、會(huì)話綁定和事件不含數(shù)據(jù)這三個(gè)特性是所有上層框架都要面對的底層約束。Curator 的價(jià)值不是讓 Watcher 變得無限續(xù)杯而是讓你不再需要關(guān)心續(xù)杯這件事。我現(xiàn)在的代碼里已經(jīng)很少出現(xiàn)usingWatcher這種寫法了。新項(xiàng)目一律默認(rèn)CuratorCache老項(xiàng)目如果只是小改動(dòng)就按場景選NodeCache或PathChildrenCache。每個(gè)監(jiān)聽器都單獨(dú)命名線程池回調(diào)里只做內(nèi)存更新不碰數(shù)據(jù)庫、不碰遠(yuǎn)程調(diào)用。如果真的需要在事件里觸發(fā)重活我會(huì)把它丟進(jìn)消息隊(duì)列或者異步任務(wù)表讓監(jiān)聽器盡快返回。另外我養(yǎng)成了一個(gè)比較「笨」的習(xí)慣每個(gè)配置監(jiān)聽外面都會(huì)有一層定時(shí)對賬。比如一分鐘拉一次全量配置和本地緩存做 diff。有人覺得這樣重復(fù)但在我看來ZooKeeper Watcher 再可靠也只是一個(gè)異步通知機(jī)制異步通知在異常場景下一定會(huì)有盲區(qū)。定時(shí)對賬成本很低卻能兜住絕大多數(shù)事件丟失、線程阻塞、session 過期帶來的問題。從最原始的手寫 Watcher到 Curator 的連接層封裝再到 Cache 和 CuratorCache我最大的體會(huì)是分布式系統(tǒng)里「收到通知」和「狀態(tài)正確」完全是兩回事。抽象層能幫你省掉重復(fù)代碼但省不掉對業(yè)務(wù)數(shù)據(jù)一致性的思考。把監(jiān)聽器當(dāng)作通知的入口、把定時(shí)對賬當(dāng)作正確性的兜底這套組合在我維護(hù)過的服務(wù)里表現(xiàn)最穩(wěn)。