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

Wiggle266

304人浏览 · 2026-01-31 00:42:32

Wiggle266 · 2026-01-31 00:42:32 发布

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

摘要：本文深入解析七鱼智能客服系统的核心技术架构，重点解决高并发场景下的消息处理瓶颈问题。通过分析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，千兆内网

指标	HTTP 短轮询(1 s)	HTTP 长轮询(30 s)	WebSocket
QPS	20 000	1 200	50
吞吐(MiB/s)	18.3	1.1	0.12
P99 延迟	1.02 s	30.1 s	28 ms
CPU 占用	78%	41%	9%

结论：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 双保险

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

连接建立时，Gateway 把 userId 做一致性哈希，同一用户永远落到同一 Broker 组（Sticky）
首次握手后，Broker 将会话快照写 Redis Hash，TTL 15 min
若节点宕机，Gateway 通过 Redis 探活，发现会话后把流量重定向到幸存副本，实现“秒级”漂移
对坐席端，七鱼额外提供 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%

生产环境避坑指南

消息幂等
每条消息带 msgId UUID，消费表建联合索引 (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