使用 Rust 构建高性能 WebSocket 服务:Tokio + Axum 实战

Building High-Performance WebSocket Services with Rust: Tokio + Axum in Practice

| Wang Lei | 2026-08-08T10:30:00

分享使用 Rust Tokio + Axum 框架构建支持百万连接的 WebSocket 服务的完整经验,包含架构设计和性能调优。

Sharing complete experience building WebSocket services supporting millions of connections using Rust Tokio + Axum, including architecture design and performance tuning.

技术选型在为 iDev 实时消息推送系统选型时,我们对比了多个方案:Node.js (ws)、Go (gorilla/websocket)、Rust (tokio-tungstenite)。最终选择 Rust 方案,原因是其内存效率和尾延迟表现最优。架构设计// 核心连接管理 use axum::extract::ws::{WebSocket, WebSocketUpgrade}; use dashmap::DashMap; use tokio::sync::broadcast; struct AppState { connections: DashMap<UserId, Vec<ConnSender>>, broadcast: broadcast::Sender<Message>, } async fn ws_handler( ws: WebSocketUpgrade, State(state): State<Arc<AppState>>, ) -> impl IntoResponse { ws.on_upgrade(|socket| handle_connection(socket, state)) }性能调优要点使用 DashMap 替代 Mutex<HashMap> 降低锁争用消息广播使用 tokio::broadcast 而非逐连接发送配置 SO_REUSEPORT 实现多核负载均衡使用 jemalloc 替代系统分配器减少内存碎片压测结果单机(32核64GB)稳定支撑 120 万并发连接,消息广播延迟 P99


Technology SelectionWhen selecting technology for iDev's real-time message push system, we compared multiple solutions: Node.js (ws), Go (gorilla/websocket), and Rust (tokio-tungstenite). We chose Rust for its superior memory efficiency and tail latency performance.Architecture Design// Core connection management use axum::extract::ws::{WebSocket, WebSocketUpgrade}; use dashmap::DashMap; use tokio::sync::broadcast; struct AppState { connections: DashMap<UserId, Vec<ConnSender>>, broadcast: broadcast::Sender<Message>, } async fn ws_handler( ws: WebSocketUpgrade, State(state): State<Arc<AppState>>, ) -> impl IntoResponse { ws.on_upgrade(|socket| handle_connection(socket, state)) }Performance Tuning PointsUse DashMap instead of Mutex<HashMap> to reduce lock contentionUse tokio::broadcast for message broadcasting instead of per-connection sendingConfigure SO_REUSEPORT for multi-core load balancingUse jemalloc instead of system allocator to reduce memory fragmentationBenchmark ResultsSingle machine (32 cores, 64GB) stably supports 1.2 million concurrent connections, message broadcast P99 latency

← Back to News