最近在做一个智能客服系统的升级其中一个核心模块就是“转人工”。这个功能听起来简单不就是把用户从机器人对话切换到人工坐席嘛但真做起来坑是一个接一个。用户排队排到天荒地老、好不容易接通了还得把问题重新说一遍、高峰期系统直接卡死……这些问题不解决用户体验就是灾难。经过一番折腾我们最终基于事件驱动架构搞出了一套能扛住高并发的方案这里就把从设计到踩坑的全过程记录下来希望能帮到有类似需求的同学。1. 背景与核心痛点为什么转人工这么难在深入技术细节前我们先看看转人工流程到底有哪些“坑”。理解了问题解决方案才有针对性。会话状态同步困难这是最头疼的问题。用户在和机器人对话时生成了大量的上下文Context包括用户问题、机器人回复、可能的用户画像、业务流水号等。当用户点击“转人工”时如何将这些上下文完整、实时地传递给人工坐席端如果传递失败用户就得重新描述问题体验极差。高并发下的排队雪崩促销或活动期间咨询量激增。如果转人工请求的处理是同步阻塞的大量请求会堆积在服务器线程池导致响应时间飙升甚至拖垮整个客服系统形成雪崩效应。转接延迟与用户流失用户等待接通的时间哪怕只多几秒放弃率都会显著上升。传统的轮询Polling方式间隔长、实时性差加剧了用户的焦虑感。重复转接与资源浪费由于网络抖动或前端重复点击可能导致同一个会话向多个坐席发送转接请求造成坐席资源被无效占用。坐席负载不均如何将转接请求智能地分配给最合适、最空闲的坐席而不是简单地轮询这也是提升效率的关键。2. 技术选型轮询、长连接还是WebSocket针对实时性要求高的转接通知和上下文同步我们对比了几种常见方案短轮询Polling客户端定时比如每秒向服务器询问“轮到我没” 实现简单但延迟高、服务器压力大大量无效请求不适合高并发场景。长轮询Long Polling客户端发起请求服务器hold住连接直到有事件如坐席就绪或超时才返回。比短轮询实时性好一些但每个连接在等待期间都占用服务器资源连接数有上限。WebSocket全双工通信协议一旦建立连接服务器和客户端可以随时主动推送消息。这是我们的最终选择。它完美解决了实时性问题一个连接即可持续通信服务器资源占用相对高效非常适合转接状态同步、坐席消息推送这类场景。基于WebSocket我们自然采用了事件驱动架构Event-Driven Architecture。整个转接流程被抽象为一系列事件UserRequestTransferEvent用户请求转接、SessionContextPreparedEvent会话上下文就绪、AgentAssignedEvent坐席分配成功、TransferCompletedEvent转接完成。系统组件通过发布/订阅这些事件来协同工作实现了高度的解耦和异步处理能力从容应对突发流量。3. 核心实现构建异步非阻塞的转接网关整个系统的核心是一个转接网关Transfer Gateway它负责接收用户转接请求协调上下文准备、坐席分配并推送状态。3.1 使用Spring WebFlux实现异步网关我们选择了Spring WebFlux而非传统的Spring MVC因为它基于Reactor项目提供了真正的非阻塞Non-blocking异步编程模型能够用少量线程处理大量并发连接非常适合IO密集型的网关服务。/** * 转人工请求控制器 * 使用WebFlux实现非阻塞处理 */ RestController RequestMapping(/transfer) Slf4j public class TransferController { Autowired private TransferService transferService; /** * 处理用户转人工请求 * param request 包含userId, sessionId等信息 * return 返回转接请求ID用于后续状态查询 */ PostMapping(/request) public MonoResponseEntityTransferResponse requestTransfer(RequestBody TransferRequest request) { // 1. 参数校验 (略) // 2. 调用异步服务处理转接请求 return transferService.processTransferRequest(request) .map(transferId - ResponseEntity.ok(new TransferResponse(transferId, 转接请求已受理))) .onErrorResume(e - { log.error(转接请求处理失败, e); return Mono.just(ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR) .body(new TransferResponse(null, 系统繁忙请稍后再试))); }); } } /** * 转接服务核心类 */ Service Slf4j public class TransferService { Autowired private ApplicationEventPublisher eventPublisher; Autowired private SessionContextService sessionContextService; Autowired private AgentAssignService agentAssignService; /** * 处理转接请求流程 * 注意此方法应在反应式链中调用避免阻塞操作 */ public MonoString processTransferRequest(TransferRequest request) { // 生成唯一转接ID用于幂等性控制 String transferId IdUtil.fastSimpleUUID(); // 1. 发布事件开始处理转接请求异步保存请求记录等 eventPublisher.publishEvent(new UserRequestTransferEvent(transferId, request)); // 2. 异步准备会话上下文 MonoSessionContext contextMono sessionContextService.prepareContextAsync(request.getSessionId()); // 3. 异步分配坐席 (依赖上下文准备完成) return contextMono.flatMap(context - agentAssignService.assignAgentAsync(context, transferId)) .doOnSuccess(agentId - { // 4. 坐席分配成功发布事件通知网关推送消息给用户和坐席 eventPublisher.publishEvent(new AgentAssignedEvent(transferId, agentId, request.getUserId())); }) .thenReturn(transferId); // 返回转接ID } }3.2 Redis分布式会话存储设计会话上下文需要被转接网关和坐席端共享并且要设置过期时间我们选择Redis作为分布式存储。数据结构使用Hash存储整个会话上下文对象Key为session:context:{sessionId}。TTLTime To Live生存时间策略设置合理的过期时间如30分钟避免无用数据常驻内存。在每次更新上下文时刷新TTL。内存淘汰策略在Redis配置中我们选择了allkeys-lru策略当内存不足时淘汰最近最少使用的键保证服务稳定性。/** * 会话上下文服务 */ Service public class SessionContextService { Autowired private StringRedisTemplate redisTemplate; /** * 异步准备并保存会话上下文 * param sessionId 会话ID * return 包含上下文的Mono对象 */ public MonoSessionContext prepareContextAsync(String sessionId) { return Mono.fromCallable(() - { // 模拟从其他服务或数据库获取完整的对话历史、用户信息等 SessionContext context fetchFullContextFromSource(sessionId); String redisKey session:context: sessionId; // 使用Hash结构存储 MapString, String contextMap BeanUtil.beanToMap(context, new HashMap(), false, true); redisTemplate.opsForHash().putAll(redisKey, contextMap); // 关键设置TTL为30分钟 redisTemplate.expire(redisKey, 30, TimeUnit.MINUTES); log.info(会话上下文已保存至Redis key: {}, redisKey); return context; }).subscribeOn(Schedulers.boundedElastic()); // 将阻塞操作调度到弹性线程池 } /** * 根据sessionId获取上下文 * 注意此方法可能被多个线程坐席端、网关同时调用但Redis操作本身是原子性的线程安全。 */ public SessionContext getContext(String sessionId) { String redisKey session:context: sessionId; MapObject, Object entries redisTemplate.opsForHash().entries(redisKey); if (entries.isEmpty()) { return null; } // 刷新TTL表示这个上下文还在被使用 redisTemplate.expire(redisKey, 30, TimeUnit.MINUTES); return BeanUtil.mapToBean(entries, SessionContext.class, false); } }3.3 基于Sentinel的熔断与降级在调用坐席分配服务、上下文服务等下游依赖时必须防止因某个服务不稳定导致网关线程池被拖垮。我们集成Sentinel进行流量控制、熔断降级。# application.yml Sentinel 配置示例 spring: cloud: sentinel: transport: dashboard: localhost:8080 # Sentinel控制台地址 web-context-unify: false # 在代码中定义资源和降级规则 Configuration public class SentinelConfig { PostConstruct public void initRules() { // 定义针对坐席分配服务的熔断规则 ListDegradeRule rules new ArrayList(); DegradeRule rule new DegradeRule(assignAgentService) .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_COUNT) // 按异常数熔断 .setCount(5) // 5个异常 .setTimeWindow(10) // 熔断时间窗口10秒 .setMinRequestAmount(5); // 最小请求数 rules.add(rule); DegradeRuleManager.loadRules(rules); } } /** * 坐席分配服务使用Sentinel资源注解进行保护 */ Service public class AgentAssignService { /** * 异步分配坐席 * 使用SentinelResource定义资源并指定降级方法 */ SentinelResource(value assignAgentService, blockHandler assignAgentBlockHandler, fallback assignAgentFallback) public MonoString assignAgentAsync(SessionContext context, String transferId) { // 模拟调用坐席调度中心可能是一个远程RPC服务 return WebClient.create(http://agent-center/assign) .post() .bodyValue(new AssignRequest(context, transferId)) .retrieve() .bodyToMono(String.class) .timeout(Duration.ofSeconds(5)) // 设置超时 .doOnError(e - log.warn(分配坐席服务调用异常, e)); } /** * 流控或熔断时的处理BlockException */ public MonoString assignAgentBlockHandler(SessionContext context, String transferId, BlockException ex) { log.warn(触发Sentinel熔断/流控转入备用分配逻辑, ex); // 降级策略返回一个标记让用户进入排队队列或分配一个兜底坐席组 return Mono.just(fallback-agent-group-001); } /** * 业务异常时的降级处理Throwable */ public MonoString assignAgentFallback(SessionContext context, String transferId, Throwable t) { log.error(分配坐席服务业务异常执行降级, t); return Mono.just(fallback-agent-group-001); } }4. 实战避坑指南光有核心代码还不够生产环境里的一些细节问题才是真正的“杀手”。幂等性处理防止重复转接用户可能因网络延迟重复点击“转人工”。我们在后端为每个转接请求生成唯一transferId如UUID。在处理请求时先检查transferId是否已存在于Redis或数据库中。如果已存在直接返回之前的结果确保同一请求只被处理一次。// 在TransferService.processTransferRequest开始处加入幂等校验 public MonoString processTransferRequest(TransferRequest request, String idempotentKey) { // 先查Redis看这个幂等键是否已处理过 Boolean absent redisTemplate.opsForValue().setIfAbsent(transfer:idempotent: idempotentKey, PROCESSING, 5, TimeUnit.MINUTES); if (Boolean.FALSE.equals(absent)) { return Mono.error(new BusinessException(重复的转接请求)); } // ... 后续正常处理流程 }上下文丢失的Fallback策略如果从Redis获取会话上下文失败可能已过期我们不能让流程卡住。我们的策略是尝试从备份的持久化存储如数据库中加载最近的一份快照。如果仍然失败则创建一个最小化的上下文至少包含用户ID和最后一条机器人对话记录并记录告警事后人工补全。Nginx层连接数优化WebSocket连接需要通过Nginx代理。默认配置可能无法支持大量长连接需要调整# nginx.conf 部分优化参数 http { # 增加每个Worker进程能打开的最大文件数连接数受此限制 worker_rlimit_nofile 65535; upstream websocket_backend { server 10.0.0.1:8080; server 10.0.0.2:8080; # 支持WebSocket的负载均衡 } server { listen 80; location /ws { proxy_pass http://websocket_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; # 以下参数对保持长连接很重要 proxy_read_timeout 3600s; # 长连接超时时间 proxy_send_timeout 3600s; proxy_connect_timeout 75s; } } }5. 性能验证JMeter压测报告方案上线前我们使用JMeter进行了压力测试模拟用户高并发请求转人工。场景5000个用户线程在1分钟内启动持续请求转接接口同时维持WebSocket连接接收状态更新。关键指标吞吐量TPS稳定在 5200 请求/秒达到预期目标。平均响应时间 50ms 仅指受理请求的API。P99延迟99%的请求响应时间 100ms。这意味着绝大多数用户感觉不到延迟。错误率 0.1%。主要错误来自网络抖动导致的WebSocket连接断开业务逻辑错误极少。资源消耗网关服务器4核8GCPU平均使用率约65%内存使用平稳无Full GC。证明了异步非阻塞模型在高并发下的优势。6. 延伸思考Serverless架构下的优化可能当前架构虽然稳定但仍在虚拟机/容器层面。如果迁移到Serverless架构如阿里云函数计算、AWS Lambda转人工流程可能会有新的优化点极致弹性转接网关的每个请求处理函数可以独立伸缩无需预先规划容量理论上可应对无限并发。成本优化在没有转接请求时函数计算成本为零。而坐席分配、上下文准备等事件处理也可以拆分为独立的函数按需付费。挑战Serverless的冷启动延迟可能影响首次响应速度需要预留实例或优化代码包体积。此外WebSocket的长连接状态管理在无状态函数中是个挑战可能需要借助外部的连接管理服务如云厂商提供的WebSocket API网关。可能的架构用户直接连接云厂商的WebSocket网关网关将事件触发函数执行。函数负责处理业务逻辑并将需要持久化的状态写入Redis或数据库。这样业务逻辑完全无服务器化运维复杂度大大降低。总结构建一个高可用的智能客服转人工系统关键在于异步、解耦、容错。通过采用事件驱动架构和WebSocket保证实时性利用Spring WebFlux和Redis提升并发处理能力与状态共享再结合Sentinel做好服务保护这套组合拳下来系统就能变得既健壮又灵敏。当然每套业务都有其特殊性文中提到的方案和代码更多是提供一种思路和参考实际落地时还需要根据具体情况进行调整和细化。希望这篇笔记能为你带来一些启发。