“Redis 已正式接入 AI”這個(gè)說(shuō)法最近在好幾個(gè)技術(shù)群里都引發(fā)了爭(zhēng)論。有人覺得又是蹭熱點(diǎn)Redis 一個(gè)緩存數(shù)據(jù)庫(kù)跟大模型能有多大關(guān)系也有人已經(jīng)開始動(dòng)手把 Redis 的向量檢索和對(duì)話緩存接進(jìn)了生產(chǎn)環(huán)境。我的看法很直接這一波還真不是標(biāo)題黨。過(guò)去半年我在三個(gè)不同項(xiàng)目里給 Redis 安排了非常明確的角色——LLM 響應(yīng)緩存、RAG 向量倉(cāng)庫(kù)、Agent 會(huì)話存儲(chǔ)。每一個(gè)角色都對(duì)應(yīng)著 AI 應(yīng)用上線后的真實(shí)痛點(diǎn)重復(fù)請(qǐng)求太多、上下文太長(zhǎng)、檢索太慢。這篇文章不聊空泛的概念只講我實(shí)際跑通的選型思路、代碼實(shí)現(xiàn)和踩坑記錄。你照著把鏈路搭一遍馬上就能感受到變化。1. AI 應(yīng)用里 Redis 的角色不只是緩存1.1 先看清 AI 應(yīng)用的三個(gè)真實(shí)痛點(diǎn)AI 應(yīng)用和傳統(tǒng) Web 應(yīng)用最大的區(qū)別是每一次用戶請(qǐng)求背后都連著一個(gè)昂貴的模型推理過(guò)程。傳統(tǒng)接口頂多查幾次數(shù)據(jù)庫(kù)、跑一段業(yè)務(wù)邏輯AI 接口卻要把 Prompt 送到模型里跑一輪生成動(dòng)輒幾百毫秒甚至幾秒。這時(shí)候第一個(gè)痛點(diǎn)就出現(xiàn)了成本膨脹。十個(gè)用戶同時(shí)問(wèn)知識(shí)庫(kù)里同一個(gè)問(wèn)題模型給出的答案幾乎一模一樣你卻要為這十次重復(fù)計(jì)算買單。第二個(gè)痛點(diǎn)是上下文膨脹。Agent 類應(yīng)用尤其明顯任務(wù)要拆解成多步每一步都可能調(diào)用工具工具返回的結(jié)果又要拼接回對(duì)話歷史。多輪下來(lái)塞給模型的 Token 數(shù)量呈指數(shù)級(jí)上漲。很多團(tuán)隊(duì)做 Agent 做到一半發(fā)現(xiàn)成本失控本質(zhì)上是上下文沒有治理每次調(diào)用都把全量歷史倒給模型。第三個(gè)痛點(diǎn)是檢索太慢。想讓大模型回答私有知識(shí)問(wèn)題最穩(wěn)妥的做法是走 RAG從外部存儲(chǔ)里先召回相關(guān)內(nèi)容再拼進(jìn) Prompt。召回環(huán)節(jié)如果依賴傳統(tǒng)數(shù)據(jù)庫(kù)的 LIKE 查詢那速度基本告別了實(shí)時(shí)交互。這三個(gè)痛點(diǎn)分別對(duì)應(yīng)著緩存、狀態(tài)管理和向量檢索——全是 Redis 的老本行。1.2 LLM 響應(yīng)緩存把重復(fù)計(jì)算擋在門外最簡(jiǎn)單的降本增效手段就是把大模型的響應(yīng)緩存下來(lái)。同一個(gè) Prompt在緩存有效期內(nèi)再次請(qǐng)求直接返回上一次的結(jié)果不再調(diào)用模型接口。你可能會(huì)說(shuō)進(jìn)程內(nèi)緩存不也能做到嗎能但撐不住真實(shí)環(huán)境。AI 服務(wù)大概率是多實(shí)例部署的進(jìn)程內(nèi)緩存放在實(shí)例 A 里的數(shù)據(jù)實(shí)例 B 根本讀不到。用戶負(fù)載均衡打到 B 上重復(fù)調(diào)用還是發(fā)生。Redis 作為獨(dú)立緩存服務(wù)天然被所有實(shí)例共享命中率不會(huì)因?yàn)閿U(kuò)容而下降。具體的收益我算過(guò)一筆賬某個(gè)知識(shí)問(wèn)答項(xiàng)目上線緩存后同一問(wèn)題的重復(fù)請(qǐng)求占比大約 60%這就意味著模型調(diào)用量直接砍掉六成。再疊加一個(gè)降級(jí)策略——模型 API 抖動(dòng)或超時(shí)時(shí)優(yōu)先返回緩存里最近一次的結(jié)果用戶體驗(yàn)至少不會(huì)斷崖下跌。1.3 RAG 檢索Redis 作為低門檻向量數(shù)據(jù)庫(kù)RAG 是目前大模型落地最穩(wěn)的路線不需要微調(diào)模型把私有知識(shí)切成文本塊用 Embedding 模型轉(zhuǎn)成向量存進(jìn)向量數(shù)據(jù)庫(kù)。用戶提問(wèn)時(shí)也轉(zhuǎn)成向量做一次相似度檢索把最相關(guān)的幾個(gè)文本塊取出來(lái)拼進(jìn) Prompt。這里面的關(guān)鍵組件就是向量數(shù)據(jù)庫(kù)。Redis Stack 從 7.2 版本開始內(nèi)置向量索引能力到 Redis 8 更是把查詢引擎直接整合進(jìn)主庫(kù)支持 HNSW 和 FLAT 兩種索引算法可以毫秒級(jí)完成 Top-K 召回。這帶來(lái)的最大好處是不用引入新組件。你原來(lái)就有 Redis本來(lái)就在當(dāng)緩存用現(xiàn)在同一個(gè)集群里建一個(gè)向量索引順便把檢索問(wèn)題也解決了。中小項(xiàng)目或者 POC 階段這套方案完全夠用。我不建議一上來(lái)就上 Milvus、Weaviate 那種專用向量數(shù)據(jù)庫(kù)多一套分布式系統(tǒng)就是多一堆運(yùn)維負(fù)擔(dān)。當(dāng)然邊界也很清楚如果你的向量規(guī)模到了千萬(wàn)級(jí)之外或者對(duì)召回精度有極高要求專用向量庫(kù)還是必需的。選型要跟著規(guī)模走。1.4 Agent 會(huì)話與在線特征另兩個(gè)高頻場(chǎng)景Agent 應(yīng)用跟普通聊天界面的本質(zhì)區(qū)別在于它有狀態(tài)。一個(gè) Agent 任務(wù)要維護(hù)目標(biāo)、中間步驟、工具調(diào)用記錄甚至多個(gè)子 Agent 之間的協(xié)作消息。這些數(shù)據(jù)不能全丟給客戶端也不能每次都完整塞進(jìn)模型上下文。把它們落到 Redis 里用 List 存消息流用 Hash 存任務(wù)元數(shù)據(jù)用 TTL 控制生命周期Agent 每次醒來(lái)只需要從 Redis 里撈出最近幾十條記錄拼裝請(qǐng)求即可。在線推理服務(wù)里還有另一個(gè)高頻場(chǎng)景特征存儲(chǔ)。推薦、風(fēng)控、圖像識(shí)別這類模型推理時(shí)往往要根據(jù)用戶 ID 或者物品 ID 實(shí)時(shí)抓取特征。Redis 的 Hash 結(jié)構(gòu)天然就是特征表字段名就是特征名一次網(wǎng)絡(luò)往返取回幾十個(gè)字段延遲穩(wěn)定在毫秒級(jí)。再加上對(duì)外開放的模型網(wǎng)關(guān)基本都要限流Redis 的計(jì)數(shù)器方案也是社區(qū)里最成熟的。可以說(shuō)AI 應(yīng)用從請(qǐng)求入口到推理出口Redis 都能在關(guān)鍵節(jié)點(diǎn)上插一腳。2. 拆解核心機(jī)制Redis 到底靠什么支撐 AI2.1 數(shù)據(jù)結(jié)構(gòu)選型一張表對(duì)號(hào)入座很多朋友一說(shuō) Redis 就想到 String其實(shí) AI 鏈路里每個(gè)環(huán)節(jié)都有更合適的數(shù)據(jù)結(jié)構(gòu)。我整理了一份對(duì)應(yīng)關(guān)系直接照著用場(chǎng)景推薦類型用法說(shuō)明LLM 響應(yīng)緩存String直接緩存模型返回的文本配合 SETEX 設(shè)置 TTLToken 計(jì)數(shù)與限流StringINCR EXPIRE 實(shí)現(xiàn)滑動(dòng)窗口前的基礎(chǔ)計(jì)數(shù)用戶特征存儲(chǔ)Hash一個(gè) Key 對(duì)應(yīng)一個(gè)用戶字段是特征名Agent 消息記錄ListRPUSH 追加消息LRANGE 取最近 N 條向量元數(shù)據(jù)Hash文本內(nèi)容、來(lái)源、向量字段放同一個(gè) Hash已處理任務(wù)去重SetSADD 記錄任務(wù) IDSISMEMBER 判定是否處理過(guò)消息隊(duì)列Stream工具調(diào)用事件、日志推送支持消費(fèi)者組Agent 任務(wù)計(jì)劃JSON計(jì)劃節(jié)點(diǎn)、工具狀態(tài)等復(fù)雜結(jié)構(gòu)直接存 JSON關(guān)鍵原則是別把 Redis 用成單純的 Key-Value。消息記錄用 List 或 Stream能讓追加和分頁(yè)都非常自然結(jié)構(gòu)化狀態(tài)用 JSON 類型能減少應(yīng)用層的序列化代碼。Redis 的每一種數(shù)據(jù)類型在 AI 鏈路上都有明確位置。2.2 向量索引的底層邏輯Redis 的向量檢索能力本質(zhì)上是給字段聲明一個(gè) VECTOR 類型然后選索引算法。HNSW 是目前最常用的近似最近鄰算法它把向量組織成多層圖結(jié)構(gòu)犧牲極小的召回率換來(lái)極快的檢索速度千萬(wàn)級(jí)以內(nèi)的向量規(guī)模都很合適。FLAT 則是暴力精確計(jì)算適合小數(shù)據(jù)集或者對(duì)召回精度要求極高的場(chǎng)景。索引參數(shù)里有兩個(gè)值需要留意M 控制每個(gè)節(jié)點(diǎn)的最大連接數(shù)數(shù)值越大圖越密、召回越準(zhǔn)但內(nèi)存和構(gòu)建時(shí)間也漲EF 控制查詢時(shí)的候選集大小調(diào)大能提升精度但會(huì)增加延遲。距離度量方面文本 Embedding 一般用 COSINE圖像特征常用 L2某些推薦場(chǎng)景會(huì)用 IP 內(nèi)積。最基礎(chǔ)也最容易出錯(cuò)的是維度一致性索引創(chuàng)建時(shí)的 DIM 必須和 Embedding 模型的輸出維度完全一致。text-embedding-3-small 是 1536 維你生成向量時(shí)模型輸出多少維索引就得這么建差一位都會(huì)導(dǎo)致查詢報(bào)錯(cuò)。2.3 分布式鎖與冪等AI 服務(wù)的并發(fā)底線AI 服務(wù)里的并發(fā)問(wèn)題比傳統(tǒng)接口更難排查。多個(gè) Worker 同時(shí)消費(fèi)同一個(gè)任務(wù)隊(duì)列同一個(gè)請(qǐng)求在網(wǎng)絡(luò)重試下執(zhí)行了兩遍模型預(yù)熱函數(shù)被多個(gè)實(shí)例同時(shí)觸發(fā)——這些場(chǎng)景都需要分布式鎖。Redis 實(shí)現(xiàn)鎖的核心命令是SET key value NX EX secondsNX 保證只有 Key 不存在時(shí)才能寫入EX 設(shè)置自動(dòng)過(guò)期。但最基礎(chǔ)的三行代碼往往藏著坑。第一個(gè)坑是忘記過(guò)期時(shí)間進(jìn)程崩潰后鎖永遠(yuǎn)不釋放死鎖。第二個(gè)坑是鎖過(guò)期時(shí)間設(shè)得太短任務(wù)還沒跑完鎖就自動(dòng)釋放另一個(gè)實(shí)例搶到鎖造成雙重執(zhí)行。第三個(gè)坑是釋放鎖時(shí)不做身份校驗(yàn)線程 A 的鎖可能被線程 B 誤刪。正確姿勢(shì)是用唯一 Token 當(dāng)鎖的值釋放時(shí)用 Lua 腳本先比較再刪除保證原子性。我個(gè)人的選擇邏輯是對(duì)于 AI 任務(wù)去重、冪等控制這類場(chǎng)景標(biāo)準(zhǔn) SETNX 加冪等表已經(jīng)完全夠了如果是扣款、發(fā)券這種強(qiáng)一致業(yè)務(wù)再去考慮 Redisson 的紅鎖。Redis 鎖解決的是高并發(fā)下的互斥問(wèn)題不是分布式事務(wù)問(wèn)題別指望它包治百病。2.4 模塊到內(nèi)核Redis 官方能力演進(jìn)Redis 的擴(kuò)展能力走了一條很有意思的演進(jìn)路線。早期想加搜索、JSON 這類能力需要自己編譯加載模塊模塊之間的版本還容易打架運(yùn)維負(fù)擔(dān)很重。后來(lái)官方推出 Redis Stack把 RediSearch、RedisJSON、RedisTimeSeries 等模塊打包成官方發(fā)行版開箱即用。再到 Redis 8查詢引擎被直接整合進(jìn)核心數(shù)據(jù)庫(kù)向量索引不再是“額外裝的插件”而是主庫(kù)自帶能力。這個(gè)演進(jìn)對(duì)開發(fā)者最大的好處是心智負(fù)擔(dān)大幅降低。以前要研究哪個(gè)模塊版本配哪套 Redis現(xiàn)在下載官方鏡像跑起來(lái)建索引、存 JSON、做查詢都是默認(rèn)能力。我用 Docker 起一個(gè)redis:8鏡像FT.CREATE命令直接可用這就是“Redis 接入 AI”最實(shí)質(zhì)的落地形態(tài)。3. 實(shí)操給 LLM 應(yīng)用加一個(gè) Redis 層的完整記錄3.1 環(huán)境準(zhǔn)備與客戶端選型先說(shuō)我本地的環(huán)境用 Docker 拉一個(gè)官方 Redis 8 鏡像數(shù)據(jù)持久化到本地卷。命令很簡(jiǎn)單docker run -d --name redis-ai -p 6379:6379 -v redis-data:/data redis:8啟動(dòng)后驗(yàn)證一下redis-cli -h localhost -p 6379 127.0.0.1:6379 PING PONG看完數(shù)據(jù)我習(xí)慣用開源客戶端開發(fā)調(diào)試用 redis-cli日常數(shù)據(jù)巡檢用 Another Redis Desktop Manager連接配置里填主機(jī)端口就能看到所有 Key。Windows 用戶注意一點(diǎn)Redis 官方?jīng)]有原生 Windows 版本別去下那些來(lái)路不明的“綠色版”直接用 WSL 或者 Docker 最省心。macOS 用戶用 Homebrew 裝一個(gè)也很簡(jiǎn)單brew install redis一行搞定。3.2 實(shí)現(xiàn)大模型響應(yīng)緩存假設(shè)你用的是兼容 OpenAI 接口的服務(wù)。第一步設(shè)計(jì)緩存 Key我把模型名、歸一化后的 Prompt、temperature 參數(shù)一起做 MD5保證不同參數(shù)組合不會(huì)互相污染import hashlib import time import redis from openai import OpenAI r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) client OpenAI() def normalize_prompt(prompt: str) - str: # 去掉首尾和多余空白避免“同一個(gè)意思”因?yàn)閾Q行產(chǎn)生不同緩存 return .join(prompt.strip().split()) def get_completion(prompt: str, model: str gpt-4o-mini, temperature: float 0.0, ttl: int 3600): cache_key fllm:cache:{model}:{temperature}:{hashlib.md5(normalize_prompt(prompt).encode()).hexdigest()} cached r.get(cache_key) if cached: return cached resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperaturetemperature, ) content resp.choices[0].message.content r.setex(cache_key, ttl, content) return content為什么要把 temperature 加進(jìn) Key因?yàn)?temperature 會(huì)影響生成結(jié)果的隨機(jī)程度。如果只按 Prompt 緩存那么 temperature0 和 temperature1 兩次請(qǐng)求會(huì)混用同一個(gè)結(jié)果這在需要多樣性的場(chǎng)景里是 bug。此外我建議再加一層降級(jí)邏輯模型 API 調(diào)用異常時(shí)優(yōu)先返回緩存結(jié)果至少保證用戶能拿到一次合理的回答。關(guān)鍵細(xì)節(jié)是 Prompt 歸一化。真實(shí)業(yè)務(wù)場(chǎng)景里用戶輸入經(jīng)常帶著亂七八糟的空格和換行直接拿去算 MD5 會(huì)嚴(yán)重拉低緩存命中率。先把空白折疊再哈希命中率會(huì)明顯提升。3.3 用 Redis 完成一次完整的 RAG 向量召回流程分三步生成向量、寫入 Redis、查詢召回。前提是你已經(jīng)有一個(gè) Embedding 模型我習(xí)慣用 OpenAI 的 text-embedding-3-small輸出 1536 維向量。先創(chuàng)建索引。Redis 用命令聲明哈希字段里哪一個(gè)是向量from redis import Redis r Redis(hostlocalhost, port6379) r.execute_command( FT.CREATE, idx_doc, ON, HASH, PREFIX, 1, doc:, SCHEMA, content, TEXT, embedding, VECTOR, HNSW, 6, TYPE, FLOAT32, DIM, 1536, DISTANCE_METRIC, COSINE )向量寫入時(shí)要特別注意序列化方式。Embedding 模型輸出的是浮點(diǎn)數(shù)組必須先轉(zhuǎn)成 Float32 的二進(jìn)制再存不能直接塞 JSON 字符串import numpy as np def encode(text: str): resp client.embeddings.create(modeltext-embedding-3-small, inputtext) return np.array(resp.data[0].embedding, dtypenp.float32).tobytes() r.hset(doc:1, mapping{ content: Redis 緩存策略與 TTL 設(shè)計(jì), embedding: encode(Redis 緩存策略與 TTL 設(shè)計(jì)), })查詢時(shí)同樣要把問(wèn)題轉(zhuǎn)成向量然后執(zhí)行 KNN 搜索query_vec encode(緩存過(guò)期時(shí)間怎么設(shè)置) res r.execute_command( FT.SEARCH, idx_doc, *[KNN 3 embedding $query_vec], PARAMS, 2, query_vec, query_vec, DIALECT, 4 )返回結(jié)果里會(huì)附帶每個(gè)命中文檔的向量距離距離越小代表越相似。把命中的 content 字段取出來(lái)拼進(jìn) Prompt再送給大模型一個(gè)完整的 RAG 鏈路就通了。這里最大的坑是 DIM 必須和模型輸出維度一致以及查詢向量的二進(jìn)制格式必須和索引聲明一致這兩處出錯(cuò)往往不是立刻爆出而是檢索結(jié)果全空。3.4 會(huì)話與 Agent 狀態(tài)管理聊天的消息記錄天然是追加型的我會(huì)用 List 來(lái)存儲(chǔ)。每條消息序列化成 JSON 后 RPUSH 進(jìn)列表一次 LRANGE 就能取回最近 N 條import json def save_message(session_id: str, role: str, content: str, ttl: int 1800): key fchat:{session_id} r.rpush(key, json.dumps({role: role, content: content}, ensure_asciiFalse)) r.expire(key, ttl) def load_recent_messages(session_id: str, limit: int 20): key fchat:{session_id} items r.lrange(key, -limit, -1) return [json.loads(item) for item in items]設(shè)置 TTL 非常關(guān)鍵。Agent 會(huì)話不可能無(wú)限保留半小時(shí)沒有活躍就自動(dòng)清理能避免 Redis 內(nèi)存被歷史對(duì)話撐爆。如果你用的 Redis 8JSON 數(shù)據(jù)類型可以直接存 Agent 的任務(wù)計(jì)劃、工具調(diào)用參數(shù)、執(zhí)行狀態(tài)這類復(fù)雜結(jié)構(gòu)比你自己拼字符串再反序列化要省事得多。我還習(xí)慣把 Agent 的整個(gè)決策過(guò)程路徑寫進(jìn) Redis比如規(guī)劃節(jié)點(diǎn)、工具入?yún)?、中間結(jié)果這比打日志好用。排查問(wèn)題的時(shí)候把整個(gè)執(zhí)行鏈條拉出來(lái)看一眼就能定位是規(guī)劃錯(cuò)了、工具調(diào)用失敗還是模型輸出不符合預(yù)期。4. 常見問(wèn)題與排查實(shí)錄4.1 Command timed out連接池與超時(shí)配置熱詞里出現(xiàn)了一條非常眼熟的報(bào)錯(cuò)redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException。這是 Java Spring 項(xiàng)目里用 Lettuce 客戶端的老問(wèn)題我排查過(guò)不下三次。最常見的原因有三個(gè)連接池太小高并發(fā)下連接被占滿命令執(zhí)行時(shí)間太長(zhǎng)比如一次拉取超大 ValueRedis 服務(wù)端 CPU 被打滿。Spring Boot 場(chǎng)景先把連接池配出來(lái)我常用的參數(shù)如下spring: data: redis: host: localhost port: 6379 timeout: 3000 lettuce: pool: max-active: 50 max-idle: 20 min-idle: 2 max-wait: 3000如果確認(rèn)是超大 Value 導(dǎo)致的超時(shí)不要無(wú)腦調(diào)大 timeout更好的做法是拆 Key 和壓縮。比如把幾千條消息的 JSON 拆成按天分片讀取時(shí)只拿需要的片段。配合 Redis 的 slowlog 命令排查那些執(zhí)行時(shí)間過(guò)長(zhǎng)的命令方向基本不會(huì)錯(cuò)。4.2 序列化亂碼與向量二進(jìn)制的坑Java 后端特別容易踩序列化的坑。Spring Data Redis 默認(rèn)的 JDK 序列化器會(huì)把對(duì)象變成一串不可讀的亂碼你連可視化工具里排查都很痛苦。我的建議是統(tǒng)一用 JSON 序列化Key 用 StringRedisSerializerValue 用 GenericJackson2JsonRedisSerializerBean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); StringRedisSerializer keySerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer valueSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(keySerializer); template.setHashKeySerializer(keySerializer); template.setValueSerializer(valueSerializer); template.setHashValueSerializer(valueSerializer); template.afterPropertiesSet(); return template; }但是做向量存儲(chǔ)時(shí)反而要反過(guò)來(lái)注意向量字段本質(zhì)上是二進(jìn)制數(shù)據(jù)塊絕不能用 JSON 序列化器去序列化 NumPy 數(shù)組否則向量維度對(duì)不上檢索結(jié)果直接崩潰。二進(jìn)制的數(shù)據(jù)就老老實(shí)實(shí)用二進(jìn)制序列化兩種序列化策略按存儲(chǔ)內(nèi)容分開用別圖省事一套配置通吃。4.3 主從、持久化與淘汰策略AI 場(chǎng)景里 Redis 存的數(shù)據(jù)價(jià)值密度比傳統(tǒng)緩存高得多向量索引重建極其耗時(shí)絕不能接受重啟丟數(shù)據(jù)。我的建議至少開啟 AOF 持久化并且配置合理的淘汰策略。用 Docker Compose 搭主從也很方便一條命令就能把讀寫分離跑起來(lái)services: redis-master: image: redis:8 command: redis-server --appendonly yes ports: - 6379:6379 redis-replica: image: redis:8 command: redis-server --replicaof redis-master 6379 --appendonly yes depends_on: - redis-master ports: - 6380:6379緩存場(chǎng)景的 maxmemory 策略用allkeys-lru但如果你在同一個(gè) Redis 實(shí)例里又放緩存又放向量索引要小心 LRU 淘汰把向量數(shù)據(jù)誤殺了。我的經(jīng)驗(yàn)是向量索引的 Key 前綴單獨(dú)規(guī)劃淘汰策略選擇noeviction靠 TTL 保證內(nèi)存可控寧肯緩存未命中也不讓向量索引丟失。4.4 可視化工具與日常運(yùn)維清單日常巡檢 Redis我很少看那些花里胡哨的監(jiān)控面板幾條命令足夠了。INFO MEMORY看內(nèi)存水位SLOWLOG GET 10看慢命令CLIENT LIST看連接數(shù)?？梢暬矫鍭nother Redis Desktop Manager 夠用支持 JSON 格式查看和命令執(zhí)行調(diào)試 Python 寫進(jìn)去的哈希結(jié)構(gòu)非常直觀。還有一個(gè)很多人忽略的習(xí)慣上線 AI 相關(guān) Redis 功能之前先在測(cè)試環(huán)境把FT.SEARCH的查詢計(jì)劃跑一遍。向量索引如果字段類型配置錯(cuò)誤建索引時(shí)不一定報(bào)錯(cuò)但查詢時(shí)會(huì)出現(xiàn)無(wú)法解析的詭異現(xiàn)象。這類問(wèn)題在可視化工具里看數(shù)據(jù)形態(tài)很容易發(fā)現(xiàn)別等到線上爆了再去翻日志。說(shuō)實(shí)話Redis 接入 AI 在我這里最大的收獲不是省了多少錢而是讓我重新理解了基礎(chǔ)設(shè)施的價(jià)值它往往是被新場(chǎng)景二次挖掘出來(lái)的。以前寫緩存只想著扛流量現(xiàn)在發(fā)現(xiàn)同一個(gè)東西在向量召回、上下文記憶、冪等控制里照樣好使。下次再有人問(wèn) AI 項(xiàng)目基礎(chǔ)設(shè)施怎么起步我的答案還是那句——先把你手頭的 Redis 用透。