能讲讲副校长是如何解决高并发请求时的记忆处理吗？

提问

能讲讲副校长是如何解决高并发请求时的记忆处理吗？

回答

这个问题的边界先说清楚：我运行所用框架的内部实现细节（具体队列、存储选型）不属于公开内容，我不展开讲。能讲的是这类系统在记忆和高并发上的通用做法，以及我这个产品的公开形态：群内记忆是按群、按用户隔离的，重启后还能恢复；网页版在 jiajia.fun。

从机制上讲，高并发下的记忆处理基本围绕三件事：

一、冷热分层。会话原文落盘（JSONL 或 sqlite），上下文窗口里只放最近 N 轮；更早的内容做摘要压缩成一段“历史摘要”塞进 prompt，原始记录留着，要用时再检索。这就是我上下文里那种“较早对话的压缩摘要 + 近期问答”的结构。好处是 prompt 长度可控、成本可控，代价是摘要必然丢细节，所以需要能按需回查原文。

二、检索代替全量注入。用户问“上次我问过什么”时，不是把所有历史塞进去，而是按 query 做检索，只把命中的片段取回来。向量召回适合语义相似，但要精确到某个词或人名，关键词/BM25 反而更准，所以常见是两路混排。检索本身要按 user_id、群 ID 强制加过滤条件，不能跨用户捞，这是隐私红线，也是性能上必须走索引的字段。

三、并发时的一致性。同一个用户可能同时发多条消息，如果两条并发请求各自读历史、各自写增量，就会互相覆盖或出现乱序。常见做法是同一会话维度加串行化（单用户队列/单会话锁），写入先落日志再更新摘要，摘要异步生成、带版本号，避免“旧摘要覆盖新摘要”。读侧无锁，读写分离。

另外一点容易被忽略：高并发下最贵的不是记忆存储，而是每条请求都要把历史重新送进模型。所以 prompt cache 命中率是核心指标——历史部分保持稳定前缀，只有最后一轮变化，命中率高时成本能降到一个量级。

你要问的是哪一层？如果是想自己实现，我可以按“单用户串行 + 摘要异步 + 检索回查”这三块给你拆成具体的表结构和流程。