漂移檢測與選主實現(xiàn))
1. 先聊清楚微信個人號多設備場景下的“在線狀態(tài)漂移”是什么1.1 多個實例同時工作為什么會產(chǎn)生狀態(tài)分歧如果你搭過微信個人號相關的中臺服務一定遇過這種奇怪現(xiàn)象后臺明明顯示賬號在線消息流水也正常可業(yè)務側(cè)就是反饋漏消息、重復消息。查到最后往往是同一個號被兩個進程同時管理著A 進程剛發(fā)完一條消息B 進程又把它頂下線微信端的在線狀態(tài)像拉鋸一樣來回橫跳。我們內(nèi)部把這種現(xiàn)象叫做“在線狀態(tài)漂移”——主控權從一個實例轉(zhuǎn)移到另一個實例但沒有經(jīng)過雙方確認誰都覺得當前自己才有資格操作這個賬號。這種場景在帶多設備、多進程的 IM 個人號管理系統(tǒng)里非常常見客服工作臺、消息聚合、自動化備份都可能讓同一套憑據(jù)同時暴露給多個節(jié)點。理想情況下同一時間只能有一個實例作為“主控”與微信服務端保持主會話其他實例只做只讀監(jiān)聽或待命。可一旦節(jié)點宕機、網(wǎng)絡抖動、進程僵死主控身份就需要立刻交給另一個實例。關鍵問題是怎么讓大家同時感知到“舊主已失效”并且在新舊交替時不讓消息發(fā)送錯亂。這就是在線狀態(tài)漂移檢測要解決的核心矛盾。1.2 數(shù)據(jù)庫里放一個在線標志位為什么靠不住有人會想在數(shù)據(jù)庫建一張狀態(tài)表online_holdernode_aA 不行了就改成node_b不就行了嗎我一開始也是這么干的后來發(fā)現(xiàn)這條路走不通。第一數(shù)據(jù)庫里存的只是一個靜態(tài)快照。進程是被 kill -9 干掉的數(shù)據(jù)庫不會自動把狀態(tài)改成“離線”只能靠額外的定時任務去心跳清理而心跳本身又會引入新的超時判斷問題。第二多節(jié)點同時讀寫這張表時時序很難控制。A 網(wǎng)絡抖動恢復后可能并不知道 B 已經(jīng)把狀態(tài)改成自己了它只要再往數(shù)據(jù)庫寫一條online_holdernode_a狀態(tài)就又分裂了。第三數(shù)據(jù)庫的更新事務沒法保障“誰真正持有網(wǎng)絡會話”這個事實。會話是長連接數(shù)據(jù)庫狀態(tài)只是一個弱信號兩者沒有強綁定關系最終一定會出現(xiàn)狀態(tài)與事實脫節(jié)。所以我們需要的是一個具備“會話語義”的協(xié)調(diào)組件把進程是否存在、會話是否有效、主控權是否被持有這幾件事天然綁在一起。ZooKeeper 的臨時節(jié)點正好干這個。2. 選型思考為什么是 ZooKeeper而不是 Redis 或 MySQL2.1 臨時節(jié)點天然就是在線狀態(tài)的“心跳探針”ZooKeeper 里有一種節(jié)點叫臨時節(jié)點Ephemeral Node它和客戶端的 ZK 會話綁定?？蛻舳藙?chuàng)建臨時節(jié)點之后如果連接斷開并且超過會話超時時間ZooKeeper 服務端會主動把這個節(jié)點刪除。進程被強殺、機器掉電、長時間網(wǎng)絡隔離都會觸發(fā)同樣的結果節(jié)點自動消失。這個特性幾乎是給“在線狀態(tài)漂移檢測”量身定做的。我們不需要寫清理邏輯去移除僵尸標記也不需要等業(yè)務方手動上報離線。ZK 服務端會替我們做這件事。把“當前主控權”放在一個臨時節(jié)點上等于告訴所有節(jié)點誰能在 ZK 里保住這個節(jié)點誰才有資格繼續(xù)對外操作。這里有個容易忽略的細節(jié)臨時節(jié)點刪除的時機是“會話超時”不是“連接斷開”。客戶端和 ZooKeeper 之間的連接斷開后會話不會立刻失效ZK 服務端會等待一個會話超時時間期間如果網(wǎng)絡恢復客戶端可以重連并繼續(xù)使用同一個會話。這個超時時間是可以配置的后面我會專門講如何避免因為參數(shù)設置不當導致誤漂移。2.2 Watch 機制讓狀態(tài)變化能夠主動通知所有候選節(jié)點ZooKeeper 的另一個關鍵能力是 Watch監(jiān)聽。客戶端可以對某個節(jié)點設置監(jiān)聽節(jié)點創(chuàng)建、刪除、數(shù)據(jù)變化、子節(jié)點變化時ZK 會向客戶端推送一個事件。這樣選主和漂移檢測就可以從“定時輪詢”變成“事件驅(qū)動”。比如每個候選節(jié)點都盯著當前active節(jié)點一旦active節(jié)點消失所有候選中至少有一個會收到通知馬上發(fā)起新一輪選舉。如果換成數(shù)據(jù)庫輪詢就得每隔幾百毫秒查一次狀態(tài)表既慢又費資源而且響應速度還取決于輪詢間隔。當然Watch 是“一次性”的。事件觸發(fā)后監(jiān)聽自動失效如果業(yè)務代碼沒有重新注冊 Watch下一次變化就感知不到了。這是一個非常經(jīng)典的坑后面的實操部分我會給出應對方案。2.3 和 Redis / MySQL / etcd 放在一起看選型時我也對比過其他方案簡單列個表方案會話綁定能力事件通知運維成本適合場景ZooKeeper有臨時節(jié)點綁定會話節(jié)點隨會話失效自動刪除原生 Watch注冊簡單偏高集群需要獨立維護分布式協(xié)調(diào)、選主、分布式鎖Redis沒有會話概念需要自己用 TTL 模擬可用 Pub/Sub 或 Stream但語義弱低簡單緩存鎖、短任務互斥MySQL無狀態(tài)全靠業(yè)務寫無只能輪詢低業(yè)務狀態(tài)存儲etcd有 Lease可綁定節(jié)點續(xù)期有 WatchgRPC 生態(tài)高云原生場景下的選主配置如果你團隊里已經(jīng)有成熟的 ZooKeeper 集群用 ZK 做在線狀態(tài)漂移檢測和選主是最順手的。如果沒運維條件etcd 也完全可以做類似的事但本文重點講 ZooKeeper 的實現(xiàn)思路。3. 在線狀態(tài)漂移檢測與選主的整體設計3.1 節(jié)點模型把賬號狀態(tài)“立”在 ZooKeeper 上我最終采用的節(jié)點結構大概是這樣/wx-accounts /{wxid} /members /m-0000000001 /m-0000000002 /active三層節(jié)點的含義/wx-accounts/{wxid}是持久節(jié)點代表一個微信個人號。/wx-accounts/{wxid}/members是持久節(jié)點用戶存放所有候選實例。/members/m-0000000001是臨時順序節(jié)點。每個實例啟動時都在這里創(chuàng)建一個節(jié)點節(jié)點序號由 ZooKeeper 自動遞增。/wx-accounts/{wxid}/active是臨時節(jié)點由當前主控實例創(chuàng)建。誰創(chuàng)建成功了誰就是主控。active節(jié)點的數(shù)據(jù)里我習慣放一段 JSON{ seq: 1, instanceId: host-a-001, sessionId: 1234567890, activeSince: 1699999999000 }seq就是候選節(jié)點的序號instanceId是本實例的唯一標識sessionId是 ZK 會話 ID。這三個字段一起決定“當前主控是誰”以及“是否發(fā)生了狀態(tài)漂移”。用臨時順序節(jié)點而不是隨機節(jié)點名是有意的節(jié)點序號天然給出了候選者的繼任順序先啟動的實例序號小更容易成為主控中途掛掉后下一個節(jié)點自動頂上不需要再做復雜的優(yōu)先級排序。3.2 選主流程順序節(jié)點 最小序號 Watch 前驅(qū)有了上面的節(jié)點模型選主流程就非常清晰了實例啟動連接 ZooKeeper。確保/wx-accounts/{wxid}和/members持久節(jié)點存在。在/members下創(chuàng)建臨時順序節(jié)點拿到自己的seq。讀取/members下所有子節(jié)點按序號排序。如果自己的序號是最小的嘗試創(chuàng)建/active臨時節(jié)點。創(chuàng)建成功就是主控實例失敗說明已經(jīng)有主控存在那就監(jiān)聽/active。如果自己的序號不是最小那么監(jiān)聽“緊挨著自己前面的那個節(jié)點”。比如當前序是 2就監(jiān)聽序 1 的節(jié)點。當前驅(qū)節(jié)點消失時說明前面的候選退出了立刻重新讀取子節(jié)點重新執(zhí)行選舉。這里的關鍵優(yōu)化是“只監(jiān)聽前驅(qū)節(jié)點”。如果所有候選節(jié)點都監(jiān)聽/active一旦active刪除所有節(jié)點都會收到事件但只有一個能創(chuàng)建成功其他節(jié)點白白競爭會產(chǎn)生驚群效應。通過監(jiān)聽前驅(qū)節(jié)點ZooKeeper 天然給候選人排了隊前面的掛了后面的頂上整個過程非常安靜。選舉完成后非主控節(jié)點還要繼續(xù)監(jiān)聽/active節(jié)點因為如果主控實例進程沒崩但是active節(jié)點被人為刪除或數(shù)據(jù)被改也需要觸發(fā)重新評估。3.3 漂移檢測規(guī)則序號、會話、持有者三者缺一不可在線狀態(tài)漂移檢測的核心不是簡單判斷“有沒有主控”而是判斷“當前主控是不是我”。我總結了三個信號信號一我的候選節(jié)點在/members下是否存在。如果不存在說明我的 ZK 會話可能已經(jīng)過期我失去競選資格。信號二/active節(jié)點是否存在。不存在說明當前沒有主控需要立即選舉。信號三/active節(jié)點里的數(shù)據(jù)是不是我。如果節(jié)點存在但instanceId、sessionId、seq和我本地不一致說明主控權已經(jīng)漂移到了別的實例我必須立刻降級。把這三個信號組合起來看候選節(jié)點存在active 節(jié)點存在active 持有者是我判定結果是是是正常主控繼續(xù)工作是是否候選/待命等待 active 消失是否否沒有主控立即參與選舉否任意任意本實例已失去資格重新登記節(jié)點連接斷開任意任意暫停一切業(yè)務操作等待重連這里最容易被忽略的是“連接斷開”這一行。我在早期實現(xiàn)里犯過錯誤本地進程以為自己還是主控繼續(xù)向微信服務發(fā)送消息但其實 ZooKeeper 里active節(jié)點已經(jīng)因為會話超時被刪除了新的主控已經(jīng)產(chǎn)生于是兩邊同時發(fā)消息造成重復和沖突。正確做法是只要 ZK 客戶端進入Disconnected或Expired狀態(tài)立刻把本地角色降級為SUSPEND停掉所有對外寫操作避免舊主在不知道的情況下繼續(xù)工作。3.4 狀態(tài)機把角色流轉(zhuǎn)寫清楚所有實例都會經(jīng)歷幾個狀態(tài)INIT初始化、CANDIDATE候選、LEADER主控、WAITING等待前驅(qū)、SUSPEND暫停/降級。創(chuàng)建候選節(jié)點成功進入CANDIDATE。CANDIDATE發(fā)現(xiàn)自己是最小序號且成功創(chuàng)建active進入LEADER。CANDIDATE發(fā)現(xiàn)前驅(qū)還在進入WAITING。WAITING收到前驅(qū)節(jié)點刪除事件回到CANDIDATE重新選舉。LEADER如果發(fā)現(xiàn)active節(jié)點消失、數(shù)據(jù)被改、ZK 連接異常進入SUSPEND。SUSPEND重連成功后重新創(chuàng)建候選節(jié)點進入CANDIDATE。把這個狀態(tài)機寫清楚代碼就不容易亂。我在工程里遇到過一些代碼選主邏輯和心跳邏輯混在一起狀態(tài)一多就開始到處改變量最后線上故障時根本分不清當前該算什么態(tài)。后來強行把狀態(tài)流轉(zhuǎn)收斂到一個對象里所有狀態(tài)變更都只由 ZK 事件驅(qū)動再也沒有出現(xiàn)過“看著像主控但其實不是”的混亂窗口。4. Java 落地一套最小可用的選主與漂移檢測實現(xiàn)4.1 環(huán)境與依賴準備我用 Java 原生客戶端做了一版可運行的最小實現(xiàn)。先加依賴dependency groupIdorg.apache.zookeeper/groupId artifactIdzookeeper/artifactId version3.8.4/version /dependency本地起一個單節(jié)點 ZooKeeper 就夠了測試時用bin/zkServer.sh start啟動服務默認端口2181。生產(chǎn)環(huán)境建議起三節(jié)點集群但選主邏輯本身不需要區(qū)分單機還是集群。核心類我命名為WxAccountLeaderElector字段包括private final ZooKeeper zk; private final String wxid; private final String instanceId; private final String membersPath; private final String activePath; private String candidatePath; private long localSeq; private volatile boolean isLeader false;instanceId用來標識本機實例比如host-a-001。后面判斷active節(jié)點是否為本人持有全靠它。4.2 候選注冊創(chuàng)建臨時順序節(jié)點實例啟動的第一步是創(chuàng)建候選節(jié)點。這個過程相當于向 ZooKeeper 喊一句“我來了請給我排個號”。public void start() throws Exception { ensureParentNode(); registerCandidate(); evaluateLeader(); } private void ensureParentNode() throws Exception { if (zk.exists(/wx-accounts, false) null) { zk.create(/wx-accounts, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } if (zk.exists(/wx-accounts/ wxid, false) null) { zk.create(/wx-accounts/ wxid, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } String path /wx-accounts/ wxid /members; if (zk.exists(path, false) null) { zk.create(path, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } } private void registerCandidate() throws Exception { String data String.format({\instanceId\:\%s\,\pid\:%d,\startTime\:%d}, instanceId, ProcessHandle.current().pid(), System.currentTimeMillis()); candidatePath zk.create(membersPath /m-, data.getBytes(StandardCharsets.UTF_8), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); localSeq Long.parseLong(candidatePath.substring(candidatePath.lastIndexOf(-) 1)); }這里創(chuàng)建的是EPHEMERAL_SEQUENTIAL節(jié)點它既具備臨時節(jié)點的自動刪除特性又能得到一個全局遞增的序號。所有候選節(jié)點按照創(chuàng)建順序排成一條隊序號越小優(yōu)先級越高。4.3 選主與漂移監(jiān)聽核心邏輯選主邏輯在evaluateLeader方法里。每次 ZK 事件觸發(fā)都會重新評估當前角色。private void evaluateLeader() throws Exception { if (zk.getState() ! ZooKeeper.States.CONNECTED) { markFence(); return; } ListString children zk.getChildren(membersPath, true); ListLong seqs children.stream() .map(p - Long.parseLong(p.substring(p.lastIndexOf(-) 1))) .sorted() .collect(Collectors.toList()); if (seqs.isEmpty()) { return; } long minSeq seqs.get(0); if (minSeq localSeq) { tryAcquireActive(); } else { long prevSeq seqs.get(seqs.indexOf(localSeq) - 1); String prevPath membersPath /m- prevSeq; if (zk.exists(prevPath, event - { if (event.getType() EventType.NodeDeleted) { try { evaluateLeader(); } catch (Exception e) { log.error(重新選舉失敗, e); } } }) null) { evaluateLeader(); } } }注意zk.exists(prevPath, ...)這一步注冊的是針對前驅(qū)節(jié)點的 Watch。事件回調(diào)只在NodeDeleted時觸發(fā)觸發(fā)后重新執(zhí)行evaluateLeader這樣當前實例就能從前驅(qū)消失的狀態(tài)中立刻感知到主控權發(fā)生了漂移。下一步是嘗試創(chuàng)建active節(jié)點也就是搶主控private void tryAcquireActive() throws Exception { String data String.format({\seq\:%d,\instanceId\:\%s\,\sessionId\:%d}, localSeq, instanceId, zk.getSessionId()); try { zk.create(activePath, data.getBytes(StandardCharsets.UTF_8), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL); isLeader true; log.info(成為主控實例seq{}, instance{}, localSeq, instanceId); zk.exists(activePath, event - { if (event.getType() EventType.NodeDeleted) { try { evaluateLeader(); } catch (Exception e) { log.error(active 節(jié)點消失重新選舉失敗, e); } } }); } catch (KeeperException.NodeExistsException e) { log.info(active 已存在當前不是主控進入等待狀態(tài)); isLeader false; zk.exists(activePath, event - { if (event.getType() EventType.NodeDeleted) { try { evaluateLeader(); } catch (Exception ex) { log.error(重新選舉失敗, ex); } } }); } }當active創(chuàng)建成功isLeader置為true。但“創(chuàng)建成功”只代表那一瞬間我是主控不代表我一直是。所以每次對外執(zhí)行任務前還要做一次漂移校驗確保主控權沒有在后臺悄悄溜走。4.4 發(fā)送消息前的主控權校驗我在實際工程里寫了一個方法所有對外操作都必須走這一層門禁public boolean checkLeadership() { if (!isLeader) { return false; } if (zk.getState() ! ZooKeeper.States.CONNECTED) { resign(); return false; } try { Stat stat new Stat(); byte[] raw zk.getData(activePath, false, stat); ActiveInfo info ActiveInfo.fromJson(raw); boolean mine info.seq localSeq info.instanceId.equals(instanceId) info.sessionId zk.getSessionId(); if (!mine) { resign(); return false; } return true; } catch (KeeperException.NoNodeException e) { resign(); return false; } catch (Exception e) { return false; } } private void resign() { isLeader false; log.warn(檢測到在線狀態(tài)漂移或主控權丟失當前實例已降級); }這里最關鍵的一點是除了比對instanceId還要比對sessionId。因為 ZK 會話過期后客戶端重連會得到一個全新的sessionId即使instanceId相同它也不是原來的會話。單獨比對instanceId是不夠的。任務執(zhí)行時可以這樣統(tǒng)一約束public boolean executeIfLeader(Runnable task) { if (!checkLeadership()) { log.warn(非主控或主控已漂移拒絕執(zhí)行任務); return false; } task.run(); return true; }嚴格來說這個校驗屬于“操作前檢查”。在分布式環(huán)境下舊主可能已經(jīng)和新主同時工作消息帶一個 fencing token 會更安全。seq就是天然的 token每一次選主都會產(chǎn)生更大的序號下游服務只需要拒絕 token 小于當前主控序號的請求就能避免舊主消息造成數(shù)據(jù)沖突。4.5 運行效果漂移檢測到底能檢測到什么假設我同時啟動兩個實例A和BA 啟動創(chuàng)建/members/m-0000000001成功創(chuàng)建/activeA 成為主控。B 啟動創(chuàng)建/members/m-0000000002發(fā)現(xiàn)最小序號不是自己于是 watchm-1進入等待狀態(tài)。我手動 kill 掉 A 進程。ZK 檢測到 A 的會話結束臨時節(jié)點m-1和/active自動刪除。B 收到前驅(qū)節(jié)點刪除事件重新執(zhí)行evaluateLeader發(fā)現(xiàn)自己是當前最小序號創(chuàng)建active成功B 成為新主控。我重新啟動 A。A 創(chuàng)建/members/m-0000000003發(fā)現(xiàn)最小序號是 B于是 watchm-2進入等待。整個過程里B 的日志會出現(xiàn)一行“成為主控實例”A 重啟后不會有任何任務權限直到 B 再次故障。這就是一次標準的在線狀態(tài)漂移檢測和選主切換。5. 實戰(zhàn)中踩過的坑故障排查與避坑清單5.1 網(wǎng)絡抖動引發(fā)的會話超時誤判我在測試環(huán)境第一次上線這套邏輯時用的是 5 秒會話超時。結果機房一次輕微的網(wǎng)絡抖動把所有實例全部踢下線觸發(fā)了一次完全沒必要的選主切換。原因是 ZooKeeper 的臨時節(jié)點刪除機制基于會話超時不是基于連接斷開。網(wǎng)絡抖動后ZK 服務端暫時聯(lián)系不上客戶端如果超時設得太短服務端會認為客戶端死了直接刪除臨時節(jié)點?？蛻舳司W(wǎng)絡恢復后發(fā)現(xiàn)自己創(chuàng)建的節(jié)點已經(jīng)沒了只能重新注冊。我的建議是把 ZK 客戶端構造參數(shù)里的sessionTimeout設置為 20 到 30 秒具體數(shù)值取決于業(yè)務對“主控恢復速度”和“誤判容忍度”的權衡。如果業(yè)務可以容忍 30 秒沒有主控就設 30 秒如果希望秒級切換那就要接受網(wǎng)絡抖動帶來的誤判風險。同時客戶端收到Disconnected事件時不要等 ZK 告訴你“節(jié)點已刪除”自己要先主動標記為SUSPEND暫停所有對外寫操作。這樣即使 ZK 側(cè)還沒判定會話超時業(yè)務側(cè)也不會因為舊主繼續(xù)工作而產(chǎn)生重復信息。5.2 舊進程僵尸化帶來的雙主窗口真正危險的場景不是進程被 kill而是舊主進程還活著但它和 ZooKeeper 之間的網(wǎng)絡被切斷了。這時候從 ZK 的視角看舊主已經(jīng)因為會話超時而退出新主成功上位但舊主進程還保存著“我是主控”的本地狀態(tài)它仍然能訪問微信服務端繼續(xù)發(fā)消息。兩個主同時存在就成了雙主窗口。這個問題不能單靠 ZooKeeper 解決。ZooKeeper 只能保證“在 ZK 內(nèi)部狀態(tài)一致”不能保證“在業(yè)務網(wǎng)絡里也一致”。我最后的處理方法是兩層配合客戶端收到Disconnected時立刻拒絕所有本地任務不等待 ZK 判定。業(yè)務消息里帶上 fencing token也就是active節(jié)點里的seq。下游服務只接受當前主控的 token。如果你能把 token 校驗下沉到消息網(wǎng)關雙主問題能基本被攔住。舊主發(fā)出來的 token 已經(jīng)比新主小網(wǎng)關直接拒絕比舊主自己“猜”自己是不是主控要可靠得多。5.3 Watch 只觸發(fā)一次重連后通知丟失ZooKeeper 的 Watch 是一次性的。最開始我寫代碼時只在初始化時注冊了一次exists后面發(fā)現(xiàn)節(jié)點變化后程序完全沒有反應。排了半天才發(fā)現(xiàn)事件觸發(fā)后 Watch 就失效了如果不重新注冊下一次變化永遠感知不到。更隱蔽的是在回調(diào)里重新執(zhí)行evaluateLeader時getChildren(membersPath, true)會注冊一個新的 Watch但如果你在某條分支里調(diào)了zk.exists(prevPath, watcher)這次注冊也是獨立的別忘記在對應回調(diào)里再次注冊。我建議把“重新評估 重新注冊 Watch”收斂成一個公共方法在回調(diào)里統(tǒng)一調(diào)用并且把異常包裹在 try/finally 里保證 Watch 不會因為一次異常就永久丟失。當然更省心的做法是用 Curator 框架的LeaderSelector或PathChildrenCache它內(nèi)部封裝了 Watch 的重注冊邏輯。但如果想真正理解 ZK 選主的原理手工實現(xiàn)一次是值得的。5.4 多賬號場景下的線程模型與連接復用如果同時管理幾百個微信個人號不可能給每個號都建一個獨立的 ZooKeeper 連接。連接太多會耗盡 ZK 的文件描述符和會話資源。正確的做法是一個 ZooKeeper 實例承載所有賬號的選主邏輯不同賬號通過不同的父節(jié)點路徑區(qū)分。但這就帶來一個新的問題ZooKeeper 的 Watcher 回調(diào)線程是共享的。如果一個賬號的選主回調(diào)里做了數(shù)據(jù)庫操作或者網(wǎng)絡請求整個 Watcher 線程都會被阻塞其他賬號的狀態(tài)變化也會延遲處理。我后來把狀態(tài)變更邏輯全部丟進一個獨立的單線程 executor回調(diào)只負責往 executor 里提交任務。這樣賬號 A 的慢操作不會影響賬號 B。同時每個賬號的選主狀態(tài)都隔離在自己的WxAccountLeaderElector對象里公共的僅是 ZK 連接。5.5 監(jiān)控與可觀測性別等漂移發(fā)生了才去救火選主邏輯上線后一定要配監(jiān)控。我至少會暴露這些指標當前賬號的active節(jié)點持有者。候選節(jié)點數(shù)量。主控切換次數(shù)和切換時間。最近一次切換的原因session_expired、node_deleted、active_deleted。日志里每次切換都要帶清晰上下文比如leader changed accountwxid_xxx oldSeq1 oldInstancehost-a newSeq2 newInstancehost-b reasonsession_expired這樣每次發(fā)生漂移我們都能從日志里快速還原當時的網(wǎng)絡情況、實例狀態(tài)而不是靠猜。沒有監(jiān)控的選主邏輯等于把一個分布式炸彈埋在系統(tǒng)里平時看不出來一炸就是大事故。我在實際項目里反復體會到一件事ZooKeeper 只是給了你一個可靠的狀態(tài)源真正決定系統(tǒng)穩(wěn)不穩(wěn)的是所有業(yè)務操作是否嚴格服從“只要不持有 active 節(jié)點就立刻停手”這個紀律。選主代碼反而是整個鏈路里最簡單的一塊難的是讓所有調(diào)用方都統(tǒng)一走同一個門禁。建議先把狀態(tài)機畫清楚再寫代碼會少走非常多彎路。 基于ZooKeeper的在線狀態(tài)漂移檢測與選主實現(xiàn)
1. 先聊清楚微信個人號多設備場景下的“在線狀態(tài)漂移”是什么1.1 多個實例同時工作為什么會產(chǎn)生狀態(tài)分歧如果你搭過微信個人號相關的中臺服務一定遇過這種奇怪現(xiàn)象后臺明明顯示賬號在線消息流水也正常可業(yè)務側(cè)就是反饋漏消息、重復消息。查到最后往往是同一個號被兩個進程同時管理著A 進程剛發(fā)完一條消息B 進程又把它頂下線微信端的在線狀態(tài)像拉鋸一樣來回橫跳。我們內(nèi)部把這種現(xiàn)象叫做“在線狀態(tài)漂移”——主控權從一個實例轉(zhuǎn)移到另一個實例但沒有經(jīng)過雙方確認誰都覺得當前自己才有資格操作這個賬號。這種場景在帶多設備、多進程的 IM 個人號管理系統(tǒng)里非常常見客服工作臺、消息聚合、自動化備份都可能讓同一套憑據(jù)同時暴露給多個節(jié)點。理想情況下同一時間只能有一個實例作為“主控”與微信服務端保持主會話其他實例只做只讀監(jiān)聽或待命。可一旦節(jié)點宕機、網(wǎng)絡抖動、進程僵死主控身份就需要立刻交給另一個實例。關鍵問題是怎么讓大家同時感知到“舊主已失效”并且在新舊交替時不讓消息發(fā)送錯亂。這就是在線狀態(tài)漂移檢測要解決的核心矛盾。1.2 數(shù)據(jù)庫里放一個在線標志位為什么靠不住有人會想在數(shù)據(jù)庫建一張狀態(tài)表online_holdernode_aA 不行了就改成node_b不就行了嗎我一開始也是這么干的后來發(fā)現(xiàn)這條路走不通。第一數(shù)據(jù)庫里存的只是一個靜態(tài)快照。進程是被 kill -9 干掉的數(shù)據(jù)庫不會自動把狀態(tài)改成“離線”只能靠額外的定時任務去心跳清理而心跳本身又會引入新的超時判斷問題。第二多節(jié)點同時讀寫這張表時時序很難控制。A 網(wǎng)絡抖動恢復后可能并不知道 B 已經(jīng)把狀態(tài)改成自己了它只要再往數(shù)據(jù)庫寫一條online_holdernode_a狀態(tài)就又分裂了。第三數(shù)據(jù)庫的更新事務沒法保障“誰真正持有網(wǎng)絡會話”這個事實。會話是長連接數(shù)據(jù)庫狀態(tài)只是一個弱信號兩者沒有強綁定關系最終一定會出現(xiàn)狀態(tài)與事實脫節(jié)。所以我們需要的是一個具備“會話語義”的協(xié)調(diào)組件把進程是否存在、會話是否有效、主控權是否被持有這幾件事天然綁在一起。ZooKeeper 的臨時節(jié)點正好干這個。2. 選型思考為什么是 ZooKeeper而不是 Redis 或 MySQL2.1 臨時節(jié)點天然就是在線狀態(tài)的“心跳探針”ZooKeeper 里有一種節(jié)點叫臨時節(jié)點Ephemeral Node它和客戶端的 ZK 會話綁定?？蛻舳藙?chuàng)建臨時節(jié)點之后如果連接斷開并且超過會話超時時間ZooKeeper 服務端會主動把這個節(jié)點刪除。進程被強殺、機器掉電、長時間網(wǎng)絡隔離都會觸發(fā)同樣的結果節(jié)點自動消失。這個特性幾乎是給“在線狀態(tài)漂移檢測”量身定做的。我們不需要寫清理邏輯去移除僵尸標記也不需要等業(yè)務方手動上報離線。ZK 服務端會替我們做這件事。把“當前主控權”放在一個臨時節(jié)點上等于告訴所有節(jié)點誰能在 ZK 里保住這個節(jié)點誰才有資格繼續(xù)對外操作。這里有個容易忽略的細節(jié)臨時節(jié)點刪除的時機是“會話超時”不是“連接斷開”。客戶端和 ZooKeeper 之間的連接斷開后會話不會立刻失效ZK 服務端會等待一個會話超時時間期間如果網(wǎng)絡恢復客戶端可以重連并繼續(xù)使用同一個會話。這個超時時間是可以配置的后面我會專門講如何避免因為參數(shù)設置不當導致誤漂移。2.2 Watch 機制讓狀態(tài)變化能夠主動通知所有候選節(jié)點ZooKeeper 的另一個關鍵能力是 Watch監(jiān)聽。客戶端可以對某個節(jié)點設置監(jiān)聽節(jié)點創(chuàng)建、刪除、數(shù)據(jù)變化、子節(jié)點變化時ZK 會向客戶端推送一個事件。這樣選主和漂移檢測就可以從“定時輪詢”變成“事件驅(qū)動”。比如每個候選節(jié)點都盯著當前active節(jié)點一旦active節(jié)點消失所有候選中至少有一個會收到通知馬上發(fā)起新一輪選舉。如果換成數(shù)據(jù)庫輪詢就得每隔幾百毫秒查一次狀態(tài)表既慢又費資源而且響應速度還取決于輪詢間隔。當然Watch 是“一次性”的。事件觸發(fā)后監(jiān)聽自動失效如果業(yè)務代碼沒有重新注冊 Watch下一次變化就感知不到了。這是一個非常經(jīng)典的坑后面的實操部分我會給出應對方案。2.3 和 Redis / MySQL / etcd 放在一起看選型時我也對比過其他方案簡單列個表方案會話綁定能力事件通知運維成本適合場景ZooKeeper有臨時節(jié)點綁定會話節(jié)點隨會話失效自動刪除原生 Watch注冊簡單偏高集群需要獨立維護分布式協(xié)調(diào)、選主、分布式鎖Redis沒有會話概念需要自己用 TTL 模擬可用 Pub/Sub 或 Stream但語義弱低簡單緩存鎖、短任務互斥MySQL無狀態(tài)全靠業(yè)務寫無只能輪詢低業(yè)務狀態(tài)存儲etcd有 Lease可綁定節(jié)點續(xù)期有 WatchgRPC 生態(tài)高云原生場景下的選主配置如果你團隊里已經(jīng)有成熟的 ZooKeeper 集群用 ZK 做在線狀態(tài)漂移檢測和選主是最順手的。如果沒運維條件etcd 也完全可以做類似的事但本文重點講 ZooKeeper 的實現(xiàn)思路。3. 在線狀態(tài)漂移檢測與選主的整體設計3.1 節(jié)點模型把賬號狀態(tài)“立”在 ZooKeeper 上我最終采用的節(jié)點結構大概是這樣/wx-accounts /{wxid} /members /m-0000000001 /m-0000000002 /active三層節(jié)點的含義/wx-accounts/{wxid}是持久節(jié)點代表一個微信個人號。/wx-accounts/{wxid}/members是持久節(jié)點用戶存放所有候選實例。/members/m-0000000001是臨時順序節(jié)點。每個實例啟動時都在這里創(chuàng)建一個節(jié)點節(jié)點序號由 ZooKeeper 自動遞增。/wx-accounts/{wxid}/active是臨時節(jié)點由當前主控實例創(chuàng)建。誰創(chuàng)建成功了誰就是主控。active節(jié)點的數(shù)據(jù)里我習慣放一段 JSON{ seq: 1, instanceId: host-a-001, sessionId: 1234567890, activeSince: 1699999999000 }seq就是候選節(jié)點的序號instanceId是本實例的唯一標識sessionId是 ZK 會話 ID。這三個字段一起決定“當前主控是誰”以及“是否發(fā)生了狀態(tài)漂移”。用臨時順序節(jié)點而不是隨機節(jié)點名是有意的節(jié)點序號天然給出了候選者的繼任順序先啟動的實例序號小更容易成為主控中途掛掉后下一個節(jié)點自動頂上不需要再做復雜的優(yōu)先級排序。3.2 選主流程順序節(jié)點 最小序號 Watch 前驅(qū)有了上面的節(jié)點模型選主流程就非常清晰了實例啟動連接 ZooKeeper。確保/wx-accounts/{wxid}和/members持久節(jié)點存在。在/members下創(chuàng)建臨時順序節(jié)點拿到自己的seq。讀取/members下所有子節(jié)點按序號排序。如果自己的序號是最小的嘗試創(chuàng)建/active臨時節(jié)點。創(chuàng)建成功就是主控實例失敗說明已經(jīng)有主控存在那就監(jiān)聽/active。如果自己的序號不是最小那么監(jiān)聽“緊挨著自己前面的那個節(jié)點”。比如當前序是 2就監(jiān)聽序 1 的節(jié)點。當前驅(qū)節(jié)點消失時說明前面的候選退出了立刻重新讀取子節(jié)點重新執(zhí)行選舉。這里的關鍵優(yōu)化是“只監(jiān)聽前驅(qū)節(jié)點”。如果所有候選節(jié)點都監(jiān)聽/active一旦active刪除所有節(jié)點都會收到事件但只有一個能創(chuàng)建成功其他節(jié)點白白競爭會產(chǎn)生驚群效應。通過監(jiān)聽前驅(qū)節(jié)點ZooKeeper 天然給候選人排了隊前面的掛了后面的頂上整個過程非常安靜。選舉完成后非主控節(jié)點還要繼續(xù)監(jiān)聽/active節(jié)點因為如果主控實例進程沒崩但是active節(jié)點被人為刪除或數(shù)據(jù)被改也需要觸發(fā)重新評估。3.3 漂移檢測規(guī)則序號、會話、持有者三者缺一不可在線狀態(tài)漂移檢測的核心不是簡單判斷“有沒有主控”而是判斷“當前主控是不是我”。我總結了三個信號信號一我的候選節(jié)點在/members下是否存在。如果不存在說明我的 ZK 會話可能已經(jīng)過期我失去競選資格。信號二/active節(jié)點是否存在。不存在說明當前沒有主控需要立即選舉。信號三/active節(jié)點里的數(shù)據(jù)是不是我。如果節(jié)點存在但instanceId、sessionId、seq和我本地不一致說明主控權已經(jīng)漂移到了別的實例我必須立刻降級。把這三個信號組合起來看候選節(jié)點存在active 節(jié)點存在active 持有者是我判定結果是是是正常主控繼續(xù)工作是是否候選/待命等待 active 消失是否否沒有主控立即參與選舉否任意任意本實例已失去資格重新登記節(jié)點連接斷開任意任意暫停一切業(yè)務操作等待重連這里最容易被忽略的是“連接斷開”這一行。我在早期實現(xiàn)里犯過錯誤本地進程以為自己還是主控繼續(xù)向微信服務發(fā)送消息但其實 ZooKeeper 里active節(jié)點已經(jīng)因為會話超時被刪除了新的主控已經(jīng)產(chǎn)生于是兩邊同時發(fā)消息造成重復和沖突。正確做法是只要 ZK 客戶端進入Disconnected或Expired狀態(tài)立刻把本地角色降級為SUSPEND停掉所有對外寫操作避免舊主在不知道的情況下繼續(xù)工作。3.4 狀態(tài)機把角色流轉(zhuǎn)寫清楚所有實例都會經(jīng)歷幾個狀態(tài)INIT初始化、CANDIDATE候選、LEADER主控、WAITING等待前驅(qū)、SUSPEND暫停/降級。創(chuàng)建候選節(jié)點成功進入CANDIDATE。CANDIDATE發(fā)現(xiàn)自己是最小序號且成功創(chuàng)建active進入LEADER。CANDIDATE發(fā)現(xiàn)前驅(qū)還在進入WAITING。WAITING收到前驅(qū)節(jié)點刪除事件回到CANDIDATE重新選舉。LEADER如果發(fā)現(xiàn)active節(jié)點消失、數(shù)據(jù)被改、ZK 連接異常進入SUSPEND。SUSPEND重連成功后重新創(chuàng)建候選節(jié)點進入CANDIDATE。把這個狀態(tài)機寫清楚代碼就不容易亂。我在工程里遇到過一些代碼選主邏輯和心跳邏輯混在一起狀態(tài)一多就開始到處改變量最后線上故障時根本分不清當前該算什么態(tài)。后來強行把狀態(tài)流轉(zhuǎn)收斂到一個對象里所有狀態(tài)變更都只由 ZK 事件驅(qū)動再也沒有出現(xiàn)過“看著像主控但其實不是”的混亂窗口。4. Java 落地一套最小可用的選主與漂移檢測實現(xiàn)4.1 環(huán)境與依賴準備我用 Java 原生客戶端做了一版可運行的最小實現(xiàn)。先加依賴dependency groupIdorg.apache.zookeeper/groupId artifactIdzookeeper/artifactId version3.8.4/version /dependency本地起一個單節(jié)點 ZooKeeper 就夠了測試時用bin/zkServer.sh start啟動服務默認端口2181。生產(chǎn)環(huán)境建議起三節(jié)點集群但選主邏輯本身不需要區(qū)分單機還是集群。核心類我命名為WxAccountLeaderElector字段包括private final ZooKeeper zk; private final String wxid; private final String instanceId; private final String membersPath; private final String activePath; private String candidatePath; private long localSeq; private volatile boolean isLeader false;instanceId用來標識本機實例比如host-a-001。后面判斷active節(jié)點是否為本人持有全靠它。4.2 候選注冊創(chuàng)建臨時順序節(jié)點實例啟動的第一步是創(chuàng)建候選節(jié)點。這個過程相當于向 ZooKeeper 喊一句“我來了請給我排個號”。public void start() throws Exception { ensureParentNode(); registerCandidate(); evaluateLeader(); } private void ensureParentNode() throws Exception { if (zk.exists(/wx-accounts, false) null) { zk.create(/wx-accounts, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } if (zk.exists(/wx-accounts/ wxid, false) null) { zk.create(/wx-accounts/ wxid, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } String path /wx-accounts/ wxid /members; if (zk.exists(path, false) null) { zk.create(path, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } } private void registerCandidate() throws Exception { String data String.format({\instanceId\:\%s\,\pid\:%d,\startTime\:%d}, instanceId, ProcessHandle.current().pid(), System.currentTimeMillis()); candidatePath zk.create(membersPath /m-, data.getBytes(StandardCharsets.UTF_8), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); localSeq Long.parseLong(candidatePath.substring(candidatePath.lastIndexOf(-) 1)); }這里創(chuàng)建的是EPHEMERAL_SEQUENTIAL節(jié)點它既具備臨時節(jié)點的自動刪除特性又能得到一個全局遞增的序號。所有候選節(jié)點按照創(chuàng)建順序排成一條隊序號越小優(yōu)先級越高。4.3 選主與漂移監(jiān)聽核心邏輯選主邏輯在evaluateLeader方法里。每次 ZK 事件觸發(fā)都會重新評估當前角色。private void evaluateLeader() throws Exception { if (zk.getState() ! ZooKeeper.States.CONNECTED) { markFence(); return; } ListString children zk.getChildren(membersPath, true); ListLong seqs children.stream() .map(p - Long.parseLong(p.substring(p.lastIndexOf(-) 1))) .sorted() .collect(Collectors.toList()); if (seqs.isEmpty()) { return; } long minSeq seqs.get(0); if (minSeq localSeq) { tryAcquireActive(); } else { long prevSeq seqs.get(seqs.indexOf(localSeq) - 1); String prevPath membersPath /m- prevSeq; if (zk.exists(prevPath, event - { if (event.getType() EventType.NodeDeleted) { try { evaluateLeader(); } catch (Exception e) { log.error(重新選舉失敗, e); } } }) null) { evaluateLeader(); } } }注意zk.exists(prevPath, ...)這一步注冊的是針對前驅(qū)節(jié)點的 Watch。事件回調(diào)只在NodeDeleted時觸發(fā)觸發(fā)后重新執(zhí)行evaluateLeader這樣當前實例就能從前驅(qū)消失的狀態(tài)中立刻感知到主控權發(fā)生了漂移。下一步是嘗試創(chuàng)建active節(jié)點也就是搶主控private void tryAcquireActive() throws Exception { String data String.format({\seq\:%d,\instanceId\:\%s\,\sessionId\:%d}, localSeq, instanceId, zk.getSessionId()); try { zk.create(activePath, data.getBytes(StandardCharsets.UTF_8), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL); isLeader true; log.info(成為主控實例seq{}, instance{}, localSeq, instanceId); zk.exists(activePath, event - { if (event.getType() EventType.NodeDeleted) { try { evaluateLeader(); } catch (Exception e) { log.error(active 節(jié)點消失重新選舉失敗, e); } } }); } catch (KeeperException.NodeExistsException e) { log.info(active 已存在當前不是主控進入等待狀態(tài)); isLeader false; zk.exists(activePath, event - { if (event.getType() EventType.NodeDeleted) { try { evaluateLeader(); } catch (Exception ex) { log.error(重新選舉失敗, ex); } } }); } }當active創(chuàng)建成功isLeader置為true。但“創(chuàng)建成功”只代表那一瞬間我是主控不代表我一直是。所以每次對外執(zhí)行任務前還要做一次漂移校驗確保主控權沒有在后臺悄悄溜走。4.4 發(fā)送消息前的主控權校驗我在實際工程里寫了一個方法所有對外操作都必須走這一層門禁public boolean checkLeadership() { if (!isLeader) { return false; } if (zk.getState() ! ZooKeeper.States.CONNECTED) { resign(); return false; } try { Stat stat new Stat(); byte[] raw zk.getData(activePath, false, stat); ActiveInfo info ActiveInfo.fromJson(raw); boolean mine info.seq localSeq info.instanceId.equals(instanceId) info.sessionId zk.getSessionId(); if (!mine) { resign(); return false; } return true; } catch (KeeperException.NoNodeException e) { resign(); return false; } catch (Exception e) { return false; } } private void resign() { isLeader false; log.warn(檢測到在線狀態(tài)漂移或主控權丟失當前實例已降級); }這里最關鍵的一點是除了比對instanceId還要比對sessionId。因為 ZK 會話過期后客戶端重連會得到一個全新的sessionId即使instanceId相同它也不是原來的會話。單獨比對instanceId是不夠的。任務執(zhí)行時可以這樣統(tǒng)一約束public boolean executeIfLeader(Runnable task) { if (!checkLeadership()) { log.warn(非主控或主控已漂移拒絕執(zhí)行任務); return false; } task.run(); return true; }嚴格來說這個校驗屬于“操作前檢查”。在分布式環(huán)境下舊主可能已經(jīng)和新主同時工作消息帶一個 fencing token 會更安全。seq就是天然的 token每一次選主都會產(chǎn)生更大的序號下游服務只需要拒絕 token 小于當前主控序號的請求就能避免舊主消息造成數(shù)據(jù)沖突。4.5 運行效果漂移檢測到底能檢測到什么假設我同時啟動兩個實例A和BA 啟動創(chuàng)建/members/m-0000000001成功創(chuàng)建/activeA 成為主控。B 啟動創(chuàng)建/members/m-0000000002發(fā)現(xiàn)最小序號不是自己于是 watchm-1進入等待狀態(tài)。我手動 kill 掉 A 進程。ZK 檢測到 A 的會話結束臨時節(jié)點m-1和/active自動刪除。B 收到前驅(qū)節(jié)點刪除事件重新執(zhí)行evaluateLeader發(fā)現(xiàn)自己是當前最小序號創(chuàng)建active成功B 成為新主控。我重新啟動 A。A 創(chuàng)建/members/m-0000000003發(fā)現(xiàn)最小序號是 B于是 watchm-2進入等待。整個過程里B 的日志會出現(xiàn)一行“成為主控實例”A 重啟后不會有任何任務權限直到 B 再次故障。這就是一次標準的在線狀態(tài)漂移檢測和選主切換。5. 實戰(zhàn)中踩過的坑故障排查與避坑清單5.1 網(wǎng)絡抖動引發(fā)的會話超時誤判我在測試環(huán)境第一次上線這套邏輯時用的是 5 秒會話超時。結果機房一次輕微的網(wǎng)絡抖動把所有實例全部踢下線觸發(fā)了一次完全沒必要的選主切換。原因是 ZooKeeper 的臨時節(jié)點刪除機制基于會話超時不是基于連接斷開。網(wǎng)絡抖動后ZK 服務端暫時聯(lián)系不上客戶端如果超時設得太短服務端會認為客戶端死了直接刪除臨時節(jié)點?？蛻舳司W(wǎng)絡恢復后發(fā)現(xiàn)自己創(chuàng)建的節(jié)點已經(jīng)沒了只能重新注冊。我的建議是把 ZK 客戶端構造參數(shù)里的sessionTimeout設置為 20 到 30 秒具體數(shù)值取決于業(yè)務對“主控恢復速度”和“誤判容忍度”的權衡。如果業(yè)務可以容忍 30 秒沒有主控就設 30 秒如果希望秒級切換那就要接受網(wǎng)絡抖動帶來的誤判風險。同時客戶端收到Disconnected事件時不要等 ZK 告訴你“節(jié)點已刪除”自己要先主動標記為SUSPEND暫停所有對外寫操作。這樣即使 ZK 側(cè)還沒判定會話超時業(yè)務側(cè)也不會因為舊主繼續(xù)工作而產(chǎn)生重復信息。5.2 舊進程僵尸化帶來的雙主窗口真正危險的場景不是進程被 kill而是舊主進程還活著但它和 ZooKeeper 之間的網(wǎng)絡被切斷了。這時候從 ZK 的視角看舊主已經(jīng)因為會話超時而退出新主成功上位但舊主進程還保存著“我是主控”的本地狀態(tài)它仍然能訪問微信服務端繼續(xù)發(fā)消息。兩個主同時存在就成了雙主窗口。這個問題不能單靠 ZooKeeper 解決。ZooKeeper 只能保證“在 ZK 內(nèi)部狀態(tài)一致”不能保證“在業(yè)務網(wǎng)絡里也一致”。我最后的處理方法是兩層配合客戶端收到Disconnected時立刻拒絕所有本地任務不等待 ZK 判定。業(yè)務消息里帶上 fencing token也就是active節(jié)點里的seq。下游服務只接受當前主控的 token。如果你能把 token 校驗下沉到消息網(wǎng)關雙主問題能基本被攔住。舊主發(fā)出來的 token 已經(jīng)比新主小網(wǎng)關直接拒絕比舊主自己“猜”自己是不是主控要可靠得多。5.3 Watch 只觸發(fā)一次重連后通知丟失ZooKeeper 的 Watch 是一次性的。最開始我寫代碼時只在初始化時注冊了一次exists后面發(fā)現(xiàn)節(jié)點變化后程序完全沒有反應。排了半天才發(fā)現(xiàn)事件觸發(fā)后 Watch 就失效了如果不重新注冊下一次變化永遠感知不到。更隱蔽的是在回調(diào)里重新執(zhí)行evaluateLeader時getChildren(membersPath, true)會注冊一個新的 Watch但如果你在某條分支里調(diào)了zk.exists(prevPath, watcher)這次注冊也是獨立的別忘記在對應回調(diào)里再次注冊。我建議把“重新評估 重新注冊 Watch”收斂成一個公共方法在回調(diào)里統(tǒng)一調(diào)用并且把異常包裹在 try/finally 里保證 Watch 不會因為一次異常就永久丟失。當然更省心的做法是用 Curator 框架的LeaderSelector或PathChildrenCache它內(nèi)部封裝了 Watch 的重注冊邏輯。但如果想真正理解 ZK 選主的原理手工實現(xiàn)一次是值得的。5.4 多賬號場景下的線程模型與連接復用如果同時管理幾百個微信個人號不可能給每個號都建一個獨立的 ZooKeeper 連接。連接太多會耗盡 ZK 的文件描述符和會話資源。正確的做法是一個 ZooKeeper 實例承載所有賬號的選主邏輯不同賬號通過不同的父節(jié)點路徑區(qū)分。但這就帶來一個新的問題ZooKeeper 的 Watcher 回調(diào)線程是共享的。如果一個賬號的選主回調(diào)里做了數(shù)據(jù)庫操作或者網(wǎng)絡請求整個 Watcher 線程都會被阻塞其他賬號的狀態(tài)變化也會延遲處理。我后來把狀態(tài)變更邏輯全部丟進一個獨立的單線程 executor回調(diào)只負責往 executor 里提交任務。這樣賬號 A 的慢操作不會影響賬號 B。同時每個賬號的選主狀態(tài)都隔離在自己的WxAccountLeaderElector對象里公共的僅是 ZK 連接。5.5 監(jiān)控與可觀測性別等漂移發(fā)生了才去救火選主邏輯上線后一定要配監(jiān)控。我至少會暴露這些指標當前賬號的active節(jié)點持有者。候選節(jié)點數(shù)量。主控切換次數(shù)和切換時間。最近一次切換的原因session_expired、node_deleted、active_deleted。日志里每次切換都要帶清晰上下文比如leader changed accountwxid_xxx oldSeq1 oldInstancehost-a newSeq2 newInstancehost-b reasonsession_expired這樣每次發(fā)生漂移我們都能從日志里快速還原當時的網(wǎng)絡情況、實例狀態(tài)而不是靠猜。沒有監(jiān)控的選主邏輯等于把一個分布式炸彈埋在系統(tǒng)里平時看不出來一炸就是大事故。我在實際項目里反復體會到一件事ZooKeeper 只是給了你一個可靠的狀態(tài)源真正決定系統(tǒng)穩(wěn)不穩(wěn)的是所有業(yè)務操作是否嚴格服從“只要不持有 active 節(jié)點就立刻停手”這個紀律。選主代碼反而是整個鏈路里最簡單的一塊難的是讓所有調(diào)用方都統(tǒng)一走同一個門禁。建議先把狀態(tài)機畫清楚再寫代碼會少走非常多彎路。