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