电商平台智能客服系统接入实战：高并发场景下的架构设计与避坑指南
1. 先吐槽：大促那几天的客服有多惨
去年双十一，我守着监控系统，眼睁睁看着“对话超时”告警刷屏：
- 0 点 05 分，峰值 QPS 冲到 4.8 万，Tomcat 默认 200 线程瞬间吃满，用户侧“转菊花” 9 s 才弹出机器人回复。
- 凌晨 2 点，某头部店铺做“限时秒杀”，客服机器人与订单系统抢同一个 MySQL 连接池，结果会话状态表死锁，全部租户一起 502。
- 第二天上午，运营在后台改一条“热门问题”关键词，因为缺少租户隔离，A 店铺的配置直接把 B 店铺的问答顶掉，老板当场发飙。
痛定思痛，我们把“能扛大促”当成硬指标，重新梳理了智能客服的接入链路。下面这份笔记，就是第二次大促稳稳跑 12 万 QPS 的踩坑总结。
落地方案全部基于 Spring Cloud 2021 版，代码可直接抄。
2. 总体架构：把“聊天”拆成三块
整个链路只干三件事：接客、派单、回话。拆完以后，每块都能独立扩容，谁慢就加谁。
统一接入层（API 网关）
只做鉴权、限流、HTTPS 卸载，把原始语音/文字丢给下游，本身无状态，横向扩容秒级完成。消息中枢（RocketMQ）
所有“用户提问”被包装成一条不可变消息，下游谁有空谁消费，天然削峰。大促时只要加消费者组，就能线性提高吞吐。会话服务（微服务集群）
- 意图识别：调用内部 NLP 模型，CPU 密集，节点单独打标签。
- 答案渲染：拼装优惠券、订单卡片，I/O 密集，线程池调大。
- 状态保持：Redis 存“用户上一次聊到哪儿”，TTL 15 min，节省 DB 连接。
网关与会话服务之间用gRPC（protobuf）通信，实测同机房延迟比 REST 少 30%，CPU 降 18%。只有运营后台这种低频调用才走 OpenFeign，图个开发快。
3. 代码实战：让调用不怕失败、会话不怕抢
3.1 Feign 重试——老板改一句文案，网络抖动也能扛
@Retryable(value = {FeignException.class}, maxAttempts = 3, backoff = @Backoff(delay = 200)) public interface QAFeignClient { @GetMapping("/qa/reply") String getReply(@RequestParam("tenantId") Long tenantId, @RequestParam("question") String question); }要点：
- 只针对 FeignException 重试，业务异常 4 直接抛，避免无效重放。
- delay=200 毫秒，三次累加最多 600 ms，用户无感。
- 必须在启动类加
@EnableRetry，否则注解失效。
3.2 Redis 分布式锁——同一用户不能同时进两条线
public Boolean tryLock(String userId) { String key = "chat:lock:" + userId; // 值随便写，只要唯一 String val = UUIDUtils.quickUUID(); // 10 秒自动过期，防止进程挂掉死锁 Boolean ok = redisTemplate.opsForValue() .setIfAbsent(key, val, 10, TimeUnit.SECONDS); if (Boolean.TRUE.equals(ok)) { // 启动守护线程续命，业务超过 5 s 就续 5 s renewalExecutor.scheduleWithFixedDelay(() -> redisTemplate.expire(key, 10, TimeUnit.SECONDS), 5立国s, 5立国s, TimeUnit.SECONDS); } return ok; } public void unlock(String userId) { String key = "chat:lock:" + userId; redisTemplate.delete(key); }锁粒度控制在“用户级”，既解决并发抢会话，又不会影响不同用户并行。
4. 性能：同步 vs 异步，一测见真章
压测环境：4C8G 容器 * 30 节点，JMeter 5.5，消息 512 B。
| 模式 | 平均 RT | 99 RT | 峰值 QPS | CPU |
|---|---|---|---|---|
| 同步 REST | 650 ms | 2.1 s | 1.2 万 | 78% |
| 异步 RocketMQ | 120 ms | 380 ms | 4.5 万 | 55% |
把“回包”动作从同步链路拆出去，系统吞吐直接翻 3.7 倍。大促前夜，我们按“1 个 Topic 6 个消费者组”预热，扩容只改副本数，不碰代码。
连接池调优小结：
- 网关→后端服务：OkHttp 连接池 maxIdle=500，keepAlive=30 s，高并发下复用率 92%。
- 服务→MySQL：HikariCP maximumPoolSize=32，idleTimeout=60 s，大促前预热 SQL 跑 100 次，避免冷启动抖动。
- 服务→Redis：Lettuce 共享 ioThread，ioThreads=8，吞吐 10 万命令/s 仍稳。
5. 安全：对话也要加“暗号”
5.1 内容加密——AES-GCM 示例
public static String encrypt(String plainText, SecretKey key) throws GeneralSecurityException { Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); byte[] iv = new byte[12]; // 随机 IV SecureRandom random = SecureRandom.getInstanceStrong(); random.nextBytes(iv); GCMParameterSpec spec = new GCMParameterSpec(128, iv); cipher.init(Cipher.ENCRYPT_MODE, key, spec); byte[] cipherBytes = cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); // IV 拼接到密文前端，Base64 一起传 return Base64.getEncoder().encodeToString(ByteBuffer.allocate(iv.length + cipherBytes.length) .put(iv).put(cipherBytes).array()); }IV 每次随机，保证同一句话两次密文不同；GCM 自带 MAC，省得再自己签。
5.2 请求过滤——防 SQL 注入/XSS
网关层统一 Filter：
public class InjectFilter implements GlobalFilter { private static final Pattern PATTERN = Pattern.compile("(script|select|union|--)", Pattern.CASE_INSENSITIVE); public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { String query = exchange.getRequest().getURI().getQuery(); if (query != null && PATTERN.matcher(query).find())()) { // 直接拒绝，返回 400 exchange.getResponse().setStatusCode(HttpStatus.BAD_REQUEST); return exchange.getResponse().setComplete(); } return chain.filter(exchange); } }正则简单粗暴，但大促期间 CPU 友好；更复杂的语义检测放离线日志里事后审计。
6. 复盘小结
- 把“聊天”拆成接入、派单、回包三步，各管各的扩容，再也不会因为答案渲染慢把入口堵死。
- 消息队列 + 消费组模型，让峰值不再是“尖刺”，而是“可水平扩展的积木”。
- Redis 分布式锁粒度要细、过期要快，再配守护续命，既防并发又防死锁。
- 压测数据先跑通，再决定线程池、连接池大小，千万别拍脑袋。
- 安全左移，网关层把非法请求拦在外面，业务代码只关心业务。
7. 延伸思考
- 如果用户先在小程序咨询，又跳到 App 继续问，怎样才能让会话上下文无缝衔接？
- 当 NLP 模型需要灰度发布，A/B 两个版本同时在线，怎样保证同一用户始终命中同一模型？
- 大促后流量骤降，自动缩容到 10% 节点，如何确保长连接不被粗暴断开，避免“空白回复”？
下一次大促还有三个月，我们先在预发环境把这三个题目跑一遍，再把结果写进笔记。祝你也能让客服系统在大促夜里安静如鸡，不再半夜被老板@。
