从零构建高可用Chatbot网页：核心代码解析与性能优化实战-开发者社区

背景痛点：传统轮询为何撑不住 Chatbot 流量

Chatbot 网页最早普遍采用「短轮询」：前端每 1-2 秒发起一次 HTTP 请求，询问服务端是否有新消息。该方案实现简单，却在生产环境暴露出三大硬伤：

无效请求占比高：服务端 90% 以上返回 204 No Content，浪费带宽与 CPU
状态同步困难：HTTP 无状态，每次需携带完整会话上下文，报文体积膨胀
延迟不可控：轮询间隔与实时性成反比；缩短间隔虽降低延迟，却成倍放大 QPS，导致服务端雪崩

当并发在线人数过万时，短轮询的额外握手、TLS 协商、Cookie 解析等开销，使单机 QPS 飙升至 8-10 万，CPU 空转 70% 以上，完全背离「毫秒级对话体验」的业务目标。

技术选型对比：WebSocket vs SSE vs Ajax 轮询

维度	WebSocket	Server-Sent Events	传统 Ajax 轮询
协议	TCP 之上帧协议	HTTP/1.1 流	HTTP/1.1 短连接
延迟	毫秒级（单向 <40 ms）	秒级（受 retry 字段限制）	秒级（受轮询间隔限制）
兼容性	IE≥10、iOS≥5	IE 不支持、Edge≤79 需 polyfill	全平台
服务端压力	低（长连接、无重复握手）	中（HTTP 开销仍在）	高（频繁握手）
防火墙友好度	需额外开放 80/443	默认放行 80/443	默认放行
双工能力	全双工	仅服务端→客户端	半双工
代码复杂度	需心跳、重连、帧解析	仅需重连	简单

结论：Chatbot 需要客户端随时回传「正在输入」状态，且对延迟极度敏感，WebSocket 是唯一能在浏览器侧实现全双工且毫秒级推送的协议。

核心实现：Node.js 高可用 WebSocket 服务

以下示例基于 ws 8.x，符合 ESLint Airbnb 规范，关键函数均带 JSDoc。

1. 服务端骨架（app.js）

/** * 创建 WebSocket 服务并挂载到现有 HTTP 服务 * @module ChatSocket */ const http = require('http'); const WebSocket = require('ws'); const redis = require('redis'); const server = http.createServer(); const wss = new WebSocket.Server({ server }); const pub = redis.createClient({ host: '127.0.0.1', port: 6379 }); const sub = redis.createClient({ host: '127.0.0.1', port: 6379 }); /** * 向 Redis 订阅全局消息频道 */ sub.subscribe('chat:broadcast'); /** * 心跳检测：服务端定时 ping，客户端需回 pong * @param {WebSocket} ws */ function heartbeat(ws) { clearTimeout(ws.pongTimeout); ws.pongTimeout = setTimeout(() => ws.terminate(), 30000); } wss.on('connection', (ws, req) => { ws.isAlive = true; ws.on('pong', () => { ws.isAlive = true; }); heartbeat(ws); /** * 收到客户端消息后发布到 Redis，实现多进程解耦 */ ws.on('message', (data) => { const msg = JSON.parse(data); pub.publish('chat:broadcast', JSON.stringify(msg)); }); /** * Redis 收到广播后推送至当前连接 */ sub.on('message', (_, message) => { if (ws.readyState === WebSocket.OPEN) ws.send(message); }); ws.on('close', () => clearTimeout(ws.pongTimeout)); }); /** * 定时心跳轮询 */ setInterval(() => { wss.clients.forEach((ws) => { if (!ws.isAlive) return ws.terminate(); ws.isAlive = false; ws.ping(); }); }, 30000); server.listen(8080);

2. 前端消息队列与防抖（client.js）

/* global WebSocket */ /** * 会话状态管理 */ class Session { constructor() { this.ws = null; this.queue = []; // 待发送缓冲 this.reconnectInterval = 1000; this.debounceTimer = null; } connect() { this.ws = new WebSocket(`wss://${location.host}/ws`); this.ws.onopen = () => { this.reconnectInterval = 1000; this.flushQueue(); }; this.ws.onmessage = (e) => this.renderMessage(JSON.parse(e.data)); this.ws.onclose = () => this.reconnect(); this.ws.onerror = () => this.ws.close(); } /** * 防抖：300 ms 内无新输入才发送 * @param {Object} payload */ send(payload) { clearTimeout(this.debounceTimer); this.debounceTimer = setTimeout(() => { if (this.ws.readyState === WebSocket.OPEN) { this.ws.send(JSON.stringify(payload)); } else { this.queue.push(payload); } }, 300); } /** * 重连指数退避 */ reconnect() { setTimeout(() => { this.connect(); }, this.reconnectInterval); this.reconnectInterval = Math.min(this.reconnectInterval * 2, 30000); } flushQueue() { while (this.queue.length && this.ws.readyState === WebSocket.OPEN) { this.ws.send(JSON.stringify(this.queue.shift())); } } }

3. 异常处理要点

服务端捕获uncaughtException后仅记录日志，切勿process.exit()，否则心跳线程直接掉线
前端onerror仅触发 close，具体错误信息通过onclose的event.code区分：
- 1006 为异常断链，需立即重连
- 1000 为正常关闭，无需重连

性能优化：Redis 解耦与连接池调优

1. Redis 发布/订阅模式

将业务逻辑（NLP 调用、敏感词过滤）拆成独立微服务，通过 Redis 频道通信，WebSocket 进程仅负责「收发帧」，CPU 占用下降 35%，垂直扩展性提升 4 倍。

2. 连接池参数压测

| 场景 | 默认池(10) | 调优池(50) | 无池 | |---|---|---|---|---| | 平均 RTT(ms) | 210 | 45 | 900 | | 99th 延迟(ms) | 1200 | 180 | 3200 | | 超时错误率 | 2.3% | 0.1% | 12% |

调优后redis.createClient增加：
retry_unfulfilled_commands: true,
maxRetriesPerRequest: 3,
pool: { min: 5, max: 50 }

避坑指南

跨域安全
- 使用ws原生支持headers.origin校验，拒绝非白名单站点
- 若前端与 WebSocket 端口不同，需同时配置Access-Control-Allow-Origin与Allow-Headers: authorization
大消息分片
WebSocket 单帧上限 2^63，但 nginx 默认proxy_max_temp_file_size仅 1 MB。
方案：
- 前端按 64 KB 切片，携带{ index, total, chunk }
- 服务端缓存至 Redis List，收齐后合并转发
客户端内存泄漏
- 每次onmessage若使用innerHTML +=会持有旧 DOM 节点；改用documentFragment拼接
- 断链后未清理setInterval心跳，导致闭包持有旧ws对象；在onclose内统一clearInterval