为什么需要专门的对话系统方案？

开发即时通讯功能时，传统HTTP请求暴露出三个致命问题：

• 上下文丢失：每次请求都是无状态的，需要额外维护会话ID
• 高并发乱序：快速连续发送消息时，HTTP无法保证到达顺序
• 资源浪费：频繁轮询导致70%以上的请求都是空响应

协议选型对比

| 方案 | 平均延迟 | CPU消耗 | 开发复杂度 | 适用场景 | |---------------|----------|---------|------------|-------------------| | REST轮询 | 500-2000ms | 高 | ★★☆ | 低频状态检查 | | WebSocket | 50-200ms | 中 | ★★★ | 双向实时通讯 | | gRPC流式 | 30-150ms | 低 | ★★★★ | 内部服务间通讯 |

实际测试数据：当QPS>500时，WebSocket的内存消耗只有HTTP轮询的1/3。

核心实现四步走

1. 搭建WebSocket基础框架

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(customHandler(), "/chat")
                .addInterceptors(new AuthInterceptor())
                .setAllowedOrigins("*");
    }
}

2. 实现带JWT验证的握手拦截器

public class AuthInterceptor extends HttpSessionHandshakeInterceptor {
    @Override
    public boolean beforeHandshake(/* 参数省略 */) {
        String token = request.getParameter("access_token");
        if(!JwtUtil.validate(token)) {
            throw new RuntimeException("无效凭证");
        }
        attributes.put("userId", JwtUtil.getUserId(token));
        return true;
    }
}

3. 会话管理设计

public class SessionManager {
    private static final ConcurrentHashMap<String, WebSocketSession> sessions 
        = new ConcurrentHashMap<>();

    public static void addSession(String userId, WebSocketSession session) {
        sessions.put(userId, session);
    }

    // 使用CopyOnWriteArrayList解决并发修改问题
    public static void sendToUser(String userId, TextMessage message) {
        WebSocketSession session = sessions.get(userId);
        if(session != null && session.isOpen()) {
            session.sendMessage(message);
        }
    }
}

4. 消息幂等处理

public void handleMessage(WebSocketSession session, TextMessage message) {
    ChatMsg msg = JSON.parseObject(message.getPayload(), ChatMsg.class);

    // 消息去重校验
    if(!msgIdCache.add(msg.getMsgId())) {
        log.warn("重复消息: {}", msg.getMsgId());
        return;
    }

    // 业务处理...
}

性能优化实战

容器替换对比

| 指标 | Tomcat 9 | Undertow | Netty 4.1 | |---------------|----------|----------|-----------| | 1000连接内存 | 850MB | 620MB | 410MB | | 消息延迟(P99) | 210ms | 180ms | 130ms |

改用Netty只需添加依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>

消息批处理技巧

// 合并10ms内的消息
public void onMessage(WebSocketSession session, TextMessage message) {
    buffer.add(message);
    if(System.currentTimeMillis() - lastFlush > 10) {
        flushBuffer();
    }
}

生产环境避坑清单

1. 心跳配置

   # 服务端30秒无操作断开
   spring.websocket.idle-timeout=30000 
   # 客户端每25秒发ping
   client.heartbeat.interval=25000

2. Nginx配置

   location /chat {
       proxy_pass http://backend;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       proxy_read_timeout 3600s;
   }

3. 分布式会话方案选型

4. Redis Pub/Sub：开发简单，但存在消息风暴风险
5. RocketMQ：顺序消息保障，需要处理消费延迟
6. 自研方案：基于一致性哈希的节点路由

总结建议

对于初期项目，推荐组合：Spring Boot WebSocket + Redis会话存储 + 简易心跳机制。当在线用户超过5万时，再考虑引入Netty和消息中间件。关键是要在代码中预留扩展点，比如将会话管理抽象为接口，便于后期替换实现。