基于Java的智能客服管理系统实战：高并发场景下的架构设计与性能优化

基于Java的智能客服管理系统实战：高并发场景下的架构设计与性能优化

去年双十一，公司把客服系统从外包 SaaS 切到自研，流量一上来就“炸”了：高峰期 3 万并发，消息延迟飙到 8 s，会话还偶尔丢。老板一句“用户体验不能打折”，我们只好连夜重构。三个月趟坑下来，系统吞吐量翻了 3 倍，P99 响应压到 200 ms 以内。把过程拆成 7 个段落，照着做，基本能复制出一套扛得住大促的智能客服平台。

第一段：把痛点拆成可量化的指标

1. 消息延迟：Web 版客服后台出现“排队 99+”，用户端却收不到回复，日志里看到 WebSocket 帧堆积在 SendBuffer。
2. 会话丢失：刷新页面后 customerId 与 agentId 映射消失，原因是默认的 Spring Session 放在本地内存，多节点不 sticky 就找不到。
3. 并发冲突：两个客服同时点击“接入”同一位顾客，DB 出现唯一键冲突，前端却都显示“接待成功”。
4. 缓存穿透：FAQ 热点 Key 被瞬间打爆，MySQL QPS 涨到 1.8 万，CPU 90%+。
5. 水平扩展瓶颈：早期 All-in-one 的 Spring Boot 单体，4C8G 机器加到 8 台，RT 不降反升，线程卡在日志锁。

第二段：技术选型——别追新，先对齐场景

• 框架：Spring Boot 2.7 vs Quarkus 2.16
  前者生态全、团队熟悉熟悉会；后者编译快、内存省，但二方包少。客服系统业务重、第三方 SDK 多，最终保留 Spring Cloud 2021.x，把 Quarkus 留给后续意图模块做实验。
• 数据：MySQL 8 vs MongoDB 5
  会话事件需要事务强一致，MySQL 主从+组复制更稳；FAQ、知识库读多写少，MongoDB 更灵活。于是“会话”放 MySQL，“知识库”放 Mongo，各取所长。

第三段：总体架构图

流量顺序：Nginx → Gateway → 客服服务/机器人服务 → Redis 缓存 → MySQL/Mongo。Gateway 统一做鉴权、限流、灰度；服务内部用 Spring WebFlux + Netty 的 epoll 模式扛长连接。

第四段：核心实现三件套

1. WebSocket 实时推送
   采用 STOMP over WebSocket，Spring 配置setMessageSentBufferSizeLimit(512*1024)防止帧堆积；前端 SockJS 做 3 次降级，保证老浏览器也能轮询。
2. Redis 会话状态
   将会话抽象成 Hash：key=cs:session:{roomId}，field=customerId/agentId/status，TTL=30 min，客服发最后一条消息时自动续期。节点宕机时，新实例根据 roomId 重新加载 Hash，实现“会话漂移”。
3. 分布式锁
   客服抢单场景用 Redisson 的 RLock，waitTime=2 s，leaseTime=5 s，看门狗默认续期；锁 key 设计为lock:room:{roomId}，保证同一时刻只有一个客服能 changeStatus。

第五段：关键代码（Spring Cloud Gateway 路由 + 消息处理）
先给网关配一条带限流的路由：

spring: cloud: gateway: routes: - id: customer-service uri: lb://customer-service predicates: - Path=/ws/cs/** filters: - name: RequestRateLimiter args: rate-limiter: redis key-resolver: "#{@remoteAddrKeyResolver}" replenishRate: 800 # 每秒 800 连接 burstCapacity: 1200

客服服务端点核心片段（精简掉异常处理）：

@Component @ServerEndpoint("/ws/cs/{roomId}") public class CsWebSocket { private static final ConcurrentHashMap<String, Session> SESSIONS = new ConcurrentHashMap<>(); @OnOpen public void onOpen(Session session, @PathParam("roomId") String roomId) { // 1. 幂等校验：已存在就关闭旧连接 Session old = SESSIONS.put(roomId, session); if (old != null && old.isOpen()) { old.close(); } // 2. 恢复会话 restoreSession(roomId); } @OnMessage public void onMessage(String payload, @PathParam("roomId") String roomId) { // 3. CAS 自增消息序号，防止乱序 long seq = RedisUtils.incr("seq:" + roomId); // 4. 异步写 MySQL 后，Redis Pub/Sub 推给其它节点 csMessageProducer.send(new CsMessage(roomId, payload, seq)); } }

第六段：性能优化——压测、调参、看指标

1. JMeter 场景：300 线程、每线程 100 次 WebSocket 双工对话，Payload 512 B。
   优化前：平均 RT 1100 ms，95% 2300 ms，错误率 6%。
   优化后：平均 RT 180 ms，95% 220 ms，错误率 0.1%。
2. 连接池调优（HikariCP）：
   • maximumPoolSize = 60（CPU 核心*2）
   • minimumIdle = 20
   • connectionTimeout = 800 ms
   • idleTimeout = 120 s
3. Netty 参数：
   • SO_BACKLOG = 1024
   • SO_REUSEADDR = true
   • EPOLL开启（Linux 环境）
4. Redis 管道化：一次批 200 条指令，RTT 省 70%。

第七段：避坑指南——都是血与泪

• Nginx 长连接：
  默认keepalive_timeout 65 s，WebSocket 握手后还走 HTTP 升级，一定加proxy_read_timeout 3600s;，否则 1 分钟静默就断。
• 消息幂等：
  前端生成 UUID，后端用 RedisSETNX uuid 1 EX 300做去重；失败告诉前端重拉，防止“重复答”。
• MySQL 自增主键：
  会话表用BIGINT且步长=1，在组复制里会频繁锁；改AUTO_INCREMENT_INCREMENT=4后，写热点分散到 4 个节点。
• 日志异步：
  同步 Appender 打满磁盘 IO，RT 抖动明显；换成 Logback-async+Disruptor，QPS 涨 18%。

第八段：总结与可延伸方向
整套方案把“无状态网关 + 有状态服务 + 分布式缓存”串在一起，核心是让任何节点都能在短时间内重建会话，从而支持水平扩展。下一步打算把意图识别模块独立成 gRPC 微服务，模型用 TensorFlow Serving，通过 Quarkus 做 Native-Image 启动，内存压到 60 MB，再和现有 WebSocket 流打通，实现“机器人先回，人工兜底”的混合模式。如果你也在做客服，欢迎交流压测脚本和 Redis 大 Key 扫描工具，一起把 RT 打得更低。