Tokio: runtime bất đồng bộ cho Rust

Tokio là gì?

Tokio là một thư viện Rust cung cấp runtime bất đồng bộ cho các ứng dụng nặng về I/O và mạng. Nó gồm một scheduler đa luồng theo cơ chế work-stealing, một reactor dựng trên hàng đợi sự kiện của hệ điều hành (epoll, kqueue, hoặc IOCP), và các kiểu socket TCP/UDP bất đồng bộ, giúp code `async fn` chạy mà không chặn luồng OS. Một chương trình khởi động runtime bằng macro `#[tokio::main]` và giao việc qua `tokio::spawn`.

Các thành phần và tính năng cốt lõi

• ✓Scheduler đa luồng theo cơ chế work-stealing, tự động phân chia các task đã spawn ra nhiều luồng OS
• ✓Reactor dựng trực tiếp trên hàng đợi sự kiện của hệ điều hành — epoll, kqueue, hoặc IOCP tùy nền tảng
• ✓Các kiểu socket TCP và UDP bất đồng bộ trong `tokio::net`, cùng timer cho việc trễ và tick theo chu kỳ
• ✓Macro `#[tokio::main]` và `#[tokio::test]` tự động kết nối runtime quanh code `async fn` thông thường
• ✓Hệ thống feature flag để Cargo.toml chỉ kéo vào phần cần dùng, hoặc dùng `features = ["full"]` để lấy tất cả cùng lúc
• ✓Dự án Tokio còn duy trì các crate đồng hành — axum, hyper, tonic, tower, tracing, mio, bytes, loom — phủ HTTP, gRPC, tracing, và kiểm thử concurrency, theo danh sách Related Projects trong README

Bạn có thể xây dựng gì với Tokio

• •Server và proxy TCP/UDP cần giữ mở hàng nghìn kết nối cùng lúc
• •Dịch vụ HTTP và gRPC xây trên các crate đồng hành axum, tonic, hoặc hyper
• •Công cụ CLI và worker chạy nền, kết hợp gọi mạng, timer, và I/O file mà không chặn một luồng cho mỗi request
• •Bất kỳ binary Rust nào có workload giống ví dụ `mini-redis` mà README trỏ tới — xử lý request/response đồng thời

Thêm Tokio vào dự án Rust

Thêm `tokio = { version = "1.53.1", features = ["full"] }` vào mục `[dependencies]` trong Cargo.toml — đúng theo snippet mà README đưa ra trong ví dụ của họ. Feature flag `full` bật toàn bộ các phân hệ của Tokio (networking, timer, I/O, sync, macro) cùng lúc; docs.rs liệt kê từng flag riêng nếu build gọn hơn quan trọng hơn sự tiện lợi.

Viết code async với Tokio

Ví dụ trong README là một TCP echo server: bind một `TcpListener` bằng `.await`, lặp trên `.accept().await`, rồi giao mỗi kết nối cho `tokio::spawn(async move { ... })` để nó chạy như một task riêng. Bên trong task đó, `AsyncReadExt`/`AsyncWriteExt` cung cấp các hàm `.read()` và `.write_all()` có thể await thay vì chặn luồng. Toàn bộ nằm dưới điểm vào `#[tokio::main] async fn main()`, chính là thứ khởi động runtime. Đó là toàn bộ pattern.

Các lựa chọn thay thế Tokio cho Rust

Câu hỏi thường gặp

Vấn đề mà nó giải quyết

Standard library của Rust chỉ có I/O chặn — một lệnh gọi `std::net::TcpListener` giữ một luồng OS đứng chờ tới khi có dữ liệu, nên một server muốn giữ mở hàng nghìn kết nối buộc phải tốn một luồng cho mỗi kết nối hoặc tự viết event loop riêng. Tokio tồn tại để code ở tầng source vẫn giữ được mô hình "một task cho mỗi kết nối", trong khi các luồng bên dưới thực sự được chia sẻ và work-stealing qua lại. Không có gì ép buộc điều đó theo mặc định.

Ai nên thử — và ai nên bỏ qua

Dùng Tokio khi một dự án Rust thực sự xử lý I/O mạng hoặc file đồng thời — một server xử lý nhiều kết nối, một proxy, một client RPC — vì đó chính là trường hợp mà scheduler và reactor của nó được thiết kế cho. Bỏ qua nó nếu đó chỉ là một script hay CLI tool chạy tuần tự các lệnh gọi chặn; thêm một runtime bất đồng bộ vào đó chỉ là thêm thủ tục (pinning, `.await` khắp nơi, một wrapper `#[tokio::main]`) cho một chương trình chẳng được lợi gì từ tính đồng thời.

Repo liên quan