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