Live800智能客服系统架构解析：从高并发处理到消息队列优化-编程实验室

背景痛点：高并发下的“三座大山”

做客服系统的同学都知道，流量一旦上来，最先感受到的不是“用户热情”，而是“系统哀嚎”。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，后台定时任务人工巡检，防止客服消息“人间蒸发”。