Nacos 客戶端本地緩存與 Redo 機(jī)制完全指南故障切換、監(jiān)聽恢復(fù)與重連意圖重放【免費(fèi)下載鏈接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/na/nacos導(dǎo)讀本文深入解析 Nacos 客戶端 SDK 的本地?cái)?shù)據(jù)分層、Config 本地故障切換failover與快照snapshot恢復(fù)、Naming 本地緩存與 failover 視圖、以及連接斷開重連后的 redo重放模型并完整覆蓋面向 Agent/RAD 的新一代恢復(fù)契約。讀者將掌握 Nacos 客戶端在服務(wù)器不可用或網(wǎng)絡(luò)抖動(dòng)時(shí)的可用性保障原理、各類本地?cái)?shù)據(jù)的權(quán)威性邊界以及如何通過配置項(xiàng)如nacosAiAgentEndpointMaxPublications、nacosAiAgentDiscoveryMaxSubscriptions精確控制本地緩存行為。本文是客戶端運(yùn)行時(shí)規(guī)范中恢復(fù)部分的展開實(shí)現(xiàn)說明并與運(yùn)行時(shí)推送與重連規(guī)范互為補(bǔ)充。全部結(jié)論均有對應(yīng)源碼佐證主要位于client/src/main/java/com/alibaba/nacos/client/下。1. 本地?cái)?shù)據(jù)分類先分清權(quán)威與派生Nacos 客戶端進(jìn)程在運(yùn)行期間會(huì)維護(hù)多類本地?cái)?shù)據(jù)它們的來源、目的與權(quán)威性各不相同。規(guī)范中給出了一張關(guān)鍵分類表數(shù)據(jù)類型來源目的權(quán)威性Config failover file用戶維護(hù)的本地文件已知 Config item 的緊急覆蓋最高本地讀取優(yōu)先級(jí)但不會(huì)自動(dòng)寫回服務(wù)端Config snapshot服務(wù)端查詢響應(yīng)用于讀取 fallback 的最后已知 Config content 和 encrypted data key僅恢復(fù)緩存Config listener stateSDK listener 注冊跟蹤已知 group key、listener MD5 和 fuzzy watch 狀態(tài)僅運(yùn)行時(shí)意圖Naming service-info cache服務(wù)端 push 或 query response訂閱或查詢服務(wù)的最后已知實(shí)例僅恢復(fù)緩存Naming failover data用戶或擴(kuò)展提供的本地 failover sourcefailover switch 開啟時(shí)覆蓋 discovery view僅本地 discovery overrideRedo dataSDK register、subscribe 或 endpoint 操作reconnect 后恢復(fù)運(yùn)行時(shí)意圖僅運(yùn)行時(shí)意圖RAD 發(fā)現(xiàn)與 Watch 狀態(tài)目標(biāo)Discover 結(jié)果或 Watch 注冊最后一個(gè)完整 Agent 發(fā)現(xiàn)快照和 Watch 意圖僅恢復(fù)緩存和運(yùn)行時(shí)意圖核心原則除用戶顯式維護(hù)的 failover 文件外其余本地?cái)?shù)據(jù)都是派生數(shù)據(jù)derived data它們來自客戶端意圖或服務(wù)端響應(yīng)絕不代表服務(wù)端已提交的權(quán)威狀態(tài)。這也與客戶端運(yùn)行時(shí)規(guī)范中運(yùn)行時(shí)數(shù)據(jù)默認(rèn)是派生數(shù)據(jù)的設(shè)計(jì)規(guī)則一致。唯一例外是用戶手動(dòng)放置的 failover 文件——它可以臨時(shí)覆蓋遠(yuǎn)端讀取視圖但本身永遠(yuǎn)不會(huì)被客戶端自動(dòng)寫回服務(wù)端。2. Config 本地恢復(fù)failover 文件與 snapshot 的讀取優(yōu)先級(jí)Config 讀取遵循嚴(yán)格的三級(jí)優(yōu)先級(jí)用戶維護(hù)的本地 failover 文件優(yōu)先級(jí)最高服務(wù)端查詢本地 snapshot僅作最后回退。2.1 failover 文件緊急場景的手動(dòng)救生索failover 文件不會(huì)由客戶端自動(dòng)創(chuàng)建它只適用于緊急場景當(dāng) Nacos server 不可用、或遠(yuǎn)端變更不安全例如灰度事故、配置損壞時(shí)應(yīng)用仍需要依靠本地覆蓋來啟動(dòng)或繼續(xù)運(yùn)行。由于它是最高本地讀取優(yōu)先級(jí)只要文件存在客戶端讀取配置時(shí)就會(huì)直接命中本地內(nèi)容而不再依賴網(wǎng)絡(luò)。從源碼看failover 文件的目錄結(jié)構(gòu)由LocalConfigInfoProcessor定義LocalConfigInfoProcessor.java${user.home}/nacos/config/{serverName}_nacos/data/config-data/{group}/{dataId} # 無租戶非 namespace ${user.home}/nacos/config/{serverName}_nacos/data/config-data-tenant/{tenant}/{group}/{dataId} # 有租戶其中serverName為環(huán)境名超長時(shí)會(huì)經(jīng)過simplyEnvNameIfOverLimit截?cái)郷nacos為固定后綴data與config-data/config-data-tenant分別對應(yīng) failover 的子目錄層級(jí)。getFailover(serverName, dataId, group, tenant)方法負(fù)責(zé)定位并讀取該文件文件不存在或讀取異常時(shí)返回null。2.2 snapshot服務(wù)端查詢成功的副產(chǎn)品snapshot 與 failover 的行為正好相反snapshot 在服務(wù)端查詢成功后寫入磁盤并在服務(wù)端確認(rèn)該 Config item 不存在時(shí)刪除。它保存的是最后已知的配置內(nèi)容供服務(wù)端完全不可達(dá)時(shí)作為讀取 fallback。snapshot 的目錄結(jié)構(gòu)同樣由LocalConfigInfoProcessor定義${user.home}/nacos/config/{envName}_nacos/snapshot/{group}/{dataId} # 無租戶 ${user.home}/nacos/config/{envName}_nacos/snapshot-tenant/{tenant}/{group}/{dataId} # 有租戶對應(yīng)源碼方法為saveSnapshot(...)寫入或刪除、getSnapshot(...)讀取且受SnapShotSwitch.getIsSnapShot()全局開關(guān)控制與cleanAllSnapshot()/cleanEnvSnapshot(...)清理。規(guī)范還強(qiáng)調(diào)兩個(gè)實(shí)現(xiàn)細(xì)節(jié)Encrypted data key snapshot 與 content snapshot 分開存儲(chǔ)由LocalEncryptedDataKeyProcessor獨(dú)立管理避免密鑰與內(nèi)容耦合在同一文件中Config filter包括 encryption filter在選定本地或遠(yuǎn)端 content 之后才執(zhí)行即過濾邏輯不參與選哪份數(shù)據(jù)的決策只負(fù)責(zé)對最終選定的 content 做后處理。2.3 listener 與 failover 的聯(lián)動(dòng)Config listener 在發(fā)送 listener check即與服務(wù)端比對 MD5 的檢查請求之前必須檢查本地 failover 文件。當(dāng) failover 文件出現(xiàn)、內(nèi)容變化或消失時(shí)必須同步更新 listener state并可以按CacheData的 MD5 規(guī)則觸發(fā) listener callback。這一規(guī)則在 CacheData.java 中可以看到直接實(shí)現(xiàn)checkListenerMd5()中首先調(diào)用LocalConfigInfoProcessor.getFailover(name, dataId, group, tenant)獲取 failover 內(nèi)容而CacheData內(nèi)部維護(hù)md5字段與每個(gè) listener 的lastCallMd5ManagerListenerWrap當(dāng)md5.equals(wrap.lastCallMd5)不成立時(shí)才會(huì)觸發(fā)safeNotifyListener回調(diào)從而保證failover 變化 → MD5 變化 → listener 感知的鏈路成立。3. Config Listener 與 Fuzzy Watch 恢復(fù)讀意圖的 resyncConfig gRPC client 會(huì)注冊三類服務(wù)端通知 handlerConfig change notification配置變更通知client metrics request客戶端指標(biāo)請求fuzzy watch notification模糊監(jiān)聽通知。連接建立時(shí)客戶端必須主動(dòng)向服務(wù)端通知 listen context 和 fuzzy watch context使已知訂閱重新同步連接斷開時(shí)必須把受影響的CacheDataentry 和 fuzzy watch context 標(biāo)記為與服務(wù)端不一致。需要特別強(qiáng)調(diào)的是Config listener recovery 不是寫操作 redo而是讀/監(jiān)聽運(yùn)行時(shí)意圖的 resync——它恢復(fù)的是我關(guān)心哪些配置、我對它們的 MD5 認(rèn)知是什么而不是重新發(fā)布任何配置。這與第 7 節(jié)中Client SDK 不會(huì)自動(dòng) redo Config publish/delete 操作的約束相呼應(yīng)。4. Naming 本地緩存service-info cache 的恢復(fù)輔助定位Naming 側(cè)維護(hù)一個(gè)按grouped service name clusters維度的ServiceInfo內(nèi)存緩存。服務(wù)端 push 或 query response 會(huì)更新這塊內(nèi)存 map并在實(shí)例視圖變化時(shí)寫入磁盤緩存該邏輯由client/src/main/java/com/alibaba/nacos/client/naming/cache/ServiceInfoHolder.java承擔(dān)push 路徑入口為 NamingPushRequestHandler.java它收到 notify 后調(diào)用serviceInfoHolder.processServiceInfo(...)更新視圖。該緩存是恢復(fù)輔助其行為邊界為load-cache 選項(xiàng)開啟時(shí)可在啟動(dòng)時(shí)加載從磁盤緩存恢復(fù)最后已知視圖加速首次啟動(dòng)網(wǎng)絡(luò)中斷時(shí)可提供臨時(shí) discovery view保證應(yīng)用在斷網(wǎng)窗口內(nèi)仍能拿到最后已知的實(shí)例列表不得創(chuàng)建、更新或刪除 Naming 服務(wù)端資源——緩存只是快照絕不是管理面。此外Push-empty protection空推送保護(hù)允許客戶端忽略空或無效的 push避免把一份已知可用的視圖意外替換成空視圖。這是針對服務(wù)端抖動(dòng)期誤報(bào)空列表的一種防御性設(shè)計(jì)防止客戶端實(shí)例列表被錯(cuò)誤清空導(dǎo)致流量打掛。5. Naming Failover 視圖本地 discovery overrideNaming failover 是本地 discovery override當(dāng) failover switch 開啟且某服務(wù)存在有效 failover data 時(shí)SDK 返回 failover view而不是正常的 server-driven view。它提供的數(shù)據(jù)源由用戶或擴(kuò)展如本地文件、環(huán)境變量注入提供。關(guān)鍵聯(lián)動(dòng)規(guī)則failover switch 或 failover data 變化導(dǎo)致可見實(shí)例集合變化時(shí)應(yīng)發(fā)布 instance-change event讓訂閱方感知到視圖已被本地覆蓋failover 關(guān)閉后SDK 恢復(fù)返回正常緩存的服務(wù)端視圖如果可見視圖因此變化也要通知 listener保證訂閱方最終收斂到真實(shí)服務(wù)端狀態(tài)Naming failover 不得被用作服務(wù)端數(shù)據(jù)修復(fù)機(jī)制——它只是客戶端本地應(yīng)急手段服務(wù)端數(shù)據(jù)缺失應(yīng)由運(yùn)維在服務(wù)端側(cè)修復(fù)而不是靠客戶端長期頂著 failover 視圖運(yùn)行。6. Redo 模型重連后恢復(fù)運(yùn)行時(shí)意圖的通用抽象6.1 Redo data 記錄什么Redo重放用于連接丟失并重新建立后恢復(fù)運(yùn)行時(shí)意圖。每條 Redo data 記錄四類信息期望最終狀態(tài)例如 registered最終應(yīng)注冊或 unregistered最終應(yīng)注銷數(shù)據(jù)是否已在上一個(gè) connection 上成功注冊是否正在執(zhí)行 unregister重放操作所需的領(lǐng)域 payload如實(shí)例信息、訂閱信息、Endpoint 批次。6.2 源碼中的狀態(tài)機(jī)這四類信息在 RedoData.java 中被建模為三個(gè) volatile 布爾狀態(tài)加一個(gè)泛型 payloadprivate volatile boolean expectedRegistered; // 期望最終狀態(tài)true最終應(yīng)注冊false最終應(yīng)注銷 private volatile boolean registered; // 是否已在上一個(gè)連接成功注冊 private volatile boolean unregistering; // 是否正在執(zhí)行 unregister private T data; // 重放所需的領(lǐng)域 payload由這三個(gè)狀態(tài)可以推導(dǎo)出四種 RedoType見源碼getRedoType()的完整注釋registeredunregisteringRedoType語義truefalseNONE期望注冊或UNREGISTER期望注銷已注冊且不需要注銷 → 無事可做truetrueUNREGISTER已注冊、現(xiàn)在需要注銷falsefalseREGISTER尚未注冊 → 需要再次注冊falsetrueREGISTER期望注冊或REMOVE期望注銷未注冊且不再繼續(xù) → 移除過期 redo data6.3 Redo operation 清單與執(zhí)行前提Redo operation 包括四類動(dòng)作再次 register再次 unregister移除過期 redo data當(dāng)當(dāng)前運(yùn)行時(shí)意圖已經(jīng)滿足時(shí)不執(zhí)行操作即 RedoType 為NONE時(shí)跳過。Redo task 僅能在運(yùn)行時(shí)連接已連接時(shí)執(zhí)行。連接斷開時(shí)所有已注冊的 redo data 必須被標(biāo)記為未注冊setRegistered(false)使下一次 connected period 可以修復(fù)服務(wù)端掛載狀態(tài)。這一行為在 AbstractRedoService.java 的onDisConnect(Connection)回調(diào)中直接實(shí)現(xiàn)遍歷redoDataMap中所有 redo data 并統(tǒng)一setRegistered(false)隨后由ScheduledThreadPoolExecutor按redoDelayTime周期scheduleWithFixedDelay驅(qū)動(dòng)AbstractRedoTask執(zhí)行重放。此外該類還暴露了cachedRedoData、removeRedoData、dataRegistered、dataDeregister、dataDeregistered、isDataRegistered、findRedoData等完整的狀態(tài)管理 API并實(shí)現(xiàn)ConnectionEventListener接口以感知連接事件。7. 領(lǐng)域 Redo 規(guī)則Config / Naming / AI 各自的重放邊界7.1 Naming redo 覆蓋范圍Naming redo 覆蓋四類運(yùn)行時(shí)意圖臨時(shí)實(shí)例注冊批量臨時(shí)實(shí)例注冊服務(wù)訂閱fuzzy watch 一致性狀態(tài)。對應(yīng)源碼為client/src/main/java/com/alibaba/nacos/client/naming/remote/gprc/redo/data/下的 InstanceRedoData.java、BatchInstanceRedoData.java 與 SubscriberRedoData.java它們都繼承自NamingRedoDataT記錄 serviceName groupName再繼承通用RedoDataT。特別地持久 Naming service 狀態(tài)由服務(wù)端持有。除非領(lǐng)域規(guī)范明確把某個(gè)操作視為運(yùn)行時(shí)意圖否則不應(yīng)由客戶端 redo 恢復(fù)——客戶端重放只針對臨時(shí)、會(huì)隨連接消失而消失的掛載狀態(tài)臨時(shí)實(shí)例、訂閱持久服務(wù)元數(shù)據(jù)屬于服務(wù)端權(quán)威數(shù)據(jù)。7.2 AI redo 覆蓋范圍AI redo 覆蓋運(yùn)行時(shí) endpoint 和 subscription intent例如 MCP 或 Agent Endpoint 注冊。其實(shí)現(xiàn)位于client/src/main/java/com/alibaba/nacos/client/ai/remote/redo/下包括AiGrpcRedoService、AiRedoScheduledTask、AgentEndpointRedoData、AgentEndpointPublicationRedoData、McpServerEndpointRedoData等類。AIresource publish/delete 語義仍由 AI Registry 規(guī)范約束——即資源的發(fā)布/刪除屬于資源生命周期管理不在客戶端 redo 范疇內(nèi)客戶端 redo 只負(fù)責(zé)恢復(fù)運(yùn)行時(shí)掛載意圖。7.3 Config 不 redo 寫操作Config listener 通過listener resync 和 fuzzy watch resync恢復(fù)見第 3 節(jié)。Client SDK 不會(huì)自動(dòng) redo Config publish/delete 操作——配置發(fā)布是管理動(dòng)作不是客戶端運(yùn)行時(shí)意圖。8. Agent 與 RAD 目標(biāo)恢復(fù)契約本節(jié)定義新 Agent/RAD SDK 的恢復(fù)契約。gRPC 路徑在 Agent API 規(guī)范中的 Agent/RAD 能力完成協(xié)商后生效HTTP 路徑使用同一份本地期望狀態(tài)但不依賴 gRPC ability。注意首版 Nacos HTTP Binding 支持 Discover 但不支持 Watch見運(yùn)行時(shí)推送與重連規(guī)范。8.1 Endpoint 發(fā)布 Redo 身份SDK 按Publication 身份維護(hù)期望 Endpoint 發(fā)布狀態(tài)并保存重放所需的完整 Batch Payload。Redo key 固定為(namespaceId, agentName, protocol)該 key 的生成邏輯在 AgentEndpointPublicationRedoData.java 的keyOf(namespaceId, agentName, protocol)中實(shí)現(xiàn)復(fù)用 Naming 的可讀分隔符拼接三段身份由于校驗(yàn)過的 namespace 和 protocol 都拒絕字符即使 agentName 包含首尾分隔符邊界依然無歧義。每個(gè) key 只保存一份完整AgentEndpointRegistrationBatch。語義約束如下Register先復(fù)制并校驗(yàn)全部 Endpoint再以提交的完整 Batch原子替換舊記錄不合并 Endpoint upsert。runtimeVersion、versionRange和全部 Endpoint payload 都屬于記錄內(nèi)容后一次 Register 可以完整更換它們Deregister按 Endpoint 自然鍵從這份期望 Batch 中刪除成員。仍有 Endpoint 時(shí)SDK 通過 Register 發(fā)送完整剩余 Batch沒有 Endpoint 時(shí)發(fā)送整份 Publication 注銷并清除成功完成的期望記錄Redo Payload 必須保留 URI、Priority、Weight 和 Metadata 等完整公開值不能為了省流量只保留部分字段——否則重放后的 Endpoint 會(huì)丟失原始注冊信息。8.2 HTTP 與 gRPC Publisher 恢復(fù)Transport 隔離與 owner 歸屬HTTP Agent Publisher 為一個(gè) SDK 實(shí)例生成一個(gè)X-Nacos-Client-Id。在該 SDK 實(shí)例生命周期內(nèi)這個(gè) Id 在請求重試、Server 切換、故障轉(zhuǎn)移、Heartbeat 和 Redo 時(shí)保持穩(wěn)定進(jìn)程重啟后生成新 Id因?yàn)?HTTP Client 身份本質(zhì)上是進(jìn)程級(jí)的。關(guān)鍵恢復(fù)規(guī)則任一 Agent Endpoint 請求返回HTTP_CLIENT_NOT_FOUND時(shí)SDK 將該 HTTP Client 擁有的全部Endpoint redo record 標(biāo)記為未注冊并 redo 每個(gè)完整期望 Publication 分組。只重試失敗的那一個(gè) Endpoint 是不充分的——因?yàn)?Server 已經(jīng)聲明整個(gè) HTTP Client 狀態(tài)不存在其余 Endpoint 實(shí)際上也丟了gRPC Endpoint 意圖歸屬于當(dāng)前 connection id。Reconnect 后SDK 獲取新的 connection id把舊 Connection 的全部 Endpoint redo record 標(biāo)記為未注冊并在新 Connection 下重放完整期望分組HTTP 與 gRPC Publisher record 必須隔離一種 Transport 不得注銷另一種 Transport 擁有的 Contribution。AUTOTransport 的 owner 選擇當(dāng) Agent Transport 為AUTO時(shí)Publication 首次準(zhǔn)備發(fā)送前選擇并緩存ownerTransport。同一(namespaceId, agentName, protocol)的后續(xù)完整 Batch 替換、部分注銷、整份注銷、HTTP Heartbeat 和 Redo 均使用該 owner。Client 可以同時(shí)持有由 HTTP 和 gRPC 分別擁有的不同 Publication但不得因?yàn)檫B接狀態(tài)變化遷移一個(gè)已存在 Publication 的 owner也不得讓 HTTP maintenance 處理 gRPC-owned record——owner 一經(jīng)選定即固定直到該 Publication 生命周期結(jié)束。Publication 軟水位SDK 默認(rèn)對全部已保留完整 Publication Batch 中的 Runtime Endpoint 條目使用100 的軟水位可通過nacosAiAgentEndpointMaxPublications配置。行為語義為一次原子 Register 前的條目數(shù)低于水位時(shí)SDK 整批保留已校驗(yàn) Batch即使完成后越過水位允許超量完成已達(dá)到或超過水位時(shí)仍允許等量替換或縮容但拒絕新 Batch 或擴(kuò)容 Batch且不發(fā)生局部緩存修改Server 獨(dú)立執(zhí)行權(quán)威的每 Client 軟水位客戶端水位是本地提前攔截命中本地或遠(yuǎn)程 Publication 容量限制屬于終止性寫失敗SDK 從 Publication Manager 與 gRPC Redo Cache 移除被拒絕的身份HTTP Maintenance 不再 Heartbeat 或重試它其他瞬時(shí) 5xx Transport 失敗繼續(xù)使用既有 Rollback 和 Redo 語義可重試。8.3 本地輪詢訂閱身份首版無 Watch首版 SDK不創(chuàng)建服務(wù)端 Watch也不保存 Connection 維度watchKey。規(guī)范化本地輪詢訂閱 Key 包含(namespaceId, canonicalAgentReference, canonicalFilter, listenerIdentity)規(guī)范化語義要點(diǎn)Reference 規(guī)范化保持精確 Version、Label 和 Latest 之間的區(qū)別三者是不同身份不能混同F(xiàn)ilter 的集合和 Map 內(nèi)容用于值相等比較即順序無關(guān)、按值比較Listener identity是取消訂閱時(shí)使用的同一 Listener 實(shí)例對象身份一致SDK周期執(zhí)行相同 DiscovergRPC reconnect 不增加訂閱 redo因?yàn)橄乱淮屋喸冏匀皇褂眯逻B接目標(biāo)不存在時(shí)保留輪詢但不投遞空快照避免把不存在誤報(bào)為空結(jié)果解析出的 Version、contentDigest或任一sourceRevision改變時(shí)SDK原子替換緩存并投遞完整結(jié)果。訂閱容量軟水位本地輪詢 Cache 默認(rèn)最多保留300個(gè)不同的規(guī)范化訂閱 Key可通過nacosAiAgentDiscoveryMaxSubscriptions配置。超限訂閱必須在首次 Discover、緩存插入和調(diào)度提交前失敗重復(fù) Subscribe 保持冪等Unsubscribe 或 Shutdown 釋放容量。當(dāng)前 API 每次調(diào)用只安裝一個(gè) Key后續(xù)任何批量 Watch Cache 修改都必須使用操作前軟水位水位以下整批保留規(guī)范化結(jié)果已達(dá)水位時(shí)無局部插入地拒絕增長。需要明確的是運(yùn)行時(shí)推送與重連規(guī)范定義的服務(wù)端 Watch/Push 是獨(dú)立后續(xù)契約實(shí)現(xiàn)該契約前必須先更新 Agent API、能力位和傳輸 Payload不能從本地輪詢身份推導(dǎo) Wire Watch state。8.4 舊 A2A 兼容恢復(fù)對于 namespace-boundA2aService的舊 Version-specific Endpoint Publication使用(agentName, exactVersion)作為本地 redo 身份不同精確 Version 不得相互覆蓋Redo record 保存 Endpoint 集合及其 URI、transport、metadata 等字段的防御性快照——調(diào)用方后續(xù)修改原始AgentEndpoint或 Collection 不得改變重連意圖重放內(nèi)容以快照為準(zhǔn)而非引用原對象舊 AgentCard 訂閱的exact Version 和 latest 是不同本地身份服務(wù)端返回的 Version 當(dāng)前是否為 latest不能替代調(diào)用方訂閱身份一次變化必須通知所有受影響的 exact/latest key當(dāng) latest 指向已緩存的精確 Version 時(shí)仍需產(chǎn)生 latest 變化兩者身份獨(dú)立latest 訂閱方必須收到通知取消后使用已有 Cache 重新訂閱必須重新啟動(dòng)輪詢?nèi)蝿?wù)SDK shutdown 必須停止舊 AgentCard Cache Holder 的全部輪詢。9. Shutdown清理什么、保留什么SDK shutdown 必須執(zhí)行四類清理清理內(nèi)存 redo state清空redoDataMap對應(yīng)AbstractRedoService.shutdown()中的redoDataMap.clear()停止后臺(tái) retry taskredoExecutor.shutdownNow()終止 redo 定時(shí)任務(wù)線程池關(guān)閉 transport client停止本地 cache/failover refresh task。同時(shí)除非用戶顯式調(diào)用緩存清理操作如LocalConfigInfoProcessor.cleanAllSnapshot()/cleanEnvSnapshot(...)shutdown不應(yīng)刪除用戶維護(hù)的 failover 文件或服務(wù)端派生 snapshot——它們屬于跨進(jìn)程生命周期存續(xù)的恢復(fù)資產(chǎn)應(yīng)留給下一次進(jìn)程啟動(dòng)繼續(xù)使用。10. 當(dāng)前實(shí)現(xiàn)的演進(jìn)方向與待處理問題規(guī)范最后列出了三個(gè)已知的演進(jìn)方向Redo 實(shí)現(xiàn)收斂Naming redo 當(dāng)前仍使用獨(dú)立實(shí)現(xiàn)NamingGrpcRedoServiceRedoScheduledTask較新的 AI redoAiGrpcRedoServiceAiRedoScheduledTask已使用通用 redo 抽象AbstractRedoService/AbstractRedoTask/RedoData。后續(xù)實(shí)現(xiàn)應(yīng)把 Naming 側(cè)也收斂到共享 redo 模型上可觀測字段共享Config listener recovery、Naming redo、AI redo 與運(yùn)行時(shí)推送與重連規(guī)范定義的 runtime push recovery 應(yīng)共享可觀測字段便于統(tǒng)一監(jiān)控與排障多語言 SDK 對齊各語言 SDK 應(yīng)說明自己支持哪些本地緩存和 redo 行為以及哪些行為有意與 Java 基準(zhǔn)實(shí)現(xiàn)不同。11. 常見問題速查Q1failover 文件由誰創(chuàng)建客戶端不會(huì)自動(dòng)創(chuàng)建。需要運(yùn)維或應(yīng)用在緊急場景下手動(dòng)放置到${user.home}/nacos/config/{serverName}_nacos/data/config-data(或 config-data-tenant)/{group}/{dataId}對應(yīng)路徑。Q2snapshot 什么時(shí)候刪除當(dāng)服務(wù)端確認(rèn)該 Config item 不存在時(shí)客戶端會(huì)刪除對應(yīng) snapshot因此 snapshot 永遠(yuǎn)代表最后已知存在的配置。Q3連接斷開時(shí) redo data 發(fā)生了什么AbstractRedoService.onDisConnect()會(huì)把所有 redo data 的registered標(biāo)記為 false等待重連后由 redo 定時(shí)任務(wù)重新注冊/重放。Q4為什么HTTP_CLIENT_NOT_FOUND要重放整個(gè)分組因?yàn)樵撳e(cuò)誤意味著服務(wù)端已丟棄整個(gè) HTTP Client 的所有狀態(tài)只重試單個(gè)失敗 Endpoint 無法修復(fù)其余 Endpoint 的丟失。Q5本地軟水位超限算失敗嗎算終止性寫失敗被拒絕的 Publication 會(huì)被移出 Publication Manager 與 Redo CacheHTTP Maintenance 不再 Heartbeat 或重試這與可重試的瞬時(shí) 5xx 失敗語義不同。Q6文章涉及的配置項(xiàng)有哪些nacosAiAgentEndpointMaxPublicationsPublication Batch 中 Runtime Endpoint 條目的軟水位默認(rèn) 100nacosAiAgentDiscoveryMaxSubscriptions本地輪詢訂閱 Cache 的最大規(guī)范化 Key 數(shù)默認(rèn) 300jm.snapshot.path/user.homesnapshot 根目錄定位源碼LocalConfigInfoProcessor.LOCAL_SNAPSHOT_PATH的解析順序SnapShotSwitchsnapshot 讀寫總開關(guān)getIsSnapShot()。【免費(fèi)下載鏈接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/na/nacos創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考