1. 为什么选择Netty+WebSocket组合？
在构建实时消息推送系统时，技术选型往往决定了系统的性能天花板。我经历过用传统HTTP轮询方案被高并发打垮的惨痛教训，后来切换到Netty+WebSocket组合才真正解决了问题。这个组合就像高速公路上的ETC通道——HTTP轮询是人工收费通道，每辆车都要停车交费；而WebSocket是ETC通道，车辆可以持续通行。
Netty的三大核心优势在实际项目中表现得尤为突出：
- 线程模型优化：用4核服务器实测过，单机维持10万长连接时CPU利用率不到30%
- 零拷贝技术：在消息广播场景下，内存消耗比传统方案降低40%以上
- 灵活的Pipeline：上周刚用ChannelHandler快速实现了消息加密功能，全程只改了3个类
WebSocket协议的优势则体现在：
- 建立连接时的HTTP握手仅消耗1个RTT时间
- 消息头只有2-10字节开销，比HTTP头部小得多
- 支持双向通信，服务端可以主动推送
2. 搭建基础通信框架
2.1 初始化Netty服务端
先上干货，这是经过线上验证的启动类模板：
public class NettyServer { private final int port; private EventLoopGroup bossGroup; private EventLoopGroup workerGroup; public NettyServer(int port) { this.port = port; } public void start() throws Exception { bossGroup = new NioEventLoopGroup(1); // 注意这里设为1 workerGroup = new NioEventLoopGroup(); try { ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ChannelPipeline pipeline = ch.pipeline(); // 添加WebSocket协议支持 pipeline.addLast(new HttpServerCodec()); pipeline.addLast(new HttpObjectAggregator(65536)); pipeline.addLast(new WebSocketServerProtocolHandler("/ws")); // 自定义业务处理器 pipeline.addLast(new MessageHandler()); } }) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.SO_KEEPALIVE, true); ChannelFuture f = b.bind(port).sync(); f.channel().closeFuture().sync(); } finally { workerGroup.shutdownGracefully(); bossGroup.shutdownGracefully(); } } }几个关键配置的实践经验：
bossGroup线程数设为1足够，因为主要工作是接收连接SO_BACKLOG指定了等待连接队列长度，根据服务器配置调整- 使用
NioEventLoopGroup而非EpollEventLoopGroup保证跨平台性
2.2 处理WebSocket握手
WebSocket连接建立需要经过握手过程。遇到过的一个坑是：某些浏览器会先发OPTIONS请求做预检。解决方案是在Pipeline中添加CORS支持：
pipeline.addLast(new CorsHandler()); // 自定义跨域处理器 // CorsHandler核心代码 @Override protected void channelRead0(ChannelHandlerContext ctx, FullHttpRequest req) { if (CorsConfig.isPreflightRequest(req)) { FullHttpResponse response = new DefaultFullHttpResponse(HTTP_1_1, OK); CorsConfig.addCorsHeaders(response); ctx.writeAndFlush(response); return; } ctx.fireChannelRead(req); }3. 高并发下的优化策略
3.1 连接管理方案
当连接数突破5万时，传统HashMap会出现性能瓶颈。我们最终采用分片存储方案：
public class ConnectionManager { private static final int SHARD_SIZE = 16; private final ConcurrentMap<String, Channel>[] shards; public ConnectionManager() { shards = new ConcurrentHashMap[SHARD_SIZE]; for (int i = 0; i < SHARD_SIZE; i++) { shards[i] = new ConcurrentHashMap<>(); } } private int getShardIndex(String userId) { return Math.abs(userId.hashCode()) % SHARD_SIZE; } public void addConnection(String userId, Channel channel) { shards[getShardIndex(userId)].put(userId, channel); } }实测表明，在10万并发下，分片方案的写入性能比直接使用ConcurrentHashMap提升3倍。
3.2 消息广播优化
群发消息时最容易出现性能瓶颈。我们采用二级分发策略：
- 先按业务维度分组
- 每个组内使用独立的线程池处理
public void broadcastMessage(Message msg) { // 第一级：按业务分组 List<Group> groups = groupStrategy.route(msg); // 第二级：组内并行处理 groups.forEach(group -> { groupExecutor.execute(() -> { group.getConnections().forEach(channel -> { if (channel.isActive()) { channel.writeAndFlush(msg); } }); }); }); }4. 生产环境中的稳定性保障
4.1 心跳机制设计
遇到过最棘手的问题是网络抖动导致幽灵连接。现在的解决方案是双向心跳：
// 服务端心跳检测 pipeline.addLast(new IdleStateHandler(60, 0, 0, TimeUnit.SECONDS)); pipeline.addLast(new HeartbeatHandler()); // HeartbeatHandler部分代码 @Override protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame frame) { if ("HEARTBEAT".equals(frame.text())) { ctx.writeAndFlush(new TextWebSocketFrame("ACK")); return; } ctx.fireChannelRead(frame); }客户端每30秒发送心跳，服务端60秒未收到则主动断开。这套机制让连接保活成功率从92%提升到99.9%。
4.2 监控指标埋点
推荐监控这几个核心指标：
- 当前连接数
- 消息吞吐量
- 处理延迟分布
- 异常断开率
我们使用Micrometer+Prometheus的方案：
public class MetricsHandler extends ChannelDuplexHandler { private final Counter messageCounter; public MetricsHandler(MeterRegistry registry) { this.messageCounter = registry.counter("websocket.messages"); } @Override public void channelRead(ChannelHandlerContext ctx, Object msg) { messageCounter.increment(); ctx.fireChannelRead(msg); } }5. 典型问题排查实录
5.1 内存泄漏排查
某次上线后出现内存持续增长，用MAT工具分析发现是Channel没有正确释放。根本原因是业务代码中漏掉了异常处理：
// 错误示例 try { channel.writeAndFlush(message); } catch (Exception e) { logger.error("发送失败", e); // 缺少channel.close() } // 正确做法 try { channel.writeAndFlush(message).addListener(future -> { if (!future.isSuccess()) { channel.close(); } }); } catch (Exception e) { logger.error("发送失败", e); channel.close(); }5.2 CPU飙高问题
有次压测时CPU使用率突然飙升到90%，通过线程dump发现是日志组件同步阻塞。解决方案：
- 改用异步日志框架
- 对高频日志增加采样率
// 日志采样方案 private static final AtomicLong counter = new AtomicLong(); public void debug(String format, Object... args) { if (counter.getAndIncrement() % 100 == 0) { logger.debug(format, args); } }6. 性能压测数据参考
在4核8G的云服务器上实测数据：
| 场景 | 连接数 | 消息量 | 平均延迟 | CPU使用率 |
|---|---|---|---|---|
| 单播 | 50,000 | 2000/s | 23ms | 35% |
| 广播 | 10,000 | 500/s | 110ms | 68% |
| 峰值 | 80,000 | 5000/s | 210ms | 92% |
关键发现：
- 广播场景的性能下降明显
- 连接数超过8万时出现明显毛刺
- 消息体大小对性能影响显著（建议控制在1KB内）
7. 进阶优化方向
对于需要更高性能的场景，可以考虑：
- 协议优化：改用Protobuf二进制协议，相比JSON节省40%带宽
- 混合部署：将WebSocket服务与业务服务分离
- 智能调度：基于连接活跃度动态调整资源分配
最近在尝试的方案是将热点用户连接调度到独立线程组：
EventLoopGroup hotGroup = new NioEventLoopGroup(4); if (isHotUser(userId)) { channel = hotGroup.register(channel).sync().channel(); }这种方案在社交场景下，使核心用户的消息延迟降低了60%。
