1. 從“上下文模式”說(shuō)起一個(gè)被低估的工程概念第一次聽到“context-mode”這個(gè)詞很多人會(huì)下意識(shí)地把它歸到某個(gè)具體框架的配置項(xiàng)里覺(jué)得無(wú)非是個(gè)開關(guān)或者枚舉值。但如果你在真實(shí)項(xiàng)目里被上下文切換坑過(guò)幾次就會(huì)明白它背后牽扯的東西遠(yuǎn)比一個(gè)參數(shù)復(fù)雜得多。我最早接觸這個(gè)概念是在做一個(gè)多輪對(duì)話系統(tǒng)的時(shí)候當(dāng)時(shí)用戶反饋“聊到第三輪就忘了前面說(shuō)過(guò)什么”排查了半天才發(fā)現(xiàn)問(wèn)題根本不在模型本身而在于整個(gè)請(qǐng)求鏈路里上下文的組織方式出了偏差。所謂 context-mode直白地講就是一套關(guān)于“上下文如何被組織、傳遞、切換和消費(fèi)”的運(yùn)行模式。它決定了系統(tǒng)在某個(gè)時(shí)刻應(yīng)該看到哪些信息、忽略哪些信息、以什么優(yōu)先級(jí)去處理這些信息。這個(gè)詞可以出現(xiàn)在很多場(chǎng)景里對(duì)話系統(tǒng)里的會(huì)話上下文管理、前端框架里的渲染上下文切換、后端服務(wù)里的請(qǐng)求上下文傳遞、甚至操作系統(tǒng)層面的執(zhí)行上下文切換。不同領(lǐng)域的具體實(shí)現(xiàn)千差萬(wàn)別但核心命題是一致的——在正確的時(shí)間把正確的上下文交給正確的處理單元。這篇文章適合誰(shuí)看如果你正在做多輪對(duì)話、狀態(tài)機(jī)驅(qū)動(dòng)的業(yè)務(wù)流程、或者任何需要“記住之前發(fā)生了什么”的系統(tǒng)那 context-mode 就是你繞不開的基礎(chǔ)設(shè)施。如果你只是寫寫簡(jiǎn)單的 CRUD可能暫時(shí)感受不到它的威力但一旦業(yè)務(wù)復(fù)雜度上來(lái)上下文管理混亂帶來(lái)的問(wèn)題會(huì)成倍放大。我見(jiàn)過(guò)太多項(xiàng)目在早期不重視上下文設(shè)計(jì)后期靠打補(bǔ)丁硬撐最后維護(hù)成本高到?jīng)]人敢動(dòng)。接下來(lái)我會(huì)從設(shè)計(jì)思路、核心細(xì)節(jié)、實(shí)操落地、問(wèn)題排查幾個(gè)維度把 context-mode 這個(gè)東西掰開揉碎講清楚。不是教科書式的定義羅列而是我在實(shí)際項(xiàng)目里踩過(guò)的坑、總結(jié)出的經(jīng)驗(yàn)以及那些文檔里不會(huì)寫的取舍邏輯。2. 上下文模式的整體設(shè)計(jì)與思路拆解2.1 為什么需要“模式”而不是“一個(gè)變量”很多人一開始會(huì)想上下文不就是個(gè)字典或者對(duì)象嗎存進(jìn)去取出來(lái)就完了搞什么“模式”這個(gè)想法在簡(jiǎn)單場(chǎng)景下沒(méi)問(wèn)題但一旦系統(tǒng)需要處理并發(fā)的、多來(lái)源的、有生命周期差異的上下文時(shí)一個(gè)裸字典就會(huì)變成災(zāi)難。我舉個(gè)例子一個(gè)客服系統(tǒng)同時(shí)處理多個(gè)用戶的會(huì)話每個(gè)會(huì)話有自己的歷史消息、用戶畫像、當(dāng)前工單狀態(tài)、臨時(shí)變量。如果你用一個(gè)全局字典存這些東西鍵名沖突、內(nèi)存泄漏、并發(fā)讀寫問(wèn)題會(huì)接踵而至?！澳Ｊ健钡谋举|(zhì)是約定。它約定了上下文的邊界在哪里、生命周期怎么管理、不同層級(jí)的上下文如何隔離和繼承。有了模式團(tuán)隊(duì)里每個(gè)人都知道該往哪里寫、從哪里讀、什么時(shí)候清理。沒(méi)有模式每個(gè)人都有自己的寫法最后就是一團(tuán)亂麻。從工程角度看context-mode 要解決的核心問(wèn)題可以歸納為三個(gè)隔離性不同請(qǐng)求/會(huì)話之間不能串、可追溯性出問(wèn)題時(shí)能還原當(dāng)時(shí)的上下文狀態(tài)、可擴(kuò)展性新增一種上下文類型不需要改動(dòng)核心邏輯。這三個(gè)問(wèn)題決定了你在設(shè)計(jì)時(shí)必須做出一系列取舍。2.2 幾種常見(jiàn)的上下文模式及其適用場(chǎng)景在實(shí)際項(xiàng)目中我見(jiàn)過(guò)和用過(guò)的上下文模式大致可以分成幾類每類都有它最適合的場(chǎng)景和明顯的短板。第一類是請(qǐng)求級(jí)上下文Request-Scoped Context。這是最常見(jiàn)的一種每個(gè)請(qǐng)求進(jìn)來(lái)時(shí)創(chuàng)建一個(gè)上下文對(duì)象請(qǐng)求結(jié)束時(shí)銷毀。它的優(yōu)勢(shì)是生命周期清晰、天然隔離適合無(wú)狀態(tài)服務(wù)。但缺點(diǎn)也很明顯跨請(qǐng)求的狀態(tài)無(wú)法保留如果業(yè)務(wù)需要“記住上次操作”就得額外引入存儲(chǔ)層。第二類是會(huì)話級(jí)上下文Session-Scoped Context。上下文跟會(huì)話綁定生命周期跨越多個(gè)請(qǐng)求。多輪對(duì)話、購(gòu)物車、向?qū)搅鞒潭紝儆谶@一類。它的復(fù)雜度在于過(guò)期策略和并發(fā)控制——兩個(gè)請(qǐng)求同時(shí)修改同一個(gè)會(huì)話上下文時(shí)怎么辦我通常會(huì)用版本號(hào)或者樂(lè)觀鎖來(lái)處理后面會(huì)詳細(xì)講。第三類是繼承式上下文Inherited Context。子任務(wù)從父任務(wù)繼承上下文但可以覆蓋部分字段。這在任務(wù)編排、工作流引擎里很常見(jiàn)。它的坑在于“繼承”和“隔離”的邊界容易模糊改了一個(gè)字段結(jié)果影響了父級(jí)這種 bug 排查起來(lái)非常痛苦。第四類是分層上下文Layered Context。把上下文分成全局層、租戶層、用戶層、請(qǐng)求層逐層覆蓋。配置系統(tǒng)、多租戶 SaaS 常用這種模式。它的好處是層次分明壞處是查找一個(gè)值時(shí)需要逐層回溯性能上要留意。模式類型生命周期隔離粒度典型場(chǎng)景主要風(fēng)險(xiǎn)請(qǐng)求級(jí)單次請(qǐng)求請(qǐng)求無(wú)狀態(tài) API跨請(qǐng)求狀態(tài)丟失會(huì)話級(jí)多次請(qǐng)求會(huì)話多輪對(duì)話、購(gòu)物車并發(fā)寫沖突、過(guò)期管理繼承式隨父任務(wù)任務(wù)樹工作流、任務(wù)編排父子污染分層式長(zhǎng)期多層級(jí)多租戶配置查找性能、覆蓋歧義選哪種模式取決于你的業(yè)務(wù)對(duì)“記憶”的需求有多強(qiáng)以及你對(duì)并發(fā)和一致性的容忍度。我的經(jīng)驗(yàn)是能用請(qǐng)求級(jí)就別用會(huì)話級(jí)能用會(huì)話級(jí)就別自己造繼承式。每往上加一層復(fù)雜度維護(hù)成本都是指數(shù)級(jí)上升的。2.3 設(shè)計(jì)取舍什么時(shí)候該“重”什么時(shí)候該“輕”做上下文設(shè)計(jì)時(shí)最容易犯的錯(cuò)誤是過(guò)度設(shè)計(jì)。我見(jiàn)過(guò)一個(gè)內(nèi)部工具日活不到一百卻搞了一套帶版本控制、事件溯源、分布式鎖的上下文管理系統(tǒng)結(jié)果開發(fā)效率被拖垮最后推倒重來(lái)。反過(guò)來(lái)也有項(xiàng)目該重的地方偷懶比如一個(gè)金融審批流程上下文狀態(tài)沒(méi)有持久化服務(wù)重啟后所有進(jìn)行中的審批全部丟失釀成事故。我的判斷標(biāo)準(zhǔn)很簡(jiǎn)單看上下文丟失的代價(jià)有多大。如果丟了只是讓用戶重新點(diǎn)一次那就輕量處理內(nèi)存里存著就行。如果丟了會(huì)導(dǎo)致資金損失、數(shù)據(jù)不一致、用戶投訴那就必須持久化、加鎖、做恢復(fù)機(jī)制。另一個(gè)維度是并發(fā)量低并發(fā)下很多問(wèn)題不會(huì)暴露高并發(fā)下必須提前設(shè)計(jì)好隔離和鎖策略。還有一點(diǎn)容易被忽略上下文的可觀測(cè)性。你不僅要能存能取還要能在出問(wèn)題時(shí)看到“當(dāng)時(shí)上下文里到底有什么”。我習(xí)慣在上下文對(duì)象里加一個(gè)traceId所有讀寫操作都打日志排查問(wèn)題時(shí)能完整還原鏈路。這個(gè)習(xí)慣幫我省了無(wú)數(shù)次加班。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 上下文的生命周期管理創(chuàng)建、傳遞、銷毀上下文管理最核心的就是生命周期。我把它拆成三個(gè)階段創(chuàng)建、傳遞、銷毀。每個(gè)階段都有講究。創(chuàng)建階段關(guān)鍵是確定上下文的“根”在哪里。對(duì)于 Web 服務(wù)通常是在請(qǐng)求進(jìn)入的第一個(gè)中間件里創(chuàng)建。對(duì)于消息隊(duì)列消費(fèi)者是在消息被拉取時(shí)創(chuàng)建。對(duì)于定時(shí)任務(wù)是在任務(wù)觸發(fā)時(shí)創(chuàng)建。這個(gè)根一旦確定后續(xù)所有子操作都從這個(gè)根派生上下文。我見(jiàn)過(guò)有人在業(yè)務(wù)代碼深處隨手 new 一個(gè)上下文結(jié)果這個(gè)上下文跟請(qǐng)求鏈路脫節(jié)日志對(duì)不上排查時(shí)完全找不到關(guān)聯(lián)。傳遞階段有兩種主流做法顯式傳遞和隱式傳遞。顯式傳遞就是把上下文對(duì)象作為參數(shù)一層層傳下去優(yōu)點(diǎn)是清晰、可測(cè)試缺點(diǎn)是參數(shù)列表會(huì)變得很長(zhǎng)。隱式傳遞通常借助線程本地存儲(chǔ)ThreadLocal或者異步上下文AsyncLocalStorage 之類優(yōu)點(diǎn)是代碼干凈缺點(diǎn)是“魔法”太多新人看不懂上下文從哪來(lái)的。我的建議是核心鏈路用顯式傳遞橫切關(guān)注點(diǎn)日志、監(jiān)控、鑒權(quán)用隱式傳遞。兩者結(jié)合既保證可讀性又避免參數(shù)爆炸。銷毀階段最容易被忽視。很多人創(chuàng)建了上下文就不管了導(dǎo)致內(nèi)存泄漏。尤其是在使用 ThreadLocal 的場(chǎng)景下線程池復(fù)用線程時(shí)如果不清理上一個(gè)請(qǐng)求的上下文會(huì)污染下一個(gè)請(qǐng)求。這個(gè) bug 極其隱蔽表現(xiàn)是“偶爾串?dāng)?shù)據(jù)”排查難度極高。我的做法是在請(qǐng)求結(jié)束的 finally 塊里強(qiáng)制清理上下文并且寫一個(gè)單元測(cè)試專門驗(yàn)證清理邏輯。# 以 Python 為例展示請(qǐng)求級(jí)上下文的創(chuàng)建與清理 import contextvars request_context contextvars.ContextVar(request_context) def handle_request(request): ctx { trace_id: generate_trace_id(), user_id: request.user_id, start_time: time.time(), } token request_context.set(ctx) try: process(request) finally: request_context.reset(token) # 關(guān)鍵必須重置否則污染后續(xù)請(qǐng)求注意使用 contextvars 或 ThreadLocal 時(shí)一定要在 finally 里做 reset/remove。我踩過(guò)一次坑線上出現(xiàn)用戶 A 看到用戶 B 的數(shù)據(jù)查了兩天才定位到是線程池復(fù)用導(dǎo)致的上下文殘留。3.2 上下文隔離別讓數(shù)據(jù)串了門隔離性是上下文管理的底線。一旦隔離出問(wèn)題輕則數(shù)據(jù)錯(cuò)亂重則安全事故。隔離的實(shí)現(xiàn)方式取決于你的并發(fā)模型。在同步阻塞模型下每個(gè)請(qǐng)求獨(dú)占一個(gè)線程用 ThreadLocal 天然隔離。但要注意線程池的復(fù)用問(wèn)題前面已經(jīng)提過(guò)。在異步非阻塞模型下一個(gè)線程可能同時(shí)處理多個(gè)請(qǐng)求ThreadLocal 就失效了必須用 contextvars 或者顯式傳遞。在協(xié)程模型下每個(gè)協(xié)程有自己的上下文但協(xié)程切換時(shí)要注意上下文的綁定關(guān)系。我做過(guò)一個(gè)項(xiàng)目從同步模型遷移到異步模型時(shí)忘了把 ThreadLocal 換成 contextvars結(jié)果測(cè)試環(huán)境一切正常線上高并發(fā)時(shí)數(shù)據(jù)串得一塌糊涂。原因是測(cè)試環(huán)境并發(fā)低線程沒(méi)有復(fù)用問(wèn)題沒(méi)暴露。這個(gè)教訓(xùn)告訴我并發(fā)相關(guān)的改動(dòng)必須在高并發(fā)場(chǎng)景下壓測(cè)驗(yàn)證不能只看功能測(cè)試。另一個(gè)隔離維度是租戶隔離。多租戶系統(tǒng)里上下文必須攜帶租戶標(biāo)識(shí)并且所有數(shù)據(jù)訪問(wèn)都要帶上這個(gè)標(biāo)識(shí)做過(guò)濾。我習(xí)慣在上下文創(chuàng)建時(shí)就注入租戶 ID然后在數(shù)據(jù)訪問(wèn)層強(qiáng)制校驗(yàn)防止開發(fā)者忘記加過(guò)濾條件。這種“默認(rèn)安全”的設(shè)計(jì)比靠代碼審查靠譜得多。3.3 上下文的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)扁平還是嵌套上下文的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)直接影響讀寫效率和可維護(hù)性。扁平結(jié)構(gòu)就是所有字段平鋪在一層嵌套結(jié)構(gòu)就是按業(yè)務(wù)域分組。扁平結(jié)構(gòu)的優(yōu)點(diǎn)是查找快、序列化簡(jiǎn)單缺點(diǎn)是字段多了以后容易命名沖突比如status到底是訂單狀態(tài)還是用戶狀態(tài)光看名字分不清。嵌套結(jié)構(gòu)的優(yōu)點(diǎn)是語(yǔ)義清晰order.status和user.status一目了然缺點(diǎn)是深層查找需要判空序列化反序列化也更復(fù)雜。我的實(shí)踐經(jīng)驗(yàn)是字段少于 20 個(gè)用扁平超過(guò) 20 個(gè)用嵌套但嵌套深度不要超過(guò) 3 層。超過(guò) 3 層以后代碼里全是a.b.c.d可讀性急劇下降。另外不管用哪種結(jié)構(gòu)都建議給上下文定義一個(gè) schema 或者類型定義而不是用裸字典。類型定義能在編譯期發(fā)現(xiàn)錯(cuò)誤裸字典只能等運(yùn)行時(shí)爆炸。// 用 TypeScript 定義上下文結(jié)構(gòu)編譯期就能發(fā)現(xiàn)字段錯(cuò)誤 interface RequestContext { traceId: string; userId: string; tenant: { id: string; plan: free | pro | enterprise; }; session?: { id: string; turnCount: number; }; }提示上下文里不要存大對(duì)象。我見(jiàn)過(guò)有人把整個(gè)用戶對(duì)象塞進(jìn)上下文結(jié)果每次序列化都慢得要命。上下文里只存 ID 和必要的小字段需要詳細(xì)信息時(shí)按 ID 去查。3.4 上下文切換的時(shí)機(jī)與策略上下文切換是 context-mode 里最微妙的部分。什么時(shí)候該切換上下文切換時(shí)哪些字段保留、哪些重置這些問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案但有一些原則可以遵循。原則一切換要有明確的觸發(fā)點(diǎn)。比如用戶切換會(huì)話、任務(wù)進(jìn)入新階段、請(qǐng)求跨越服務(wù)邊界。觸發(fā)點(diǎn)不明確切換就會(huì)變得隨意最后沒(méi)人說(shuō)得清當(dāng)前上下文是什么狀態(tài)。原則二切換時(shí)默認(rèn)重置顯式保留。也就是說(shuō)新上下文默認(rèn)是干凈的只有明確需要繼承的字段才從舊上下文復(fù)制過(guò)來(lái)。這個(gè)原則能有效防止上下文污染。反過(guò)來(lái)做——默認(rèn)繼承、顯式清理——幾乎必然導(dǎo)致臟數(shù)據(jù)。原則三切換要可追溯。每次切換都記錄一條日志包含切換原因、切換前后的關(guān)鍵字段。出問(wèn)題時(shí)能還原整個(gè)切換鏈路。我在一個(gè)工作流項(xiàng)目里就是這么做的后來(lái)排查一個(gè)狀態(tài)錯(cuò)亂問(wèn)題時(shí)靠切換日志十分鐘就定位到了根因。原則四跨服務(wù)傳遞要序列化。上下文在不同服務(wù)之間傳遞時(shí)必須序列化成標(biāo)準(zhǔn)格式比如 JSON 或者特定的 header并且要有版本號(hào)。我吃過(guò)虧上游服務(wù)給上下文加了個(gè)字段下游服務(wù)反序列化時(shí)因?yàn)榘姹静黄ヅ渲苯訄?bào)錯(cuò)。加了版本號(hào)以后下游可以兼容處理未知字段。4. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 從零搭建一個(gè)會(huì)話級(jí)上下文管理器光講理論不夠我?guī)銖牧愦钜粋€(gè)會(huì)話級(jí)上下文管理器。以多輪對(duì)話系統(tǒng)為例需求是每個(gè)會(huì)話有獨(dú)立的上下文支持多輪對(duì)話上下文有過(guò)期時(shí)間支持并發(fā)安全。第一步定義上下文結(jié)構(gòu)。我選擇嵌套結(jié)構(gòu)因?yàn)閷?duì)話系統(tǒng)的上下文字段比較多。from dataclasses import dataclass, field from typing import Optional import time dataclass class SessionContext: session_id: str user_id: str created_at: float field(default_factorytime.time) updated_at: float field(default_factorytime.time) turn_count: int 0 history: list field(default_factorylist) slots: dict field(default_factorydict) # 對(duì)話槽位 version: int 0 # 樂(lè)觀鎖版本號(hào)第二步實(shí)現(xiàn)存儲(chǔ)層。我用 Redis 做存儲(chǔ)因?yàn)樾枰^(guò)期能力和并發(fā)安全。key 的設(shè)計(jì)是session:{session_id}value 是序列化后的上下文。import json import redis class SessionStore: def __init__(self, redis_client, ttl_seconds1800): self.redis redis_client self.ttl ttl_seconds def load(self, session_id: str) - Optional[SessionContext]: raw self.redis.get(fsession:{session_id}) if not raw: return None data json.loads(raw) return SessionContext(**data) def save(self, ctx: SessionContext): ctx.updated_at time.time() self.redis.setex( fsession:{ctx.session_id}, self.ttl, json.dumps(ctx.__dict__) )第三步處理并發(fā)寫。兩個(gè)請(qǐng)求同時(shí)修改同一個(gè)會(huì)話時(shí)后寫的會(huì)覆蓋先寫的。我用樂(lè)觀鎖解決保存時(shí)檢查版本號(hào)不匹配就重試。def update_with_retry(store, session_id, update_fn, max_retries3): for attempt in range(max_retries): ctx store.load(session_id) if ctx is None: raise SessionNotFound(session_id) old_version ctx.version update_fn(ctx) ctx.version old_version 1 # 用 WATCH/MULTI 保證原子性 with store.redis.pipeline() as pipe: try: pipe.watch(fsession:{session_id}) current json.loads(pipe.get(fsession:{session_id})) if current[version] ! old_version: pipe.unwatch() continue # 版本沖突重試 pipe.multi() pipe.setex( fsession:{session_id}, store.ttl, json.dumps(ctx.__dict__) ) pipe.execute() return ctx except redis.WatchError: continue raise ConcurrentModificationError(session_id)這套代碼我在生產(chǎn)環(huán)境跑過(guò)QPS 幾千的情況下沒(méi)有出現(xiàn)數(shù)據(jù)錯(cuò)亂。關(guān)鍵點(diǎn)是版本號(hào) WATCH/MULTI兩者缺一不可。只用版本號(hào)不用事務(wù)檢查和寫入之間有窗口期只用事務(wù)不用版本號(hào)無(wú)法檢測(cè)到邏輯上的沖突。4.2 上下文在服務(wù)間的傳遞實(shí)現(xiàn)單體服務(wù)里上下文好管理一旦拆成微服務(wù)上下文傳遞就成了大問(wèn)題。我的做法是通過(guò) HTTP header 傳遞上下文的關(guān)鍵字段通過(guò)共享存儲(chǔ)傳遞大塊數(shù)據(jù)。具體來(lái)說(shuō)traceId、userId、tenantId這些輕量字段放在 header 里每個(gè)服務(wù)都能讀到。會(huì)話歷史、槽位這些大塊數(shù)據(jù)放在 Redis 里header 里只放一個(gè)sessionId需要時(shí)去查。這樣既保證了鏈路可追溯又避免了 header 過(guò)大。# 上游服務(wù)把上下文注入 header def inject_context(headers, ctx): headers[X-Trace-Id] ctx.trace_id headers[X-User-Id] ctx.user_id headers[X-Tenant-Id] ctx.tenant_id headers[X-Session-Id] ctx.session_id headers[X-Context-Version] 1 return headers # 下游服務(wù)從 header 還原上下文 def extract_context(headers): version headers.get(X-Context-Version, 1) if version ! 1: # 版本不匹配時(shí)的兼容處理 pass return { trace_id: headers.get(X-Trace-Id), user_id: headers.get(X-User-Id), tenant_id: headers.get(X-Tenant-Id), session_id: headers.get(X-Session-Id), }注意header 有大小限制通常 8KB 左右。不要把大對(duì)象塞進(jìn) header否則請(qǐng)求會(huì)被網(wǎng)關(guān)直接拒絕。我見(jiàn)過(guò)有人把整個(gè)對(duì)話歷史放 header 里結(jié)果長(zhǎng)對(duì)話直接 431 錯(cuò)誤。4.3 上下文過(guò)期與清理策略上下文不能無(wú)限增長(zhǎng)必須有清理機(jī)制。我通常用三層策略TTL 自動(dòng)過(guò)期、LRU 淘汰、定期歸檔。TTL 是最基礎(chǔ)的Redis 的setex就能搞定。但 TTL 有個(gè)問(wèn)題如果用戶在 TTL 內(nèi)一直活躍上下文會(huì)一直保留可能占用大量?jī)?nèi)存。所以我還會(huì)加一個(gè)最大空閑時(shí)間超過(guò)這個(gè)時(shí)間沒(méi)有活動(dòng)就主動(dòng)清理不管 TTL 到?jīng)]到。LRU 淘汰用于內(nèi)存緊張時(shí)的兜底。Redis 可以配置maxmemory-policy allkeys-lru但要注意這會(huì)淘汰所有 key不只是會(huì)話 key。更精細(xì)的做法是給會(huì)話 key 單獨(dú)打標(biāo)簽用單獨(dú)的 Redis 實(shí)例或者數(shù)據(jù)庫(kù)來(lái)隔離。定期歸檔用于合規(guī)和數(shù)據(jù)分析。有些業(yè)務(wù)要求會(huì)話記錄保留一段時(shí)間以備審計(jì)這時(shí)候就不能直接刪要?dú)w檔到冷存儲(chǔ)。我一般用定時(shí)任務(wù)每天凌晨把過(guò)期會(huì)話導(dǎo)出到對(duì)象存儲(chǔ)然后從 Redis 刪除。策略觸發(fā)條件優(yōu)點(diǎn)缺點(diǎn)TTL 過(guò)期到達(dá)設(shè)定時(shí)間實(shí)現(xiàn)簡(jiǎn)單活躍會(huì)話也占內(nèi)存最大空閑超過(guò)空閑閾值釋放活躍但無(wú)用的會(huì)話需要額外跟蹤活動(dòng)時(shí)間LRU 淘汰內(nèi)存不足自動(dòng)兜底可能誤刪活躍會(huì)話定期歸檔定時(shí)觸發(fā)滿足合規(guī)要求實(shí)現(xiàn)復(fù)雜需要冷存儲(chǔ)我的建議是TTL 最大空閑組合使用LRU 作為兜底歸檔按需開啟。不要一上來(lái)就全套上根據(jù)業(yè)務(wù)實(shí)際需求來(lái)。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 上下文串?dāng)?shù)據(jù)最危險(xiǎn)也最難查的 bug上下文串?dāng)?shù)據(jù)是我遇到過(guò)最頭疼的問(wèn)題沒(méi)有之一。表現(xiàn)是用戶 A 看到了用戶 B 的數(shù)據(jù)或者請(qǐng)求 A 的上下文里混入了請(qǐng)求 B 的字段。這種 bug 往往在低并發(fā)下不出現(xiàn)高并發(fā)下偶發(fā)排查難度極大。根因通常有三個(gè)一是 ThreadLocal 或 contextvars 沒(méi)有正確清理線程/協(xié)程復(fù)用時(shí)殘留了上一個(gè)請(qǐng)求的數(shù)據(jù)二是異步任務(wù)沒(méi)有正確傳遞上下文子任務(wù)用了默認(rèn)的全局上下文三是緩存 key 設(shè)計(jì)不當(dāng)不同用戶的上下文用了相同的 key。排查思路首先在上下文創(chuàng)建和銷毀的地方加日志記錄traceId和關(guān)鍵字段。然后在數(shù)據(jù)訪問(wèn)層加校驗(yàn)發(fā)現(xiàn)上下文里的userId和請(qǐng)求的userId不一致時(shí)立即告警。最后用壓測(cè)工具模擬高并發(fā)復(fù)現(xiàn)問(wèn)題。我解決過(guò)一次線上串?dāng)?shù)據(jù)問(wèn)題最后定位到是某個(gè)異步任務(wù)用了全局的上下文變量而不是從請(qǐng)求上下文派生。修復(fù)方式是在任務(wù)提交時(shí)顯式傳遞上下文快照任務(wù)內(nèi)部用快照而不是全局變量。提示給上下文加一個(gè)owner字段記錄創(chuàng)建者的標(biāo)識(shí)。每次讀寫上下文時(shí)校驗(yàn)owner是否匹配不匹配就拋異常。這個(gè)校驗(yàn)在開發(fā)和測(cè)試環(huán)境開啟生產(chǎn)環(huán)境可以只告警不阻斷避免誤傷。5.2 上下文過(guò)大導(dǎo)致的性能問(wèn)題上下文不是越大越好。我見(jiàn)過(guò)一個(gè)項(xiàng)目上下文里塞了幾百個(gè)字段每次序列化要幾十毫秒高并發(fā)下直接成為瓶頸。上下文過(guò)大的另一個(gè)問(wèn)題是網(wǎng)絡(luò)傳輸開銷跨服務(wù)傳遞時(shí) header 或 body 膨脹拖慢整個(gè)鏈路。判斷上下文是否過(guò)大序列化后超過(guò) 10KB 就要警惕超過(guò) 100KB 基本可以確定有問(wèn)題。用監(jiān)控工具統(tǒng)計(jì)上下文大小的分布找出異常大的請(qǐng)求。優(yōu)化手段一是拆分把不常用的字段移到按需加載的存儲(chǔ)里上下文只保留 ID二是壓縮對(duì)歷史記錄這類文本數(shù)據(jù)做壓縮后再存三是裁剪定期清理不再需要的字段比如已經(jīng)完成的對(duì)話輪次可以只保留摘要。我的經(jīng)驗(yàn)是上下文里只放“當(dāng)前決策需要的最小信息集”。什么是當(dāng)前決策需要的就是處理這個(gè)請(qǐng)求時(shí)代碼邏輯會(huì)讀到的字段。讀不到的字段一律不放。這個(gè)原則能砍掉大部分冗余數(shù)據(jù)。5.3 上下文版本兼容服務(wù)升級(jí)時(shí)的坑微服務(wù)架構(gòu)下上下文結(jié)構(gòu)會(huì)隨著業(yè)務(wù)迭代而變化。上游服務(wù)加了字段下游服務(wù)不認(rèn)識(shí)下游服務(wù)刪了字段上游服務(wù)還在傳。這種版本不一致會(huì)導(dǎo)致各種奇怪的問(wèn)題。解決方案是給上下文加版本號(hào)并且遵循“向后兼容”原則。加字段是安全的下游忽略未知字段即可。刪字段和改字段類型是危險(xiǎn)的必須走版本升級(jí)流程。我通常會(huì)在上下文里加一個(gè)schemaVersion字段下游根據(jù)版本號(hào)決定如何解析。def parse_context(raw: dict) - dict: version raw.get(schemaVersion, 1) if version 1: return parse_v1(raw) elif version 2: return parse_v2(raw) else: # 未知版本盡量兼容處理 return parse_with_defaults(raw)注意不要依賴字段的順序。JSON 對(duì)象的字段順序是不保證的用位置來(lái)解析字段遲早出問(wèn)題。永遠(yuǎn)用 key 來(lái)訪問(wèn)。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案用戶看到他人數(shù)據(jù)上下文未清理/串用加 owner 校驗(yàn)和日志修復(fù)清理邏輯加隔離校驗(yàn)上下文偶爾丟失過(guò)期時(shí)間太短/被淘汰檢查 TTL 和內(nèi)存策略調(diào)整 TTL隔離存儲(chǔ)序列化慢上下文過(guò)大統(tǒng)計(jì)上下文大小分布拆分、壓縮、裁剪跨服務(wù)字段丟失header 未傳遞/版本不匹配檢查鏈路日志補(bǔ)全傳遞邏輯加版本號(hào)并發(fā)寫覆蓋缺少鎖機(jī)制壓測(cè)復(fù)現(xiàn)加樂(lè)觀鎖或分布式鎖內(nèi)存持續(xù)增長(zhǎng)上下文未銷毀監(jiān)控內(nèi)存和 key 數(shù)量加清理機(jī)制設(shè)上限6. 上下文模式的擴(kuò)展與個(gè)人經(jīng)驗(yàn)context-mode 這個(gè)東西往淺了說(shuō)是個(gè)技術(shù)方案往深了說(shuō)是一種系統(tǒng)設(shè)計(jì)思維。它逼著你去思考什么是狀態(tài)狀態(tài)存在哪里狀態(tài)的生命周期是什么狀態(tài)之間如何隔離。這些問(wèn)題想清楚了不光上下文管理整個(gè)系統(tǒng)的架構(gòu)都會(huì)清晰很多。我后來(lái)把這套思路用在了配置管理上。配置本質(zhì)上也是一種上下文全局配置、租戶配置、用戶配置層層覆蓋每層有自己的生命周期和優(yōu)先級(jí)。用上下文模式來(lái)管理配置比傳統(tǒng)的配置文件加環(huán)境變量清晰得多。再后來(lái)做特性開關(guān)feature flag也是類似的思路開關(guān)的生效范圍、過(guò)期時(shí)間、覆蓋規(guī)則都能用上下文模式來(lái)建模。如果你正在設(shè)計(jì)一個(gè)需要“記住狀態(tài)”的系統(tǒng)我的建議是先把上下文的生命周期畫出來(lái)再寫代碼。畫的時(shí)候問(wèn)自己幾個(gè)問(wèn)題上下文從哪里創(chuàng)建經(jīng)過(guò)哪些環(huán)節(jié)在哪里銷毀并發(fā)時(shí)如何隔離出問(wèn)題時(shí)如何追溯這幾個(gè)問(wèn)題答清楚了實(shí)現(xiàn)就是水到渠成的事。最后分享一個(gè)小技巧在上下文里加一個(gè)debug字段開發(fā)環(huán)境開啟記錄每次讀寫的調(diào)用棧。線上出問(wèn)題時(shí)如果日志不夠可以臨時(shí)開啟這個(gè)字段快速定位是誰(shuí)改了上下文。這個(gè)技巧幫我省過(guò)好幾次通宵排查的時(shí)間。當(dāng)然生產(chǎn)環(huán)境要記得關(guān)掉不然日志量會(huì)爆炸。