Chatbot Arena网址实战构建高可用对话系统的架构设计与避坑指南背景痛点流量洪峰下的“三座大山”去年双十一我们给电商客服做了一套 Chatbot Arena 风格的实时对话系统凌晨 0 点流量瞬间飙到 4.2 万 QPS老架构直接“躺平”响应延迟从 200 ms 涨到 3 sCPU 空转在 JSON 序列化WebSocket 长连接 30 s 一断用户重连后上下文丢失只能再问一遍“我的订单呢”多轮会话状态放在本地 HashMap节点一挂聊天记录灰飞烟灭。痛定思痛我们决定用微服务事件驱动重新设计目标只有一个在 5 k 并发下P99 延迟 300 ms消息 0 丢失。技术选型HTTP 轮询 vs WebSocket vs gRPC先在同配置 4C8G 容器里跑压测数据如下单轮 256 byte 负载协议QPSP99 延迟CPU 占用备注HTTP 轮询(1 s)6 k1.1 s35%大量 304移动端耗电WebSocket28 k45 ms40%长连接节约 3 倍带宽gRPC*32 k38 ms45%需要 HTTP/2 网关调试略重*注gRPC 在浏览器侧需借助 grpc-web多一层 Envoy最终我们把它留给内部微服务调用对外依旧 WebSocket。核心实现Spring WebFlux Redis Stream3.1 非阻塞 WebSocket 端点用 Spring WebFlux 的ReactiveWebSocketHandler做入口Netty 事件循环线程只有 8 个却能扛住 5 k 并发关键是“异步到底”class ChatSocketHandler(private val chatService: ChatService) : WebSocketHandler { override fun handle(session: WebSocketSession): MonoVoid { val receive session.receive() .map { it.payloadAsText } .doOnNext { Metrics.counter(chat.in.msg, type, user).increment() } .flatMap { msg - chatService.handle(msg, session.id) } .onErrorResume { ex - log.warn(ws error: ${ex.message}) session.send(Mono.just(session.textMessage({code:500}))) } val send chatService.outboundFlux(session.id) .map { session.textMessage(it) } .doOnNext { Metrics.counter(chat.out.msg, type, bot).increment() } return session.send(send.mergeWith(receive.then())) } }3.2 Redis Stream 做消息总线每个节点把用户消息写到chat:{roomId}流消费组保证至少一次送达public MonoString handle(String msg, String sessionId) { String record buildRecord(msg, sessionId); return redisReactive.exec( RedisStreamCommands.XADD, chat: extractRoomId(sessionId), *, payload, record) .thenReturn(OK); }下游 LLM 服务独立成组拉取→推理→写回结果流实现“生产-消费”解耦节点扩容只需加消费组即可。3.3 分布式会话状态会话快照用 Redis Hash 存储结构session:{id} → {uid,roomId,ctxSeq,lastMsgAt}并通过Redisson的RMapCache设置 15 min 过期防止僵尸数据val bucket redisson.getMapCacheString, SessionSnapshot(session:$sessionId) bucket.put(ctxSeq, snapshot.ctxSeq, 15, TimeUnit.MINUTES)每次 LLM 返回时先WATCHMULTI保证ctxSeq单调递增解决并发写乱序问题。性能优化压测、调参、结果4.1 JMeter 5000 并发场景持续 5 min每秒新建 100 连接累计 30 k 长连接吞吐量稳定在 28 k 消息/秒P99 延迟 280 msCPU 65%内存 3.2 G0 消息丢失0 超时断开。4.2 连接池与内核参数Netty 侧SO_BACKLOG4096SO_REUSEADDRtrueSO_RCVBUF/SO_SNDBUF256 kRedis 侧Lettuce 线程池ioThread4timeout3 scluster fresh interval30 sLinux 侧echo net.core.somaxconn 65535 /etc/sysctl.conf echo net.ipv4.tcp_tw_reuse 1 /etc/sysctl.conf调完单机能扛 50 k 并发握手。避坑指南踩过的坑一个都别落下5.1 心跳与 TCP KeepAlive 冲突早期我们把WebSocketSession空闲超时设为 30 s又打开系统tcp_keepalive_time60结果 NAT 网关 50 s 回收连接服务端 30 s 没收到心跳就主动关客户端看到的却是“神秘 1006 错误”。解法心跳 25 s 一次应用层超时 ≥ 2 个心跳周期系统 KeepAlive 留给内网外网一律靠业务心跳。5.2 消息幂等Redis Stream 的 ID 即唯一键LLM 回包时把 ID 带在字段msgId里前端重复点击先查本地Set再决定是否发 ACK保证“一条答案只渲染一次”。5.3 灰度兼容WebSocket 子协议名带版本号例如chatbot.v2.json老版本客户端拒绝升级时网关自动路由到 v1 集群同时 JSON 新增字段放ext对象做到“向下兼容”。互动环节跨数据中心会话同步你会怎么做当用户从北京机房漂到上海连接重新建立如何把未读消息与上下文毫秒级同步是用 Redis Cluster 的WAIT命令等写 propagate还是通过 Kafka MirrorMaker 做双向复制或者干脆把会话快照放全球表用 CRDT 冲突自由合并欢迎留言聊聊你的方案一起把坑填平。小结与动手福利把 Chatbot Arena 的“人机对战”思路搬到生产级对话系统本质就是解决高并发、低延迟、强一致三件事协议选 WebSocket服务拆微状态放 Redis消息走 Stream监控加 Metrics灰度留协议版本——照着做5 k 并发只是起点。如果你想亲手把 ASR→LLM→TTS 整条链路跑通又懒得自己搭网关、调音色可以试试这个一站式实验从0打造个人豆包实时通话AI里面把火山引擎的豆包语音系列模型都封装好了WebSocket 网关、Redis 流式消费、异常重试、监控埋点全配齐本地docker-compose up就能跑。我跑完第一版只花了 45 分钟改两行配置就让 AI 用“四川话”回我效果还挺稳。对于想快速验证实时对话原型、又不想先踩一轮坑的同学绝对够用。