背景痛点：高并发下的“三座大山”
做客服系统的同学都知道，流量一旦上来，最先感受到的不是“用户热情”，而是“系统哀嚎”。Live800在高峰期曾同时在线 30w+ 座席+访客，我们踩过的坑可以总结成三座大山：
- 消息丢失：Tomcat 默认 200 线程打满后，新连接直接 RST，前端看起来就是“客服没回我”。
- 响应延迟：早期用 HTTP 轮询，1.5 s/次，浏览器 F12 一看，瀑布流全在 pending；访客端平均首响 4.2 s，客服端 6.1 s。
- 会话状态漂移：4 台实例无粘性，刷新网页后 ws 落到新节点，内存里的会话 Map 瞬间失效，用户被踢出房间。
这三座山不搬走，智能客服就只剩“智障”。
技术选型：轮询、长轮询与 WebSocket 的“三维对比”
| 维度 | 短轮询 | 长轮询 | WebSocket |
|---|---|---|---|
| 延迟 | 1~2 s | 300~500 ms | <100 ms |
| 吞吐 (单核) | 3 k qps | 5 k qps | 25 k qps |
| 服务端消耗 | 低 | 中（挂起线程） | 高（连接状态） |
| 防火墙亲和 | 优 | 中 | 差（需放行 Upgrade） |
结论：
- 对外访客端必须走 WebSocket，延迟第一。
- 对内客服端并发量更大，但可接受 200 ms 级延迟，因此引入消息队列做“异步削峰”，既解耦又背压。
- 最终方案：WebSocket + Kafka（双副本、零拷贝，单机 17w qps 实测）。
核心实现：代码级拆解
1. 消息生产端（客服发消息）
// 客服端事件入口，Spring Boot Controller @RestController @RequiredArgsConstructor public class AgentController { private final KafkaTemplate<String, Message> kafkaTemplate; @PostMapping("/api/send") public ApiResp<Void> send(@RequestBody Message msg) { // 1. 幂等键 = 会话ID+客服ID+客户端时间戳 String key = msg.getSessionId() + ":" + msg.getAgentId() + ":" + msg.getClientTs(); // 2. 异步发送，背压由 kafka 客户端缓冲 kafkaTemplate.send("chat.topic", key, msg) .addCallback( ok -> log.info("send ok, offset={}", ok.getRecordMetadata().offset()), fail -> log.error("send fail", fail)); return ApiResp.success(); } }2. 消息消费端（推送给访客 WebSocket）
@Component @Slf4j public class ChatConsumer { private final SimpMessagingTemplate ws; // Spring WebSocket private final RedisTemplate<String, Long> redis; @KafkaListener(topics = "chat.topic", groupId = "im-server") public void onMessage(ConsumerRecord<String, Message> record, Acknowledgment ack) { try { Message body = record.value(); // 1. 幂等判断：Redis setnx 过期 60s String dedupKey = "dedup:" + record.key(); if (Boolean.FALSE.equals(redis.opsForValue().setIfAbsent(dedupKey, 1L, 60, TimeUnit.SECONDS))) { log.warn("duplicate msg dropped, key={}", dedupKey); ack.acknowledge(); // 仍要提交，避免重平衡 return; } // 2. 推送到指定会话 ws.convertAndSendToUser(body.getSessionId(), "/queue/chat", body); ack.acknowledge(); } catch (Exception e) { log.error("consume error", e); // 不提交 ack，Kafka 会按 max.poll.interval 重试 } } }3. 连接池与线程模型
- Netty 做 WebSocket 接入层，Boss/Worker 线程分离，默认 2×CPU 核心。
- 业务线程池采用 ForkJoinPool，队列长度 8k，拒绝策略：抛异常→客户端触发重连→负载最低节点。
- Kafka Producer 端开启
delivery.timeout.ms=5s+retries=Integer.MAX_VALUE，保证 99.9% 写成功。
性能优化：把“单机 QPS”卷到 25 万
1. 基准数据（16C32G，Kafka 1 副本）
| 场景 | 指标 |
|---|---|
| 生产 | 17.3 w/s |
| 消费 | 21.1 w/s |
| 端到端 P99 | 38 ms |
2. 水平扩展
- 分区数 = max(客服并发, 访客并发) / 2000，向上取整；我们 8 个 Broker，64 分区，可线性扩展到 200 w/s。
- WebSocket 层无状态，K8s HPA 按 CPU 60% 触发，30s 内可拉起 3 倍 Pod。
3. 熔断降级
采用 Sentinel，核心规则两条：
- 慢调用比例 >40% 且 RT>500 ms 时，熔断 5 s；
- 异常比例 >5% 时，降级返回“客服忙，请稍后”静态页。
避坑指南：顺序、死信与内存
1. 消息顺序性
Kafka 只能保证分区内顺序；
做法：同一 session 写固定分区 →key=sessionId，客服端按 session 聚合发送，可避免“客服先回 A 后回 B，访客端看到 B 在前”的尴尬。
2. 死信队列（DLQ）
spring.kafka.listener.concurrency: 8 spring.kafka.consumer.properties.max.poll.interval.ms: 300000 spring.kafka.consumer.properties.isolation.level: read_committed # 死信配置 deadLetterTopic: chat.topic.dlq消费 6 次仍失败即进 DLQ，后台定时任务人工巡检，防止客服消息“人间蒸发”。
3. 内存泄漏
- Netty 忘记
release()ByteBuf → 用SimpleChannelInboundHandler，自动管理。 - ThreadLocal 用完未清理 → 采用 TransmittableThreadLocal + 线程池装饰器，任务结束强制 remove。
- Kafka Producer 缓存监控：JMX 指标
buffer-available-bytes< 50% 即报警。
延伸思考：AI 智能路由怎么玩
- 实时情绪识别：把访客分词+情绪模型打分，路由到“高情商”客服组，差评率下降 18%。
- 预测等待：基于 Kafka Streams 滑动窗口，计算各客服未来 30 s 负载，动态分流，平均等待从 42 s 降到 27 s。
- 模型热更新：通过 MQ 下发模型版本号，各节点监听后异步加载，灰度 5% 节点，效果 OK 再全量，避免“一发布就回滚”。
写在最后
把 Live800 从“能跑”做到“抗住”再到“跑得稳”，核心就是把同步变异步、把状态变无状态、把故障变可控。消息队列不是银弹，但用对了，它确实能让客服系统告别“假死”，让访客和客服都少掉几根头发。希望上面的代码和数字，能帮你少踩几次我们踩过的坑，也欢迎一起交流更骚的优化思路。
