最近在做一个智能客服项目客户量上来后系统在高并发下响应变慢、连接不稳定体验大打折扣。为了解决这个问题我们基于SpringBoot对系统架构进行了一次深度优化最终实现了单机每秒5000消息的稳定吞吐。今天就把这次实战中的架构设计、核心代码和踩过的“坑”梳理成笔记分享给大家希望能为有类似需求的同学提供一些可复用的思路。1. 业务场景与技术挑战智能客服系统看似是简单的“一问一答”但在高并发场景下背后隐藏着不少技术难点。典型的场景是成百上千的用户同时在线咨询每个用户的对话都需要保持状态消息需要实时、有序、不丢失地推送到客服端和用户端。会话状态保持传统的HTTP无状态特性在这里成了短板。我们需要一种能维持长时间双向通信的机制来跟踪每个用户的对话上下文和连接状态。消息的实时性与可靠性客服的回复需要瞬间触达用户用户的消息也要即时被客服看到。同时网络抖动或客户端异常时要保证消息不丢失、不重复幂等性。高并发连接管理当在线用户数暴涨时如何高效地管理数以万计的并发连接避免服务器资源如线程、内存被耗尽是系统稳定性的核心挑战。面对这些挑战我们放弃了传统的HTTP短轮询Polling或长轮询Comet方案因为它们会产生大量无效请求延迟高且服务器压力大。最终我们选择了WebSocket协议作为通信基石。2. WebSocket vs HTTP轮询性能数据说话为了量化差异我们在测试环境4核8G CentOS服务器JDK 8下使用JMeter对两种方案进行了压测。模拟的场景是每秒钟有大量用户发送一条消息并等待回复。传统HTTP轮询间隔1秒实现方式客户端每隔1秒向服务器发送一个HTTP GET请求询问是否有新消息。测试结果在QPS每秒查询率达到约800时服务器CPU使用率已超过80%平均响应时间显著上升大量请求实际上是在“空转”询问无新消息的状态。WebSocket长连接实现方式建立一次连接后双方可以随时主动发送消息无需频繁握手。测试结果在同样的硬件环境下系统能够轻松支撑5000的TPS每秒事务数这里指消息收发连接稳定资源占用尤其是CPU远低于轮询方式。示意图左图为高频HTTP轮询下的CPU和网络IO波动剧烈右图为WebSocket长连接下资源使用平稳吞吐量更高数据对比清晰地表明对于智能客服这类强实时、高交互的应用WebSocket在性能和服务器资源利用率上具有压倒性优势。3. 核心架构与实现代码3.1 WebSocket服务端配置首先在SpringBoot项目中启用并配置WebSocket支持。我们使用Spring提供的WebSocketHandler来处理消息。import org.springframework.context.annotation.Configuration; import org.springframework.web.socket.config.annotation.EnableWebSocket; import org.springframework.web.socket.config.annotation.WebSocketConfigurer; import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry; Configuration EnableWebSocket // 关键注解启用WebSocket支持 public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { // 注册自定义的WebSocket处理器并指定连接路径 // setAllowedOrigins(*) 在生产环境中应替换为具体域名见安全章节 registry.addHandler(myChatHandler(), /ws/chat) .setAllowedOrigins(*); } Bean public WebSocketHandler myChatHandler() { return new CustomWebSocketHandler(); } }3.2 基于Redis的分布式会话管理在集群部署中用户的WebSocket连接可能落在不同的服务器节点上。因此会话状态必须集中存储。我们使用Redis的Hash结构来存储会话信息并设置TTL实现自动过期清理。import org.springframework.data.redis.core.HashOperations; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.stereotype.Component; import javax.annotation.Resource; import java.util.concurrent.TimeUnit; Component public class SessionManager { Resource private RedisTemplateString, Object redisTemplate; private static final String SESSION_KEY_PREFIX chat:session:; /** * 保存用户会话信息 * param userId 用户ID * param sessionId WebSocket会话ID * param serverId 当前服务器节点ID */ public void saveSession(String userId, String sessionId, String serverId) { String key SESSION_KEY_PREFIX userId; HashOperationsString, Object, Object ops redisTemplate.opsForHash(); ops.put(key, sessionId, sessionId); ops.put(key, serverId, serverId); ops.put(key, activeTime, System.currentTimeMillis()); // 设置key的过期时间例如30分钟无活动则自动清除 redisTemplate.expire(key, 30, TimeUnit.MINUTES); } /** * 获取用户所在的服务器节点ID * param userId 用户ID * return 服务器节点ID如果不存在返回null */ public String getServerIdByUser(String userId) { String key SESSION_KEY_PREFIX userId; return (String) redisTemplate.opsForHash().get(key, serverId); } /** * 更新会话活跃时间防止过期 * param userId 用户ID */ public void refreshSession(String userId) { String key SESSION_KEY_PREFIX userId; if (redisTemplate.hasKey(key)) { redisTemplate.opsForHash().put(key, activeTime, System.currentTimeMillis()); redisTemplate.expire(key, 30, TimeUnit.MINUTES); // 续期 } } }3.3 异步消息处理与线程池优化消息的持久化、推送历史记录等操作不应阻塞WebSocket消息线程。我们使用Spring的Async进行异步化并自定义线程池以避免默认线程池的潜在问题。import org.springframework.scheduling.annotation.Async; import org.springframework.scheduling.annotation.EnableAsync; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor; import java.util.concurrent.Executor; Configuration EnableAsync public class AsyncConfig { /** * 自定义异步消息处理线程池 */ Bean(name messageTaskExecutor) public Executor messageTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心线程数CPU核心数 1 executor.setCorePoolSize(Runtime.getRuntime().availableProcessors() 1); // 最大线程数根据业务负载调整此处设为核心线程数的2倍 executor.setMaxPoolSize(executor.getCorePoolSize() * 2); // 队列容量不宜过大避免内存溢出和长延迟 executor.setQueueCapacity(500); // 线程名前缀 executor.setThreadNamePrefix(async-message-); // 拒绝策略由调用者线程直接执行重要避免任务丢失 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); // 核心线程允许超时关闭 executor.setAllowCoreThreadTimeOut(true); // 线程空闲存活时间秒 executor.setKeepAliveSeconds(60); executor.initialize(); return executor; } } // 使用自定义线程池执行异步任务 Service public class MessageService { Async(messageTaskExecutor) // 指定使用上面的线程池 public void handleMessageAsync(ChatMessage message) { // 1. 消息内容过滤见安全章节 // 2. 消息持久化到数据库 // 3. 查询客服状态并尝试分配 // 4. 记录日志等耗时操作 // 此方法不会阻塞WebSocket主线程 } }4. 安全加固策略4.1 WebSocket Origin 校验在生产环境中必须校验连接来源防止跨站WebSocket劫持攻击。我们可以在WebSocketConfig中细化配置也可以在HandshakeInterceptor中实现。import org.springframework.http.server.ServerHttpRequest; import org.springframework.http.server.ServerHttpResponse; import org.springframework.web.socket.server.support.DefaultHandshakeHandler; import org.springframework.web.socket.WebSocketHandler; import java.util.List; public class CustomHandshakeHandler extends DefaultHandshakeHandler { Override protected boolean isOriginValid(ServerHttpRequest request) { // 获取请求头中的Origin ListString originHeaders request.getHeaders().get(Origin); if (originHeaders null || originHeaders.isEmpty()) { return false; // 无Origin头拒绝连接 } String origin originHeaders.get(0); // 允许的域名列表应从配置文件中读取 ListString allowedOrigins Arrays.asList(https://yourdomain.com, https://www.yourdomain.com); // 简单校验检查Origin是否在允许列表中 return allowedOrigins.contains(origin); } } // 然后在WebSocketConfig中替换掉setAllowedOrigins(*)使用此HandshakeHandler4.2 消息内容XSS过滤用户输入的消息必须进行过滤防止注入恶意脚本。我们可以在消息处理逻辑的最前端加入一个简单的过滤层。import java.util.regex.Pattern; public class XssFilterUtil { // 定义常见的XSS脚本模式可根据需要扩充 private static final Pattern[] XSS_PATTERNS { Pattern.compile(script(.*?)/script, Pattern.CASE_INSENSITIVE), Pattern.compile(src[\r\n]*[\r\n]*(.*?), Pattern.CASE_INSENSITIVE | Pattern.MULTILINE | Pattern.DOTALL), Pattern.compile(/script, Pattern.CASE_INSENSITIVE), Pattern.compile(script(.*?), Pattern.CASE_INSENSITIVE | Pattern.MULTILINE | Pattern.DOTALL), Pattern.compile(eval\\((.*?)\\), Pattern.CASE_INSENSITIVE | Pattern.MULTILINE | Pattern.DOTALL), Pattern.compile(expression\\((.*?)\\), Pattern.CASE_INSENSITIVE | Pattern.MULTILINE | Pattern.DOTALL), Pattern.compile(javascript:, Pattern.CASE_INSENSITIVE), Pattern.compile(vbscript:, Pattern.CASE_INSENSITIVE), Pattern.compile(onload(.*?), Pattern.CASE_INSENSITIVE | Pattern.MULTILINE | Pattern.DOTALL) }; /** * 简单的XSS过滤将匹配到的危险内容替换为空字符串 * param value 待过滤的字符串 * return 过滤后的安全字符串 */ public static String stripXss(String value) { if (value null || value.isEmpty()) { return value; } String cleanValue value; for (Pattern pattern : XSS_PATTERNS) { cleanValue pattern.matcher(cleanValue).replaceAll(); } // 额外处理转义HTML特殊字符如果前端需要显示原始文本 // cleanValue StringEscapeUtils.escapeHtml4(cleanValue); // 使用commons-text库 return cleanValue; } } // 在MessageService.handleMessageAsync中调用 // String safeContent XssFilterUtil.stripXss(rawMessage.getContent());5. 生产环境常见问题与解决方案优化上线后平稳运行了一段时间但也遇到了一些典型问题这里总结三个最有代表性的WebSocket连接泄漏内存溢出现象服务器内存持续增长最终OOM。分析堆转储发现大量WebSocketSession对象未被释放。原因客户端如浏览器页面关闭时未发送正确的关闭帧或者网络异常导致连接非正常断开服务端未能正确触发afterConnectionClosed方法。解决实现心跳机制Ping/Pong。在服务端定期向客户端发送Ping消息如果多次未收到Pong响应则主动关闭并清理该会话。同时在WebSocketHandler中重写handleTransportError方法确保在任何传输错误时都尝试关闭和清理会话。集群部署下的会话同步难题现象用户A连接到服务器节点1其信息保存在节点1内存中。当负载均衡将用户A的下一个请求分发到节点2时节点2无法识别该用户。原因会话状态存储在单机内存中。解决这就是我们引入Redis存储会话状态的原因见3.2节。所有节点都从Redis读写会话信息实现了状态的共享。此外当需要向特定用户推送消息时可以先从Redis查出该用户所在的serverId然后通过集群消息中间件如Redis Pub/Sub、RocketMQ将消息精准路由到对应服务器节点再由该节点通过本地WebSocketSession发送。突发流量导致线程池队列积压现象在促销活动期间消息量激增异步处理任务大量堆积在线程池队列中导致消息处理延迟从毫秒级变为分钟级。原因线程池配置不够弹性queueCapacity设置过大MaxPoolSize不够高且拒绝策略不当。解决我们优化了线程池配置如3.3节所示。核心是设置合理的队列容量作为缓冲调高最大线程数以应对突发流量并采用CallerRunsPolicy拒绝策略。当队列满且线程数达到最大时该策略会让调用者线程这里是WebSocket IO线程自己执行任务。这虽然会轻微影响新消息的接收速度但保证了已有任务绝不会被丢弃是一种“优雅降级”。同时必须配合监控观察线程池活跃度、队列大小等指标作为后续扩容或进一步优化的依据。示意图优化后的系统监控显示连接数、消息吞吐量、线程池状态等指标均处于健康水平经过这一系列的架构设计、代码实现和安全加固我们的智能客服系统终于能够从容应对高并发场景。这次实战让我深刻体会到对于实时系统选择合适的协议WebSocket是基础而良好的架构设计如状态外置、异步化、合理的资源配置线程池以及全面的安全考虑才是系统稳定、高效运行的真正保障。希望这篇笔记中的思路和代码片段能对你有所帮助。