背景痛点：轮询撑不住的高并发
去年“618”大促，公司老版客服面板还是最朴素的setInterval + AJAX——每 3 秒拉一次接口。流量一上来，CDN 带宽直接飙红，后端 QPS 从 2 k 涨到 20 k，CPU 被打到 90%，用户侧消息延迟 6 s+，投诉工单雪花一样飞。
痛定思痛，我们总结出智能客服对实时性的三条硬指标：
- 首包延迟 < 300 ms（用户打字后能看到“对方正在输入…”）
- 99 线消息不丢、不乱序
- 移动端弱网（2G/电梯）下，断线 30 s 内必须无感重连
轮询方案在 TCP 三次握手、HTTP 头部冗余、无效 304 响应等叠加下，根本扛不住。于是我们把目光投向“长连接”。
技术选型：WebSocket 为什么赢
| 方案 | 协议开销 | 全双工 | 自动重连 | 防火墙友好 | 结论 | |---|---|---|---|---|---|---| | 短轮询 | 大 | 假 | 无 | 友好 | 直接 pass | | 长轮询 | 中 | 假 | 需自实现 | 友好 | 延迟 1 s+，仍不可控 | | SSE | 小 | 半双工 | 浏览器原生 | 友好 | 仅服务端→客户端，客服输入需额外接口 | | WebSocket | 极小 | 真 | 需自实现 | 需 Upgrade | 双向、低延迟，控制灵活，最终胜出 |
小贴士：内网有老防火墙拦截
Upgrade头？先让运维放通ws(s)://端口，再配HTTP/2 + WebSocket over h2，一条 TCP 解决多路复用，省 30% 握手时间。
核心实现三板斧
1. React + Redux 状态架构
我们把“消息”抽象成唯一数据源，UI 只做纯函数渲染，避免 setState 地狱：
store 结构：
interface ChatState { sid: string; // 当前会话 conn: WebSocket | null; // 连接实例 queue: Message[]; // 顺序消息 lruc: LRU<string, Message>;// 本地去重 typing: boolean; // 正在输入 }中间件：
所有 ws 帧统一走wsMiddleware，内部负责序列化、解包、背压控制，组件只 dispatch 普通 action，彻底解耦。
2. 连接池与心跳
客服后台是多节点集群，前端按“uid % 8”哈希到 8 条信道，做成简易连接池，避免单 socket 20 M 流量打满。
心跳策略：
- 每 25 s 发
ping帧（Opcode=0x9） - 若 3 s 内无
pong，记一次miss - 连续 2 次
miss触发重连
经验值：25 s 既不会触发 NAT 超时（常见 60 s），又能把功耗降 15%
3. 消息分片 & 压缩
单条消息 > 1 kB 时启用per-message-deflate，实测平均压缩率 42%；
图片/文件先走 OSS 直传，拿到url后再塞到扩展字段，防止 TCP 粘包导致 JSON 截断。
graph TD A[用户输入] -->|Redux Action| B(wsMiddleware) B -->|>1kB| C[压缩] B -->|<1kB| D[直接发送] C --> E[WebSocket 帧] D --> E E --> F[服务端网关] F -->|pong| G[心跳保活]代码实战：可复用的 TS 封装
以下代码均在我们线上 20 w 日活项目跑通，可直接拷走改路径。
WebSocket 封装（带自动重连）
/** * 带指数退避的 WebSocket 客户端 * @example * const ws = new SmartWS({url: 'wss://im.example.com'}); * ws.on('message', msg => console.log(msg)); */ export default class SmartWS extends Event { private url: string; private ws: WebSocket | null = null; private reconnectTime = 1_000; // 初始重连间隔 private maxReconnectTime = 30_000; private timer: ReturnType<typeof setTimeout> | null = null; constructor({ url }: { url: string }) { super(); this.url = url; this.connect(); } /** 建立连接 */ private connect() { if (this.ws?.readyState === WebSocket.OPEN) return; this.ws = new WebSocket(this.url); this.ws.onopen = () => { this.reconnectTime = 1_000; // 重置退避 this.emit('open'); }; this.ws.onmessage = (e) => this.emit('message', e.data); this.ws.onclose = () => this.handleClose(); this.ws.onerror = (err) => this.emit('error', err); } /** 指数退避重连 */ private handleClose() { if (this.timer) return; // 避免重复计时 this.timer = setTimeout(() => { this.timer = null; this.connect(); }, this.reconnectTime); this.reconnectTime = Math.min(this.reconnectTime * 2, this.maxReconnectTime); } /** 外部发送 */ public send(data: any) { if (this.ws?.readyState === WebSocket.OPEN) { this.ws.send(typeof data === 'string' ? data : JSON.stringify(data)); } } /** 主动关闭 */ public close() { this.ws?.close(); if (this.timer) clearTimeout(this.timer); } }消息队列 LRU 缓存（防重复、防内存爆）
/** * 简易 LRU，用于消息幂等 */ class LRU<K, V> { private max: number; private cache: Map<K, V>; constructor(max = 200) { this.max = max; this.cache = new Map(); } get(key: K): V | undefined { const val = this.cache.get(key); if (val) { this.cache.delete(key); this.cache.set(key, val); // 提到最前 } return val; } set(key: K, val: V) { if (this.cache.has(key)) this.cache.delete(key); else if (this.cache.size >= this.max) { const first = this.cache.keys().next().value; this.cache.delete(first); } this.cache.set(key, val); } }生产环境三板斧
1. 断线重连：指数退避 + 随机抖动
上面handleClose已实现指数退避，但高并发场景下，如果所有客户端在同一毫秒重连，照样把网关冲垮。于是加一段随机抖动：
const jitter = Math.random() * 500; this.reconnectTime = Math.min(this.reconnectTime * 2, this.maxReconnectTime) + jitter;2. 内存泄漏检测
- Chrome DevTools → Memory → Take heap snapshot，两次快照对比
Map/closure是否线性上涨 - 在 middleware 中打印
store.getState().queue.length，上线初期每 10 s 上报 Sentry，>300 自动报警
3. 性能压测（k6 脚本片段）
import ws from 'k6/ws'; import { check } from 'k6'; export let options = { stages: [ { duration: '30s', target: 1000 }, // 逐步爬坡 { duration: '1m', target: 5000 }, { duration: '30s', target: 0 }, ], }; export default function () { const url = 'wss://im.example.com'; ws.connect(url, null, (socket) => { socket.on('open', () => { socket.send(JSON.stringify({ uid: __VU, content: 'hi' })); }); socket.on('message', (data) => { check(data, { 'msg returned': (r) => r && r.includes('uid') }); socket.close(); }); }); }跑出来的数据：
- 5 k 并发，CPU 峰值 68%，P99 延迟 180 ms
- 内存占用 1.2 G，无泄漏增长
避坑指南
跨域：
如果前端https://a.com调wss://b.com，一定让后端把Access-Control-Allow-Origin加上，同时给Sec-WebSocket-Protocol做签名验证，防止任意域握手。移动端网络抖动：
监听navigator.onLine并不可靠，我们做法是：- 在
visibilitychange时检测document.hidden - 切到后台 5 min 后主动
close()，切回前台再new SmartWS，省电又省内存。
- 在
消息幂等：
每条消息带uuid，服务端做唯一索引；前端 LRU 先查重，再决定是否渲染，防止用户点发送按钮两次出现“双胞胎”气泡。
效果 & 小结
上线两周，客服面板整体延迟从 6 s 降到 180 ms，后端 QPS 下降 85%，带宽节省 55%，客服同学终于不用被用户催“你到底有没有收到我的图？”
更重要的是，代码层面把“连接”与“业务”彻底解耦，后续做排队系统、机器人客服，都直接复用同一套wsMiddleware，改两行 action 就能上线。
开放问题
文本客服解决了，但用户越来越“懒”，想直接语音/视频通话。
WebRTC 虽然能做 P2P，可客服席位高并发、录音合规、多端兼容都是坑。
如果你做过 WebRTC + 客服，欢迎聊聊：
- 如何优雅回退到语音消息？
- 多端混流录制存储成本怎么压？
期待你的实战分享，一起把“智能客服”卷到下一站。
