背景痛点当 ChatBot 突然“爆火”去年双十一公司把客服 ChatBot 全量开放给 C 端用户峰值 QPS 从 300 飙到 2800三个老问题集中爆发响应延迟同步调用 NLP 服务线程池瞬间打满P99 延迟从 600 ms 涨到 4.2 s。会话状态丢失Tomcat 原生 Session 粘滞在节点内存扩容时用户被“踢回首页”。部署复杂度单体 war 包 200 MB滚动发布一次 8 min回滚还要手动清理本地缓存。一句话用户激增 体验雪崩。下文记录我们如何用“微服务 事件驱动”把系统重新救回来。技术选型gRPC、WebSocket 还是 REST先跑一轮基准测试机器 4C8G同机房payload 统一 1 KB JSON协议连接方式平均 QPSP99 延迟备注REST短链接4 200110 ms无状态易缓存gRPCHTTP/2 多路复用9 80045 ms二进制省 30% 带宽WebSocket长链接6 50060 ms服务端维持 FD内存高结论入口网关继续 REST保持无状态方便 CDN 缓存静态答案。对话通道升级到 WebSocket降低 30% 往返 RTT。内部微服务用 gRPC利用 ProtoBuf 减少序列化开销。为什么选 Spring Boot RedisSpring Boot生态成熟有 WebSocket 开箱即用的STOMP支持。Redis单线程模型天然适合队列与状态机6.x 以上多 IO 线程读 QPS 轻松 10 w。核心实现一用 Redis Stream 做消息队列需求同一个用户可能同时发多条消息必须保证“幂等 顺序”。代码示例Google Java Style/** * 将用户消息推入 Redis Stream并返回消息 ID 用于去重。 * 时间复杂度O(log N) 其中 N 为 Stream 长度 */ public String addMessage(String userId, String payload) { MapString, String kv Map.of(uid, userId, body, payload); // 使用 * 让 Redis 自动生成毫秒级序列号 RecordId recordId redisOps.opsForStream().add(STREAM_KEY, kv); return recordId.getValue(); // 格式 1622000000000-0 } /** * 消费端按用户维度做幂等用 Redis SETNX 防重放。 * 时间复杂度O(1) */ public void handleMessage(MapRecordString, String, String record) { String msgId record.getId().getValue(); String userId record.getValue().get(uid); Boolean absent redisOps.opsForValue() .setIfAbsent(dup: msgId, 1, Duration.ofMinutes(5)); if (Boolean.TRUE.equals(absent)) { // 真正处理业务 nlpService.reply(userId, record.getValue().get(body)); } }要点Stream 的 ID自增 ID 天然是“时间 序号”直接当全局去重键。消费组用XREADGROUP支持多实例并行抢任务失败XACK不提交可重试。核心实现二对话状态机与持久化UML 状态图PlantUML 语法startuml [*] -- Welcome: 用户连接 Welcome -- Waiting: 发送首次消息 Waiting -- Processing: NLP 开始 Processing -- Waiting: 返回结果 Processing -- Timeout: 10 s 无响应 Timeout -- Waiting: 提示重试 Welcome -- [*]: 断开连接 enduml持久化方案状态快照用 Redis Hashkey state:{userId}field currentState、variablesJSON。每次状态跃迁先写 Redis再发布DomainEvent到 Stream实现“事件溯源”。扩容时新节点通过XREAD历史游标快速重建内存态用户无感知。生产考量一压测数据JMeter 场景1000 并发线程每线程 10 次对话每次 3 轮交互。结果成功率 99.92%失败多为 502 网关超时Gateway 层限流。平均 RT 520 msP99 1.1 sCPU 峰值 68%内存 4.2 GB。Redis Stream 消费延迟 20 ms未出现消费堆积。调优经验网关层加Circuit Breaker/熔断器阈值 50% 错误率窗口 10 s。WebSocket 节点开 4 个事件循环线程EventLoopGroup与业务线程池隔离。生产考量二JWT 安全刷新ChatBot 会话可能持续 30 min不能让旧令牌无限续期。策略Access Token 有效期 10 minRefresh Token 7 天。用户每次发消息带Authorization: Bearer access网关统一验签。剩余 2 min 时前端调用/refresh后端校验 Refresh Token 后下发新 access旧令牌加入 Redis 黑名单防止并发使用。代码片段public void revoke(String jti) { redisOps.opsForValue().set(black: jti, 1, Duration.between(Instant.now(), expireAt)); }黑名单查询 O(1)内存占用可忽略。避坑指南NLP 冷启动延迟方案发布前批量预热脚本顺序调用高频意图如“退货流程”“运费咨询”把模型加载到 GPU配合Kubernetes 的 preStop hook把旧 Pod 流量摘干净再下线。对话超时处理对比三种模式客户端轮询简单但 5 s 一次加重网关负担。服务端异步回调需维护回调地址防火墙常拦。WebSocket 心跳 服务端推送选它超时直接发{type:TIMEOUT}前端弹窗提示。线程池隔离刚开始把 NLP 调用放在业务线程池结果慢查询把池吃光WebSocket 连心跳都发不出去。拆出独立Bulkhead/舱壁线程池后稳态 CPU 降 15%。代码规范小结全项目用Spotless插件强制 Google Java StyleCI 阶段自动格式化。关键算法写清时间复杂度如上文addMessage注释。日志用/slf4j MDC每条打印带userId与traceId方便链路追踪。延伸思考让 LLM 更懂用户意图传统意图分类靠关键词 正则维护成本高。我们正尝试把 BERT 微调成领域模型收集 20 w 条客服对话人工标注 128 个意图。用Chinese-BERT-wwm做继续预训练再上层加TextCNN微调F1 从 0.81 提到 0.93。模型导出 ONNX丢进ONNX Runtime-Java推理单次耗时 18 ms比云端 NLP 还快。下一步准备把LLM BERT 意图路由结合先由小模型快速分类再决定调用哪个垂直大模型减少 40% Token 消耗。写在最后如果你也想亲手搭一套能扛住高并发的 ChatBot又苦于没有完整 Demo可以试试我上周刚刷完的从0打造个人豆包实时通话AI动手实验。它把 ASR、LLM、TTS 串成一条低延迟链路代码全开源本地 Docker 一把梭就能跑。跟着做完再把我这篇笔记里的 Redis Stream、状态机、JWT 刷新方案套进去就能快速得到一个可上生产的微服务骨架。小白也能顺利体验我实际跑下来挺顺省了不少踩坑时间。祝你编码愉快对话永不掉线