企业官网建设流程全解析

七鱼智能客服架构解析：如何实现高并发场景下的稳定消息处理

摘要：本文深入解析七鱼智能客服系统的核心技术架构，重点解决高并发场景下的消息处理瓶颈问题。通过分析WebSocket长连接管理、消息队列削峰填谷、分布式会话保持等关键技术方案，帮助开发者理解如何构建稳定高效的智能客服系统。文章包含Spring Boot集成示例代码和性能压测数据，适用于中高级后端开发者。

从一次“爆线”说起：高并发客服系统的真实痛点

去年双十一，某头部电商的自研客服网关在短短 5 分钟内涌入 18 万并发长连接，CPU 飙到 98%，Full GC 每 3 秒一次，最终 WebSocket 网关集群雪崩，用户端出现大面积“消息已发出但被对方拒收”的假象。事后复盘，核心问题被浓缩成三句话：

• 短轮询模型把 80% 流量浪费在 404 响应
• 单节点 FD 上限 65535，被瞬间打满
• 会话状态放本地内存，节点挂掉即“丢单”

七鱼智能客服在早期也踩过同样的坑，最终演进出一条“接入层无状态、逻辑层可水平扩展、存储层读写分离”的技术路线。下文把这套方案拆开聊。

轮询 vs. WebSocket：一次基准对照实验

测试环境

• 4C8G Docker 容器 * 3 台
• 客户端 1000 线程，每线程 20 连接，消息 240 byte JSON
• 网络 RTT 0.8 ms，千兆内网

结论：WebSocket 把网络往返与序列化开销销降到最低，CPU 下降一个数量级，是高并发客服场景的事实标准。

七鱼三层架构鸟瞰图

1. 接入层（Gateway）

• 基于 Netty 4.1，Epoll 边缘触发，零拷贝
• 单实例 4C8G 可扛 25 万并发长连接（调优后 FD 上限 100 万）
• 只做两件事：TLS 卸载 + 二进制帧转发，不解析业务 Payload

2. 逻辑层（Broker）

• Spring Boot 3 + Reactor Netty，无阻塞 IO
• 通过 Redis Stream 做事件总线，消费组水平扩展
• 核心职责：消息路由、坐席分配、意图识别、脚本引擎

3. 存储层（Storage RocksDB + MySQL）

• 热数据：Redis JSON 存最近 7 天会话，读 < 1 ms
• 冷数据：RocksDB 按 userId 分片，顺序写 50 万条/秒
• 审计：MySQL 8.0 只存归档，Binlog 同步到数仓

Spring Boot 集成 WebSocket 代码示例

以下示例基于 Java 17 + Spring Boot 3.2，演示如何限制单节点连接数、统一入口收消息。

@Configuration @EnableWebSocketMessageBroker public class WsConfig implements WebSocketMessageServerConfigurer { @Override public void registerStompEndpoints(StompEndpointRegistry reg) { reg.addEndpoint("/ws") .setAllowedOriginPatterns("*") .withSockJS(); // 降级方案 } @Override public void configureMessageBroker(MessageBrokerRegistry registry) { registry.setApplicationDestinationPrefixes("/app"); // 业务前缀 registry.enableSimpleBroker("/queue", "/topic"); // 内存代理，生产换 Redis } @Override public void configureWebSocketTransport(WebSocketTransportRegistration reg) { reg.setMessageSizeLimit(5 * 1024) // 单帧 5 KiB .setSendBufferSizeLimit(50 * 1024) // 发送缓存 .setSendTimeLimit(10_000); // 10 s 超时 } } @RestController public class ChatController { private final AtomicInteger online = new AtomicInteger(0); private static final int MAX_CONN = 30_000; @MessageMapping("/chat.send") @SendToUser("/queue/reply") public Mono<ChatResp> handle(ChatReq req, SimpMessageHeaderAccessor head) { if (online.incrementAndGet() > MAX_CONN) { return Mono.error(new ResponseStatusException( HttpStatus.TOO_MANY_REQUESTS dims 429)); } return chatService.reply(req) .doFinally(s -> online.decrementAndGet()); } }

要点

• 用AtomicInteger做内存级限流，防止 FD 暴涨
• 返回Mono而非阻塞字符串，背压由 Reactor 自动管理
• 生产环境把enableSimpleBroker换成StompBrokerRelay，指向 Redis Cluster

分布式会话保持：Redis + Sticky Session 双保险

无状态扩容最怕“换节点丢上下文”。七鱼方案：

1. 连接建立时，Gateway 把userId做一致性哈希，同一用户永远落到同一 Broker 组（Sticky）
2. 首次握手后，Broker 将会话快照写 Redis Hash，TTL 15 min
3. 若节点宕机，Gateway 通过 Redis 探活，发现会话后把流量重定向到幸存副本，实现“秒级”漂移
4. 对坐席端，七鱼额外提供 HTTP 轮询补偿接口，WebSocket 断链 3 s 内自动降级，保证客服不丢单

压测显示，30 台 Broker 随机下线，99.5% 会话在 1.2 s 内完成漂移，用户侧无感知。

性能优化三板斧

1. Netty 连接池调优

• SO_BACKLOG = 4096
• TCP_NODELAY = true
• ALLOCATOR = PooledByteBufAllocator
  单节点 4C8G 可顶 25 万并发，CPU 余量 35%

2. 心跳与空闲检测

• 客户端每 25 s 发PING帧
• 服务端 45 s 未读即触发IdleStateEvent，主动close()释放 FD
• 避免防火墙静默断开造成的死连接堆积

3. 消息压缩

• 对 > 1 KiB 的 JSON 启用permessage-deflate，压缩率 65%
• 坐席端批量拉历史时，采用gzip+application/x-ndjson，带宽节省 65%

生产环境避坑指南

• 消息幂等
  每条消息带msgIdUUID，消费表建联合索引(userId, msgId)，MySQL 唯一键冲突即丢弃，保证不重发

• 断线重连策略
  指数退避：1 s → 2 s → 4 s … 上限 60 s；重连时带lastMsgId，Broker 按>条件补推，避免重复

• 内存泄漏检测
  Netty 的FastThreadLocal与ThreadLocal混用易泄漏，启动参数加-Dio.netty.recycler.maxCapacityPerThread=0关闭对象池，配合jemalloc的prof:true采样，压测 12 h 堆外内存零增长才准上线

• TCP 粘包
  WebSocket 帧自带payload len，应用层无需处理；若自定义二进制协议，务必用LengthFieldBasedFrameDecoder

开放讨论：实时性与最终一致性如何平衡？

客服场景里，用户希望“秒回”，而坐席端需要看到“准确实时的访客轨迹”。若采用强一致事务，每一次消息都二阶段提交，吞吐直接掉到 1/10。七鱼目前策略：

• 用户→网关→Broker 写 Redis 主库，同步返回成功，延迟 < 10 ms
• Redis 主从异步复制，坐席端可能 50 ms 后看到，属于“最终一致”
• 对支付、敏感操作，额外走 MySQL 强一致通道，牺牲部分吞吐换安全

问题是：当业务继续扩张，单元化、跨机房容灾成为刚需，延迟与一致性的矛盾会更加尖锐。是否该引入“读写链分离 + 逻辑时钟”？或者干脆把会话事件流当成 CQRS 事件源，允许客户端做冲突合并？欢迎留言探讨。