Dubbo 中 Zookeeper 註冊中心原理分析
vivo 互聯網服務器團隊- Li Wanghong
本文通過分析Dubbo中ZooKeeper註冊中心的實現ZooKeeperResitry的繼承體系結構，自頂向下分析了AbstractRegistry（提供了服務數據的本地緩存）、FailbackRegistry（服務註冊訂閲相關的異常重試）、CacheableFailbackRegistry（Dubbo在URL推送模型做的優化）、ZooKeeperRegistry（ZooKeeper註冊中心實現原理）的源碼，詳細介紹了Dubbo中ZooKeeper註冊中心的實現原理。
當服務提供者啟動時，服務提供者將自己提供的服務信息註冊到註冊中心，註冊中心將這些信息記錄下來。服務消費者啟動時，向註冊中心發起訂閲，將自己感興趣的服務提供者的信息拉取到本地並緩存起來，用於後續遠程調用。另外，註冊中心能夠感知到服務提供者新增或者下線，並更新自己的服務信息，同時通知服務消費者告知服務提供者新增/下線，從而消費者也可以動態感知到服務提供者的變化。
一、ZooKeeper註冊中心
ZooKeeper 是 Apache 的頂級項目。ZooKeeper 為分佈式應用提供了高效且可靠的分佈式協調服務，提供了諸如統一命名服務、配置管理和分佈式鎖等分佈式的基礎服務。在解決分佈式數據一致性方面，ZooKeeper 並沒有直接採用 Paxos 算法，而是採用了名為 ZAB 的一致性協議。
1.1 ZooKeeper數據結構
ZooKeeper 的數據模型是一個樹形結構的文件系統。Dubbo服務在ZooKeeper中的數據結構（舊版模型，Dubbo2.7版本後路由數據、配置數據不再寫到該目錄下）如下圖所示。
ZooKeeper中的節點分為持久節點、持久順序節點、臨時節點、臨時順序節點。Dubbo使用ZooKeeper作為註冊中心時，不關心節點的創建順序，只會創建持久節點和臨時節點。
-
持久節點： 服務註冊後保證節點不會丟失，註冊中心重啟也會存在 。
-
臨時節點： 服務註冊後連接丟失或session超時，註冊的節點會自動被移除 。
1.2 ZooKeeper的Watcher機制
客户端和服務器維持數據交互通常有兩種形式：
-
客户端定時向服務器輪詢
-
服務器主動向客户端推送數據
ZooKeeper採用的是方式2，主動向客户端推送數據。客户端註冊監聽它關心的節點（註冊Watcher監聽指定節點），當節點狀態發生變化（數據變化、子節點增減變化）時，則相應的Watcher被觸發，ZooKeeper 服務會通知客户端，這就是Watcher機制。
Watcher有以下特點：
-
主動推送：Watcher被觸發時，由ZooKeeper主動將更新推送給客户端，而不需要客户端輪詢。
-
一次性：在節點上註冊Watcher監聽後，當節點狀態發生變化時該Watcher只會被觸發一次，如果客户端想再收到後續發生變化的通知，需要重新再註冊一次Watcher。
-
可見性：如果一個客户端在讀請求中附帶 Watcher，Watcher 被觸發的同時再次讀取數據，客户端在得到 Watcher 消息之前肯定不可能看到更新後的數據。換句話説，更新通知先於更新結果。
-
順序性：如果多個更新觸發了多個 Watcher ，那 Watcher 被觸發的順序與更新順序一致。
1.3 ZooKeeper會話機制
ZooKeeper 客户端通過 TCP 長連接連接到 ZooKeeper 服務集羣。會話 (Session) 從第一次連接開始就已經建立，之後通過心跳檢測機制來保持有效的會話狀態。通過這個連接，客户端可以發送請求並接收響應，同時也可以接收到 Watch 事件的通知。一旦一台客户端與一台服務器建立連接，這台服務器會為這個客户端創建一個新的會話。
每個會話都會有一個超時時間。若由於服務器壓力過大、網絡故障等各種原因導致客户端連接斷開時，只要在會話超時時間之內能夠重新連接上ZooKeeper服務器，那麼之前創建的會話仍然有效。若服務器在超時時間內沒有收到任何請求，則相應會話被視為過期。一旦會話過期，就無法再重新打開，且任何與該會話相關的臨時 節點都會被刪除。
通常來説，會話應該長期存在，而這需要由客户端來保證。客户端可以通過心跳方式來保持會話不過期。
1.4 使用ZooKeeper作為註冊中心
如下圖所示，服務提供者（集成了ZK客户端）在服務啟動時，會通過ZK客户端與ZK服務端建立連接，將服務提供者信息（提供者的IP地址、端口、服務接口信息等）註冊到ZooKeeper服務端，這時會在ZooKeeper服務端生成一個臨時節點來存儲這些服務信息，這就是服務提供者的註冊操作。
服務消費者（集成了ZK客户端）在服務啟動時，會通過ZK客户端與ZK服務端建立連接，拉取自己感興趣的服務提供者信息並緩存到本地，同時也會對自己感興趣的節點（比如服務提供節點）註冊Watcher監聽。後續發起遠程調用時，會從本地緩存的服務提供者信息通過負載均衡等策略選擇一台服務提供者發起服務調用。
如果服務提供者擴容新增了機器，服務提供者會向ZK發起新的註冊操作，在對應的目錄下創建臨時節點（代表這台新增的服務提供者信息），同時會觸發之前服務消費者註冊的Watcher監聽，ZooKeeper服務端會將變更信息推送到服務消費，服務消費者在接收到變更後會更新自己本地的服務提供者信息，這樣就完成了服務的自動擴容。同樣的，當某台服務提供者下線，它與ZooKeeper服務端的連接會斷掉，因為服務註冊時創建的是臨時節點，因此當連接斷掉後，該臨時節點會被刪除，同時會觸發之前服務消費者註冊的Watcher監聽，相應的服務消費者會收到通知刷新自己本地的服務提供者信息緩存。
二、源碼分析
Node，Dubbo中用Node來表示抽象節點，Dubbo中的核心概念Registry、Invoker等都實現了接口Node。
RegistryService定義了註冊服務需要提供的基本能力，即增刪改查。Registry接口繼承了Node和Registry接口，它表示擁有註冊中心能力的節點。其中定義了4個默認方法，其中的reExportRegister和reExportUnRegiser方法都是委託給RegisterService的相應方法。
AbstractRegistry實現了Registry接口中的方法，它在內存中實現了註冊數據的讀寫改動，實現了本地緩存的功能。
FailbackRegistry繼承了AbstractRegistry，結合時間輪，提供了失敗重試的能力。
CacheableFailbackRegistry針對URL推送模型做了優化，減少了URL的創建。
ZooKeeperRegistry提供了基於ZooKeeper的註冊中心實現。
下面重點分析AbstractRegistry、FailbackRegistry、CacheableFailbackRegistry和ZooKeeperRegistry。
2.1 AbstractRegistry
AbstractRegistry實現了Registry接口中的方法，它在內存中實現了註冊數據的讀寫改動，從而可以就降低註冊中心的壓力。從前文繼承體系結構可以看出，Dubbo中的註冊中心實現都繼承了該類。
AbstractRegistry的核心是通過Properties類型的properties與File類型的file字段來記錄服務數據。properties基於內存存儲了服務相關的數據，file則對應磁盤文件，兩者的數據是同步的。在創建AbstractRegistry對象時，會根據傳入的URL中的file.cache參數來決定是否開啟本地緩存，默認開啟。
如果開啟，會將磁盤文件file中的數據加載到properties當中。當properties中的數據發生變化時，會同步到磁盤文件file中。如果傳入的URL的save.file參數為false（默認是false），會通過線程池來異步同步properties的數據到file，如果是true則是在當前線程同步。
2.2 FailbackRegistry
FailbackRegistry處理的是註冊中心相關的邏輯處理異常時如何處理，它會使用時間輪來處理異常重試。像ZooKeeperRegistry、NacosRegistry等註冊中心實現，都繼承了FailbackRegistry，因此也都有了異常重試的能力。
FailbackRegistry繼承了AbstractRegistry，複寫了register/unregister、subscribe/unsubscribe、notify這5個核心方法，在這些方法中首先會調用父類AbstractRegistry對應的方法，然後真正的註冊訂閲等邏輯還是通過模板方法模式委託給了子類實現，重試邏輯則交由時間輪來處理。
2.2.1 核心字段
FailbackRegistry的核心字段如下：
1）ConcurrentMap < URL,FailedRegisteredTask > failedRegistered，註冊失敗的URL集合。key是註冊失敗的URL，value是FailedRegisteredTask，也就是重試註冊時要執行的邏輯，該註冊重試邏輯會交給時間輪執行。當註冊失敗時，會調用方法addFailedRegistered添加註冊失敗的URL。
2）ConcurrentMap < URL,FailedUnregisteredTask > failedUnregistered，取消註冊時發生失敗的URL集合。key是取消註冊失敗的URL，value是FailedUnregisteredTask，也就是重試取消註冊時要執行的邏輯。
3）ConcurrentMap < Holder,FailedSubscribedTask > failedSubscribed，訂閲失敗的URL集合。key是Holder（封裝了訂閲失敗的URL以及對應的監聽器NotifyListener）,value是FailedSubscribedTask，也就是重試訂閲時要執行的邏輯。
4）ConcurrentMap < Holder,FailedUnsubscribedTask >failedUnsubscribed，取消訂閲發生失敗的URL集合。key是Holder（封裝了取消訂閲失敗的URL以及對應的監聽器NotifyListener），value是FailedUnsubscribedTask，也就是重試取消訂閲時要執行的邏輯。
5）int retryPeriod，重試操作時間間隔。
6）HashedWheelTimer retryTimer，時間輪，用於執行重試操作。
2.2.2 核心方法
以subscribe為例來分析FailbackRegistry中是如何處理重試的（其餘方法類似）。如下圖所示，首先FailbackRegistry的subscribe方法會調用父類AbstractRegistry的subcribe方法，將訂閲數據添加到內存中進行維護，接着會從訂閲失敗/取消訂閲失敗的集合中移除該URL相關的訂閲數據。
然後調用子類的doSubscribe方法將真正的訂閲邏輯交給子類實現，這是典型的模板方法設計模式。如果發生異常，會調用getCacheUrls方法獲取緩存的服務提供者數據。如果緩存的服務數據非空，因為這邊訂閲失敗了，所以需要手動觸發下notify方法，回調相關的NotifyListener方法，刷新消費者本地的服務提供者列表、路由、配置的數據。如果緩存數據為空，則需要判斷下，是否檢測訂閲失敗以及訂閲失敗的異常是否可以跳過，根據這個來判斷是否需要拋出異常還是忽略僅打印日誌。
最後會調用addFailedSubscribed方法將訂閲失敗的信息添加到failedSubscribed集合，以及將任務添加到時間輪中，這樣當時間到了，時間輪就可以處理該重試任務了。
這邊有一點需要注意，如果任務已經存在failedSubscribed集合中，就不需要重複添加了。failedSubscribed是Map結構，通過key來判斷數據是否存在，因此這邊的Holder作為key時，需要複寫hashCode和equals方法。
@Override
public void subscribe(URL url, NotifyListener listener) {
// 調用父類方法, 在內存中記錄下訂閲相關的數據
super.subscribe(url, listener);
// 從訂閲失敗集合、取消訂閲失敗集合中移除該URL相關的數據, 如果存在需要取消相關任務的執行
removeFailedSubscribed(url, listener);
try {
// 模板方法設計模式, 委託給子類實現真正的訂閲邏輯
doSubscribe(url, listener);
} catch (Exception e) {
Throwable t = e;
// 訂閲發生了異常, 則使用本地緩存的服務提供者數據
List<URL> urls = getCacheUrls(url);
if (CollectionUtils.isNotEmpty(urls)) {
// 調用notify方法回調相關的listener方法, 通知消費者刷新自己本地
// 的服務提供者、路由、配置等數據
notify(url, listener, urls);
} else {
// 根據check以及是否是可忽略的異常來判斷是否需要拋出異常
boolean check = getUrl().getParameter(Constants.CHECK_KEY, true)
&& url.getParameter(Constants.CHECK_KEY, true);
boolean skipFailback = t instanceof SkipFailbackWrapperException;
if (check || skipFailback) {
if (skipFailback) {
t = t.getCause();
}
// 拋異常
} else {
// 僅打印錯誤日誌
}
}
// 添加訂閲失敗的URL信息
addFailedSubscribed(url, listener);
}
}protected void addFailedSubscribed(URL url, NotifyListener listener) {
// 封裝成Holder
Holder h = new Holder(url, listener);
// 判斷該Holder是否已經存在, 如果已經存在則直接返回, 不需要多次添加
FailedSubscribedTask oldOne = failedSubscribed.get(h);
if (oldOne != null) {
return;
}
// 創建訂閲失敗的重試任務
FailedSubscribedTask newTask = new FailedSubscribedTask(url, this, listener);
// 向訂閲失敗的集合裏面添加該任務, 如果返回null説明之前不存在該任務,
// 這次需要往時間輪中註冊該任務
oldOne = failedSubscribed.putIfAbsent(h, newTask);
if (oldOne == null) {
// 將該任務添加到時間輪中
retryTimer.newTimeout(newTask, retryPeriod, TimeUnit.MILLISECONDS);
}
}2.3 CacheableFailbackRegistry
在2.7.8版本中並沒有CacheableFailbackRegistry這個類。在Dubbo3.0中，針對服務數據的推送做了一系列的優化，CacheableFailbackRegistry正是其中一個改動，下面來進行具體的講解。
2.3.1 URL推送模型
下圖所示是Dubbo2.7.8中的URL推送模型，消費者啟動後會向ZooKeeper服務端訂閲感興趣的服務，當有新的消費者感興趣的服務提供者節點（提供者3）加入服務時，該服務（提供者3）會把自己的服務信息註冊到ZooKeeper服務端，接着ZooKeeper服務端會把providers節點下的所有服務實例信息（提供者1、2、3）全量推送給消費者，消費者收到後根據推送的數據全量生成URL列表，該URL列表後續會被消費者用來構建自己本地的可選的服務提供者列表數據，後續發起遠程調用時，就可以從該服務提供者列表中選擇一個節點。
可以看到，當服務提供者實例數量較小時，推送的數據量較小，消費者端構建URL的壓力就小一些，但是當某個接口有大量的服務提供者時，當發生服務擴容/縮容，就會有大量的URL被創建。Dubbo3.0中的對該URL推送模型做了一系列的優化，主要是對URL的類結構做了一定調整，引入了多級緩存，下面具體分析。
2.3.2 URL結構變更及多級緩存
如下兩圖分別是Dubbo2.7.8和Dubbo3.0.7中的URL結構，可以看到在3.0.7中新增了URLAddress和URLParam類，原本URL中的host、port等信息移到了URLAddress中，原本URL的參數信息則移到了URLParam中。為什麼要這麼做？很大程度上是為了利用緩存，避免重複創建URL對象。比如將URL中的host、port等信息抽取到URLAddress對象中，當發生服務數據變更推送時，根據host、port等信息很大程度上能夠從緩存中找到已有的URLAddress對象，這樣就避免了一些不必要的URL創建。
2.3.3 核心方法
如下圖所示，當消費者接收到ZooKeeper註冊中心推送過來的全量服務提供者列表信息（providers）時，會調用到該方法進行ServiceAddressURL列表的創建。首先，會根據消費者URL嘗試從緩存stringUrls中獲取服務提供者信息對應的Map（key是服務提供者信息的字符串表示，value是對應的ServiceAddressURL）。如果該Map為空，則providers對應的ServiceAddressURL都需要創建。如果Map不為空，則先從該Map中根據provider的字符串key嘗試獲取緩存，如果存在則不需要調用createURL創建。
createURL也是依次從緩存stringAddress和stringParam獲取對應的URLAddress和URLParam，如果緩存中不存在則創建。接着，利用剛剛獲取到的URLAddress和URLParam以及consumerURL創建ServiceAddressURL。
創建完成後會判斷該ServiceAddressURL是否和當前消費者匹配（version、group這些信息是否匹配，前文已經分析過）。如果不匹配則返回空，後續也不會被更新到stringUrls緩存中。
創建完成後會調用evictURLCache，將待清理的URL信息放入waitForRemove中，cacheRemovalScheduler會定時清理緩存數據。
protected List<URL> toUrlsWithoutEmpty(URL consumer, Collection<String> providers) {
// 根據消費者URL信息從stringUrls中獲取對應的服務提供者信息
Map<String, ServiceAddressURL> oldURLs = stringUrls.get(consumer);
// create new urls
Map<String, ServiceAddressURL> newURLs;
// 去除consumerURL中的release、dubbo、methods、時間戳、dubbo.tag這些參數
URL copyOfConsumer = removeParamsFromConsumer(consumer);
// 如果緩存中沒有, 肯定都是需要新建的
if (oldURLs == null) {
newURLs = new HashMap<>((int) (providers.size() / 0.75f + 1));
for (String rawProvider : providers) {
// 去除掉rawProvider中的時間戳、PID參數
rawProvider = stripOffVariableKeys(rawProvider);
// 調用createURL創建ServiceAddressURL
ServiceAddressURL cachedURL =
createURL(rawProvider, copyOfConsumer, getExtraParameters());
// 如果創建的為空則忽略不放入newURLs
if (cachedURL == null) {
continue;
}
newURLs.put(rawProvider, cachedURL);
}
} else {
newURLs = new HashMap<>((int) (providers.size() / 0.75f + 1));
// maybe only default , or "env" + default
for (String rawProvider : providers) {
rawProvider = stripOffVariableKeys(rawProvider);
// 從緩存中獲取, 如果緩存中存在就不需要再創建了
ServiceAddressURL cachedURL = oldURLs.remove(rawProvider);
if (cachedURL == null) {
cachedURL = createURL(rawProvider, copyOfConsumer, getExtraParameters());
if (cachedURL == null) {
continue;
}
}
newURLs.put(rawProvider, cachedURL);
}
}
// 清除老的緩存數據
evictURLCache(consumer);
// 更新stringUrls緩存
stringUrls.put(consumer, newURLs);
return new ArrayList<>(newURLs.values());
}
protected ServiceAddressURL createURL(String rawProvider, URL consumerURL,
Map<String, String> extraParameters) {
boolean encoded = true;
int paramStartIdx = rawProvider.indexOf(ENCODED_QUESTION_MARK);
if (paramStartIdx == -1) {
encoded = false;
}
// 解析rawProvider, 一分為二, 一個用來創建URLAddress、一個用來創建URLParam
String[] parts = URLStrParser.parseRawURLToArrays(rawProvider, paramStartIdx);
if (parts.length <= 1) {
return DubboServiceAddressURL.valueOf(rawProvider, consumerURL);
}
String rawAddress = parts[0];
String rawParams = parts[1];
boolean isEncoded = encoded;
// 從緩存stringAddress緩存中獲取URLAddress, 不存在則創建
URLAddress address =
stringAddress.computeIfAbsent(rawAddress,
k -> URLAddress.parse(k, getDefaultURLProtocol(), isEncoded));
address.setTimestamp(System.currentTimeMillis());
// 從緩存stringParam緩存中獲取URLParam, 不存在則創建
URLParam param = stringParam.computeIfAbsent(rawParams,
k -> URLParam.parse(k, isEncoded, extraParameters));
param.setTimestamp(System.currentTimeMillis());
// 用獲取到的URLAddress、URLParam直接new創建ServiceAddressURL
ServiceAddressURL cachedURL = createServiceURL(address, param, consumerURL);
// 判斷創建出來的ServiceAddressURL是否和當前消費者匹配, 不匹配返回null
if (isMatch(consumerURL, cachedURL)) {
return cachedURL;
}
return null;
}2.4 ZooKeeperRegistry
2.4.1 註冊
根據傳入的URL生成該節點要在ZooKeeper服務端上註冊的節點路徑，值為如下形式：/dubbo/org.apache.dubbo.springboot.demo.DemoService/providers/服務信息，/dubbo是根路徑，接下來是服務的接口名，然後/providers是類型信息（如果是消費者則是/consumers節點，路由信息則是/routers），最後是URL的字符串表示。得到節點路徑後，會根據URL的dynamic參數（默認是true）決定在ZooKeeper服務端上創建的是臨時節點，還是持久節點，默認是臨時節點。
註冊後數據結構如下圖所示。
2.4.2 訂閲
訂閲的核心是通過ZooKeeperClient在指定的節點的添加ChildListener，當該節點的子節點數據發生變化時，ZooKeeper服務端會通知到該ChildListener的notify方法，然後調用到對應的NotifyListener方法，刷新消費者本地的服務提供者列表等信息。
doSubscribe方法主要分為兩個分支：URL的interface參數明確指定了為*（訂閲所有，通常實際使用中不會這麼使用，Dubbo的控制後台會訂閲所有）或者就訂閲某個服務接口，接下來分析訂閲某個指定服務接口這個分支代碼。這塊涉及到三個監聽器（它們是一對一的）：
1）NotifyListener，Dubbo中定義的通用的訂閲相關的監聽器。它是定義在dubbo-registry-api模塊中的，不僅僅在ZooKeeper註冊中心模塊中使用。
2）ChildListener，Dubbo中定義的針對ZooKeeper註冊中心的監聽器，用來監聽指定節點子節點的數據變化。
3）CuratorWatcher，Curator框架中的監聽器，Curator是常用的ZooKeeper客户端，如果Dubbo採用其它ZooKeeper客户端工具，這塊就是其它相關的監聽器邏輯了。
當訂閲的服務數據發生變化時，最先會觸發到CuratorWatcher的process方法，process方法中會調用ChildListener的childChanged方法，在childChanged方法會繼續觸發調用到ZooKeeperRegistry的notify方法。這裏有兩點需要注意：
1）因為doSubscribe方法中通過ZooKeeperClient添加Watcher監聽器時，使用的是usingWatcher，這是一次性的，所以在CuratorWatcher的實現CuratorWatcherImpl的process方法中，當收到ZooKeeper的變更數據推送時，會再次在path上註冊Watcher。
2）在ChildListener的實現RegistryChildListenerImpl的doNotify方法中，會調用ZooKeeperRegistry的toUrlsWithEmpty將傳入的字符串形式的服務提供者列表等數據轉換成對應的ServiceAddressURL列表數據，以供後面使用。
明確了三個監聽器的含義之後，接下來分析doSubscribe的邏輯就簡單了。首先會調用toCategoriesPath方法獲取三個path路徑，分別是
-
/dubbo/org.apache.dubbo.demo.DemoService/providers
-
/dubbo/org.apache.dubbo.demo.DemoService/configurators
-
/dubbo/org.apache.dubbo.demo.DemoService/routers
表示當前消費者（url參數代表）需要訂閲這三個節點，當任意一個節點的數據發生變化時，ZooKeeper服務端都會通知到當前註冊中心客户端，更新本地的服務數據。依次遍歷這三個path路徑，分別在這三個path上註冊監聽器。
ZooKeeperRegistry通過zkListeners這個Map維護了所有消費者（URL）的所有監聽器數據，首先根據url參數獲取當前消費者對應的監聽器listeners，這是一個Map，key是NotifyListener，value是對應的ChildListener，如果不存在則需要創建ChildListener的實現RegistryChildListenerImpl。當創建完成後，會在ZooKeeper服務端創建持久化的path路徑，並且在該path路徑上註冊監聽器。首次訂閲註冊監聽器時，會獲取到該路徑下的所有服務數據的字符串形式，並調用toUrlsWithEmpty轉成URL形式，接着調用notify方法刷新消費者本地的服務相關數據。
@Override
public void doSubscribe(final URL url, final NotifyListener listener) {
CountDownLatch latch = new CountDownLatch(1);
try {
List<URL> urls = new ArrayList<>();
// 獲取三個路徑, 分別是/providers、/routers、/configurators
for (String path : toCategoriesPath(url)) {
// 獲取該消費者URL對應的監聽器Map
ConcurrentMap<NotifyListener, ChildListener> listeners =
zkListeners.computeIfAbsent(url, k -> new ConcurrentHashMap<>());
// 查找NotifyListener對應的ChildListener是否存在, 不存在則創建
ChildListener zkListener = listeners.computeIfAbsent(listener,
k -> new RegistryChildListenerImpl(url, path, k, latch));
if (zkListener instanceof RegistryChildListenerImpl) {
((RegistryChildListenerImpl) zkListener).setLatch(latch);
}
// 在ZooKeeper服務端創建持久節點
zkClient.create(path, false);
// 添加ChildListener監聽器, 並全量拉取下相關服務數據
List<String> children = zkClient.addChildListener(path, zkListener);
if (children != null) {
// 將字符串形式的服務數據轉換成URL列表數據
urls.addAll(toUrlsWithEmpty(url, path, children));
}
}
// 首次訂閲後觸發下notify邏輯, 刷新消費者本地的服務提供者列表等數據
notify(url, listener, urls);
} finally {
latch.countDown();
}
}接下來看下AbstractZooKeeperClient的addChildListener方法，邏輯也比較簡單，在指定path路徑上添加一次性的Watcher。取消訂閲的邏輯則是會將傳入的UR和NotifyListener對應的ChildListener移除，不再監聽。
public List<String> addChildListener(String path, final ChildListener listener) {
ConcurrentMap<ChildListener, TargetChildListener> listeners =
childListeners.computeIfAbsent(path, k -> new ConcurrentHashMap<>());
TargetChildListener targetListener = listeners.computeIfAbsent(listener,
k -> createTargetChildListener(path, k));
return addTargetChildListener(path, targetListener);
}
@Override
public List<String> addTargetChildListener(String path, CuratorWatcherImpl listener) {
try {
return client.getChildren().usingWatcher(listener).forPath(path);
} catch (NoNodeException e) {
return null;
} catch (Exception e) {
throw new IllegalStateException(e.getMessage(), e);
}
}三、總結
本文通過分析Dubbo3.0中AbstractRegistry、FailbackRegistry、ZooKeeperRegistry，詳細介紹了Dubbo中ZooKeeper註冊中心的實現原理，包括服務數據本地緩存、服務註冊訂閲異常重試等。另外，網上大部分文章是基於2.x版本的，本文基於Dubbo3.0，重點分析了Dubbo3.0中新引入的CacheableFailbackRegistry，詳細介紹了Dubbo在URL推送模型上所做的優化。
參考資料：
- 循序漸進講解負載均衡vivoGateway(VGW)
- Tars-Java網絡編程源碼分析
- vivo 短視頻用户訪問體驗優化實踐
- 100 行 shell 寫個 Docker
- vivo全球商城：庫存系統架構設計與實踐
- 非侵入式入侵 —— Web緩存污染與請求走私
- 解密遊戲推薦系統的建設之路
- 解密遊戲推薦系統的建設之路
- 用户行為分析模型實踐（三）——H5通用分析模型
- vivo版本發佈平台：帶寬智能調控優化實踐-平台產品系列03
- 廣告流量反作弊風控中的模型應用
- vivo官網App模塊化開發方案-ModularDevTool
- OKR之劍·實戰篇05：OKR致勝法寶-氛圍&業績雙輪驅動（上）
- vivo 自研Jenkins資源調度系統設計與實踐
- vivo官網App模塊化開發方案-ModularDevTool
- Dubbo 中 Zookeeper 註冊中心原理分析
- 用户行為分析模型實踐（三）——H5通用分析模型
- Node.js 應用全鏈路追蹤技術——全鏈路信息存儲
- 從0到1設計通用數據大屏搭建平台
- vivo 超大規模消息中間件實踐之路