电商平台智能客服系统接入实战：高并发场景下的架构设计与避坑指南-程序员充电站

电商平台智能客服系统接入实战：高并发场景下的架构设计与避坑指南

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 友好；更复杂的语义检测放离线日志里事后审计。