数据库规模的有状态对话:每个生产聊天功能都需要的会话存储架构
· 阅读需 11 分钟
大多数工程师在生产中而非设计评审时发现他们的会话架构是错误的。演示运行良好:你用五条消息进行了测试,对话历史可以放入内存,LLM 也能连贯地响应。然后你上线了,在第一批千个并发会话与第一次部署滚动之间,用户开始遇到上下文遗忘、部分响应或会话无故重置的问题。让聊天功能原型设计变得简单的内存模式,正是使其在运营中变得脆弱的根源。
这并不是一个微妙的架构错误。对话状态与请求状态有着本质区别。请求状态只存活数毫秒;对话状态必须能够在 Pod 重启、水平扩展、部署周期和移动网络中断中存活——持续数分钟、数小时或数天。建立在错误抽象上的系统会产生可靠性债务,随着对话长度增长和用户负载增加而累积。
