Zookeeper恢復(fù)了，線上微服務(wù)卻全部掉線了，怎么回事？

作者：阿丸筆記 2023-02-06 09:31:59

除了優(yōu)化對(duì)異常的捕獲處理外，RPC框架對(duì)注冊(cè)中心的空地址推送也應(yīng)該做特殊判斷，用業(yè)界的專業(yè)名詞來說，就是「推空保護(hù)」。所謂「推空保護(hù)」，就是在服務(wù)發(fā)現(xiàn)監(jiān)聽獲取空節(jié)點(diǎn)列表時(shí)，維持本地服務(wù)發(fā)現(xiàn)列表緩存，而不是清空處理。

注冊(cè)中心zookeeper重啟恢復(fù)后，線上微服務(wù)卻全部掉線了，怎么回事？！

最近因?yàn)橐淮五e(cuò)誤的運(yùn)維操作，導(dǎo)致線上注冊(cè)中心zk被重啟。而zk重啟后發(fā)現(xiàn)所有線上微服務(wù)開始不斷掉線，造成了持續(xù)30分鐘的P0?故障。

整體排查過程深入學(xué)習(xí)了 zookeeper的session機(jī)制，以及在這種異常情況下，RPC框架應(yīng)該如何處理。

好了，一起來回顧下這次線上故障吧，最佳實(shí)踐總結(jié)放在最后，千萬不要錯(cuò)過。

1、現(xiàn)象描述

某天晚上19:43分左右，誤操作將線上zk集群下線（stop），總共7臺(tái)節(jié)點(diǎn)，下線了6臺(tái)，導(dǎo)致zk停止工作。

在發(fā)現(xiàn)節(jié)點(diǎn)下掉后，于19:51分左右將所有zk節(jié)點(diǎn)進(jìn)行重啟（start），期間服務(wù)正常運(yùn)行，沒有收到批量業(yè)務(wù)調(diào)用的報(bào)錯(cuò)和客訴。

直到19:56分，開始收到大面積調(diào)用失敗的警報(bào)和客訴，我們嘗試著依賴自研RPC框架與zk間重連后的「自動(dòng)恢復(fù)」機(jī)制，希望能夠在短時(shí)間內(nèi)批量恢復(fù)。

但是很不幸，過了接近8分鐘，沒有任何大面積恢復(fù)的跡象。

結(jié)合zk znode節(jié)點(diǎn)數(shù)上升非常緩慢的情況，于是我們采取了應(yīng)急措施，將所有微服務(wù)的pod原地重啟，執(zhí)行重啟后效果顯著，大面積服務(wù)在短時(shí)間內(nèi)逐步恢復(fù)。

2、初步分析

我們自研的RPC框架采用典型的注冊(cè)中心+provider+consumer 的模式，通過zk臨時(shí)節(jié)點(diǎn)的方式做服務(wù)的注冊(cè)發(fā)現(xiàn)，如下圖所示。

結(jié)合故障期間發(fā)生的現(xiàn)象，我們初步分析：

階段1：zk集群停服（stop）期間，業(yè)務(wù)能夠正常調(diào)用。原因是consumer無法訪問zk，暫時(shí)失去服務(wù)發(fā)現(xiàn)能力，所以在這個(gè)期間只要服務(wù)沒有重啟，就不會(huì)刷新本地的服務(wù)發(fā)現(xiàn)provider緩存列表provider-list，調(diào)用無異常。
階段2：zk集群啟動(dòng)完畢后，服務(wù)間立刻出現(xiàn)調(diào)用問題。原因是consumer連接上zk后，立刻進(jìn)行服務(wù)發(fā)現(xiàn)操作，然而provider服務(wù)這時(shí)還沒重新注冊(cè)到zk，讀取到的是空地址列表，造成了業(yè)務(wù)的批量報(bào)錯(cuò)。
階段3：zk恢復(fù)后續(xù)一段時(shí)間，provider服務(wù)仍然沒「自動(dòng)重連」到zk，導(dǎo)致consumer持續(xù)報(bào)錯(cuò)。在所有服務(wù)全量重啟后，provider服務(wù)重新注冊(cè)成功，consumer恢復(fù)。

這里存在一個(gè)問題：

為什么zk集群恢復(fù)后，provider客戶端「自動(dòng)重連」注冊(cè)中心的機(jī)制沒有生效？導(dǎo)致consumer被推送了空地址列表后，沒有再收到重新的provider注冊(cè)節(jié)點(diǎn)信息了。

3、深入排查

(1問題復(fù)現(xiàn)

根據(jù)大量測試，我們找到了穩(wěn)定復(fù)現(xiàn)本次問題的方法：

zk session過期包括「服務(wù)端過期」和「客戶端過期」，在「客戶端過期」情況下恢復(fù)zk集群，會(huì)導(dǎo)致「臨時(shí)節(jié)點(diǎn)」丟失，且無法自動(dòng)恢復(fù)的情況。

(2原因分析

1）?在集群重啟恢復(fù)后，RPC框架客戶端立刻就與zk集群取得重連，將保存在本地內(nèi)存待注冊(cè)的providers節(jié)點(diǎn) + 待訂閱的consumers節(jié)點(diǎn) 進(jìn)行重建。

2）但是zk集群此時(shí)根據(jù)snapshot恢復(fù)的「臨時(shí)節(jié)點(diǎn)」（包括provider和consumer) 都還在，因此重建操作返回NodeExist異常，重建失敗了。（問題1：為什么沒有重試？）

3）在集群重啟恢復(fù)40s后，將過期Session相關(guān)的臨時(shí)節(jié)點(diǎn)全都移除了。（問題2：為什么要移除？）

4）consumer監(jiān)聽到節(jié)點(diǎn)移除的空列表，清空了本地provider列表。故障發(fā)生了。?

基于這個(gè)分析，我們需要進(jìn)一步圍繞2個(gè)問題進(jìn)行源碼的定位：

問題1：zk集群恢復(fù)后，前40s，為什么RPC框架的客戶端在創(chuàng)建臨時(shí)節(jié)點(diǎn)失敗后沒有重試？
問題2：zk集群恢復(fù)后，40s后，為什么zk會(huì)刪除之前所有已經(jīng)恢復(fù)的臨時(shí)節(jié)點(diǎn)？

（3）問題1：為什么臨時(shí)節(jié)點(diǎn)創(chuàng)建失敗沒有重試？

通過源碼分析，我們看到，RPC框架客戶端與服務(wù)端取得重連后，會(huì)將內(nèi)存里老的臨時(shí)節(jié)點(diǎn)進(jìn)行重新創(chuàng)建。

這段邏輯看來沒有什么問題，doRegister成功之后才會(huì)將該節(jié)點(diǎn)從失敗列表中移除，否則將繼續(xù)定時(shí)去重試創(chuàng)建。

繼續(xù)往下走，關(guān)鍵點(diǎn)來了：

這里我們可以看到，在創(chuàng)建臨時(shí)節(jié)點(diǎn)時(shí)，吞掉了服務(wù)端返回的NodeExistsException，使整個(gè)外層的doRegister和doSubscribe（訂閱）方法在這種情況下都被認(rèn)為是重新創(chuàng)建成功，所以只創(chuàng)建了一次。

正如上面分析的，其實(shí)正常情況下，這里對(duì)NodeExistsException不做處理是沒有問題的，就是節(jié)點(diǎn)已經(jīng)存在不用再添加了，也不需要再重試了，但是伴隨服務(wù)端后續(xù)踢出老sessionId同時(shí)刪除了相關(guān)臨時(shí)節(jié)點(diǎn)，就引起了故障。

（4）問題2：zk為什么刪除已經(jīng)恢復(fù)的臨時(shí)節(jié)點(diǎn)？

1）從zk的session機(jī)制說起

眾所周知，zk session管理在客戶端、服務(wù)端都有實(shí)現(xiàn)，并且兩者通過心跳進(jìn)行交互。

在發(fā)送心跳包時(shí)，客戶端會(huì)攜帶自己的sessionId，服務(wù)端收到請(qǐng)求，檢查sessionId確認(rèn)存活后再發(fā)送返回結(jié)果給客戶端。

如果客戶端發(fā)送了一個(gè)服務(wù)端并不知道的sessionId，那么服務(wù)端會(huì)生成一個(gè)新的sessionId頒布給客戶端，客戶端收到后本地進(jìn)行sessionid的刷新。

2）zk客戶端（curator）session過期機(jī)制

當(dāng)客戶端（curator）本地sessionTimeout超時(shí)時(shí)，會(huì)進(jìn)行本地zk對(duì)象的重建（reset），我們從源碼可以看到默認(rèn)將本地的sessionId重置為0了。

zk服務(wù)端后續(xù)收到這個(gè)為“0”sessionId，認(rèn)為是一個(gè)未知的session需要?jiǎng)?chuàng)建，接著就為客戶端創(chuàng)建了一個(gè)新的sessionId。

3）服務(wù)端（zookeeper）session過期處理機(jī)制

服務(wù)端(zookeeper) sessionTimeout的管理，是在zk會(huì)話管理器中看到一個(gè)線程任務(wù)，不斷判斷管理的session是否有超時(shí)（獲取下一個(gè)過期時(shí)間點(diǎn)nextExpirationTime已經(jīng)超時(shí)的會(huì)話），并進(jìn)行會(huì)話的清理。

我們繼續(xù)往下走，關(guān)鍵點(diǎn)來了，在清理session的過程中，除了將sessionId從本地expiryMap中清除外，還進(jìn)行了臨時(shí)節(jié)點(diǎn)的清理：

?原來zkserver端是將sessionId和它所創(chuàng)建的臨時(shí)節(jié)點(diǎn)進(jìn)行了綁定。伴隨著服務(wù)端sessionId的過期，綁定的所有臨時(shí)節(jié)點(diǎn)也會(huì)隨之刪除。

因此，zk集群恢復(fù)后40s，zk服務(wù)端session超時(shí)，刪除了過期session的所有相關(guān)臨時(shí)節(jié)點(diǎn)。?

4、故障根本原因總結(jié)

1）zk集群恢復(fù)的第一時(shí)間，對(duì)zk的snapshot文件進(jìn)行了讀取并初始化zk數(shù)據(jù)，取到了老session，進(jìn)行了create session的操作，完成了一次老session的續(xù)約（重置40s）。

集群恢復(fù)關(guān)鍵入口-重新加載snapshot：

進(jìn)行session恢復(fù)（創(chuàng)建）操作，默認(rèn)session timeout 40s：?

?2）而此時(shí)客戶端session早已經(jīng)過期，帶著空sessionid 0x0進(jìn)行重連，獲得新sessionId。但是此時(shí)RPC框架在臨時(shí)節(jié)點(diǎn)注冊(cè)失敗后吞掉了服務(wù)端返回的NodeExistsException，被認(rèn)為是重新創(chuàng)建成功，所以只創(chuàng)建了一次。

3）zk集群恢復(fù)后經(jīng)過40s最終因?yàn)榉?wù)端session過期，將過期sessionId和及其綁定的臨時(shí)節(jié)點(diǎn)進(jìn)行了清除。

4）consumer監(jiān)聽到節(jié)點(diǎn)移除的空列表，清空了本地provider列表。故障發(fā)生了。?

5、解決方案

經(jīng)過上面的源碼分析，解決方案有兩種：

方案1：客戶端（curator）設(shè)置session過期時(shí)間更長或者不過期，那么集群恢復(fù)后的前40s，客戶端帶著原本的sessionid跟服務(wù)端做一次請(qǐng)求，就自動(dòng)續(xù)約了，不再過期。
方案2：客戶端session過期后，帶著空sessionid 0x0進(jìn)行重連的時(shí)候，對(duì)NodeExsitException做處理，進(jìn)行刪除-重添加操作，保證重連成功。

于是我們調(diào)研了一下業(yè)界使用zk的開源微服務(wù)框架是否支持自愈，以及如何實(shí)現(xiàn)的：

dubbo采用了方案2。

注釋也寫得非常清楚：?

“ZNode路徑已經(jīng)存在，因?yàn)槲覀冎粫?huì)在會(huì)話過期時(shí)嘗試重新創(chuàng)建節(jié)點(diǎn)，所以這種重復(fù)可能是由zk服務(wù)器的刪除延遲引起的，這意味著舊的過期會(huì)話可能仍然保存著這個(gè)ZNode，而服務(wù)器只是沒有時(shí)間進(jìn)行刪除。在這種情況下，我們可以嘗試刪除并再次創(chuàng)建。”

看來dubbo確實(shí)后續(xù)也考慮到這個(gè)邊界場景，防止踩坑。

所以最后我們的解決方案也是借鑒dubbo fix的邏輯，進(jìn)行節(jié)點(diǎn)的替換：先deletePath再createPath，這么做的原因是將zk服務(wù)端內(nèi)存維護(hù)的過期sessionId替換新的sessionId，避免后續(xù)zk清理老sessionId時(shí)將所有綁定的節(jié)點(diǎn)刪除。