⚙️ Tokio是Rust异步编程的核心运行时，它构建于Rust的异步基础之上，负责任务的调度与执行。

🏗️ Tokio的架构由Runtime、Scheduler、Driver和Worker组成，其中Scheduler是核心，负责任务的管理和调度。

🔄 Worker线程通过循环从任务队列中获取任务并执行，Driver则负责I/O事件的监听和触发，从而驱动异步任务的进展。

🚦 Tokio的任务调度机制包括全局队列、本地队列、LIFO slot和任务窃取，以实现负载均衡和提高效率。

🆚 与Nginx相比，Tokio更适合处理复杂场景，而Nginx则在高并发的简单请求方面表现更优。

蓝堇 2025-06-11 08:31 浙江

Tokio可以说是rust中最热门的库，对于异步与并发进行了很好的支持。大多数基于rust的开源框架都使用到了Tokio，因此在介绍这些实现开源框架时经常会被问到：底层的异步和并发是怎么实现的？我只能回答：底层的异步和并发都是由Tokio控制的。这显然不是一个令人满意的回答。因此本文章将对于Tokio的基本方法和底层逻辑进行分析。

一句话概括

更具体一点，Tokio 可以类比为一个“异步操作系统”：

Tokio 的优势主要体现在以下方面：

高效

通过内部的优化机制（调度算法、无锁队列与内存池管理等）与 rust 的语言优势，Tokio 效率较高，在早期的实验中，官方给出了性能对比图：

通用

在 rust 发展之初，社区出现了很多运行时库，但是，大浪淘沙，随着时间的流逝，Tokio 越来越亮眼，无论是性能、功能还是社区、文档，它在各个方面都异常优秀，时至今日，可以说已成为事实上的标准。新出现的rust运行时库（例如 Bytedace 的 monoio）宣传性能优于 Tokio，但还是雷声大雨点小，没有被广泛应用。

Tokio 的身影遍布在各种类型的 rust 库中，例如HTTP库（Hyper）、Web框架（Axum / Warp）、gRPC（Tonic）、TLS库（Rustls）、数据库支持（SeaORM）等。同时各大厂商也广泛使用，例如AWS、Azure、Google等。

Tokio 更加适合频繁切换的场景，例如网络服务、微服务、代理、数据库连接池、实时通信系统等。而不适合并行计算或密集计算等场景。

因此，如果需要使用 rust 中的高性能异步并发，且对于 Tokio 内部工作原理不敏感，看到这里放心使用就好了。后文将从rust语言的异步来着手，分析Tokio的架构以及具体调度的生命周期，最后分析与Nginx的对比以未来的一些方向。

对 Future/async/await 非常熟悉可以跳过。

Golang/Nodejs等语言的异步内置于语言本身，做了很好的封装且开箱即用，虽然能够简化使用但不灵活无法更改。rust作为系统级语言，并不想把异步的具体实现单一化与局限化，因此在rust std中只实现了异步的基本功能与框架（例如 Future/async/await 等），而把异步调度进行了开放，由第三方库来具体实现。

Future

Future 是 Rust 异步编程的核心抽象，它是一个状态机，通过多次 poll 推进其状态，直到完成。它与 Waker、Runtime、I/O 驱动紧密配合，构成了整个非阻塞异步系统的基础。

Future 其实就是一个trait，定义如下：

pub trait Future {
    type Output;

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

Future 与 任务（task）的区别： Future 是 rust 原生支持的异步 trait，许多第三方异步库在此基础上将 Future 封装为 task 用来完成调度。

async

通常不会用上述的trait来创建 Future，而是结合使用 async，编译器会将被 async 修饰的函数或代码块转化为 Future。也就是说调用 async fn 的具体函数并不会立刻执行，而只是创建 Future 等待 poll 来推动状态机。

// async fn
async fn fetch_data() -> Result<String, Error> {
    let resp = reqwest::get("https://example.com").await?;
    Ok(resp.text().await?)
}

// async 代码块
let future = async {
    // 异步逻辑
    let data = expensive_computation().await;
    format!("Result: {}", data)
};

上述 Future trait中，poll 是核心方法，用于推进状态机的进行。我们的代码不会直接调用 poll，而是通过 Rust 的关键字 .await 来执行这个 Future，await 会被 rust 在编译时生成代码来调用 poll，返回 Poll（见下），如果是 Pending 则被 runtime 挂起（比如重新放到任务队列中）。当有 event 产生时，挂起的 future 会被唤醒，Rust 会再次调用 future 的 poll，如果此时返回 Ready 就执行完成。

pub enumPoll<T> {
    Ready(T),
    Pending,
}

多级 Future 嵌套时，只有遇到类似 .await 才会推动执行，是协同式调度而不是抢占式调度（Tokio 1.x版本引入抢占机制来缓解饥饿问题，但rust原生基础是协同式调度）。因此 rust 无需提前为 Future 分配独立的栈或堆上内存，是一种零成本抽象。

总结

如下图所示，rust std 中的异步只维护 Future 以及内部方法 poll，具体的任务队列和调度方法由第三方的 runtime 来实现。每次代码执行到 .await 时会进行一次poll，poll 若 ready 则直接退出表示执行完成，poll 若遇到阻塞，则挂起等待事件池来唤醒。当有事件（例如I/O等）唤醒之后，会把该挂起 Future 封装为 task，加入到任务队列中等待调度，runtime 会不断地从任务队列中拿出任务来执行。

架构

承接上文，这一部分主要介绍 Tokio 实现的 runtime架构，如下图所示：

Tokio 会启动很多 Worker，每个 Worker 对应一个线程，并发完成异步任务。Worker 内部又主要包括 任务队列 和 Driver引用。

Driver 是异步运行时中的“驱动引擎”，它通过操作系统提供的 I/O 多路复用机制（如 Linux 上的 
epoll
、Windows 上的 
IOCP
、macOS 上的 
kqueue
）来监听 I/O 事件和定时器事件，并在事件就绪后唤醒对应的 Future 继续执行。Tokio 中的 Driver 又分为I/O和Time，I/O负责监听socket和文件读写，Time负责sleep等定时任务。

Tokio 将 Future 封装为任务，其中主要包含了waker，waker挂载到 Driver 中，当 Driver 有新事件时会回调 waker 来停止阻塞，并加入到任务队列中。

任务会加入到任务队列中，任务队列又分为每个 Worker 内部的，以及全局的队列。通常在 Worker 创建的任务即加入到内部队列，全局创造的加入到全局队列，全局队列的任务会被任何 Worker 线程执行到。

构造（build）

Tokio 中的 Runtime 结构体如下：

pub structRuntime {
    /// Task scheduler
    scheduler: Scheduler,

    /// Handle to runtime, also contains driver handles
    handle: Handle,

    /// Blocking pool handle, used to signal shutdown
    blocking_pool: BlockingPool,
}

其中 BlockingPool 是专门用来运行阻塞任务的线程池，上述解释已简单概括；Handle 维护了过程中各种handler，本文不重点关注这两项。Scheduler 是“任务池”和“调度器”的封装，也是 Runtime 最核心的部分。

想要使用 Runtime 必须要经过初始化：

tokio::runtime::Builder::new_multi_thread()
                .enable_all().worker_threads(threads).thread_name(name)
                .build().unwrap(),

build() 即构造了 Runtime 结构，其中最重要的是 Driver 和 Worker 。

Driver 构造的过程

Driver 封装了 I/O 和 Timer 的驱动，并加入了部分机制（例如内存slab），下面以I/O Driver为例，详细说明：

pub(crate) fn new(nevents: usize) -> io::Result<(Driver, Handle)> {
    let poll = mio::Poll::new()?;
    #[cfg(not(target_os = "wasi"))]
    let waker = mio::Waker::new(poll.registry(), TOKEN_WAKEUP)?;
    let registry = poll.registry().try_clone()?;

    let driver = Driver {
        signal_ready: false,
        events: mio::Events::with_capacity(nevents),
        poll,
    };

    let (registrations, synced) = RegistrationSet::new();

    let handle = Handle {
        registry,
        registrations,
        synced: Mutex::new(synced),
        #[cfg(not(target_os = "wasi"))]
        waker,
        metrics: IoDriverMetrics::default(),
    };

    Ok((driver, handle))
}

初始化mio的poll，底层就是 epoll/kqueue 对象。

初始化waker，其是向poll注册一个特殊的事件 

TOKEN_WAKEUP

初始化driver后同时创建hadle，可以被线程共享，用于传入worker中。

worker构造的过程

pub(super) fn create(
    size: usize,
    park: Parker,
    driver_handle: driver::Handle,
    blocking_spawner: blocking::Spawner,
    seed_generator: RngSeedGenerator,
    config: Config,
) -> (Arc<Handle>, Launch) {
    let mut cores = Vec::with_capacity(size);
    let mut remotes = Vec::with_capacity(size);
    let mut worker_metrics = Vec::with_capacity(size);

    // Create the local queues
    for _ in 0..size {
        let (steal, run_queue) = queue::local();

        let park = park.clone();
        let unpark = park.unpark();
        let metrics = WorkerMetrics::from_config(&config);
        let stats = Stats::new(&metrics);

        cores.push(Box::new(Core {
            tick: 0,
            lifo_slot: None,
            lifo_enabled: !config.disable_lifo_slot,
            run_queue,
            is_searching: false,
            is_shutdown: false,
            is_traced: false,
            park: Some(park),
            global_queue_interval: stats.tuned_global_queue_interval(&config),
            stats,
            rand: FastRand::from_seed(config.seed_generator.next_seed()),
        }));

        remotes.push(Remote { steal, unpark });
        worker_metrics.push(metrics);
    }

    let (idle, idle_synced) = Idle::new(size);
    let (inject, inject_synced) = inject::Shared::new();

    let remotes_len = remotes.len();
    let handle = Arc::new(Handle {
        task_hooks: TaskHooks::from_config(&config),
        shared: Shared {
            remotes: remotes.into_boxed_slice(),
            inject,
            idle,
            owned: OwnedTasks::new(size),
            synced: Mutex::new(Synced {
                idle: idle_synced,
                inject: inject_synced,
            }),
            shutdown_cores: Mutex::new(vec![]),
            trace_status: TraceStatus::new(remotes_len),
            config,
            scheduler_metrics: SchedulerMetrics::new(),
            worker_metrics: worker_metrics.into_boxed_slice(),
            _counters: Counters,
        },
        driver: driver_handle,
        blocking_spawner,
        seed_generator,
    });

    let mut launch = Launch(vec![]);

    for (index, core) in cores.drain(..).enumerate() {
        launch.0.push(Arc::new(Worker {
            handle: handle.clone(),
            index,
            core: AtomicCell::new(Some(core)),
        }));
    }

    (handle, launch)
}

为 Tokio 多线程运行时创建一组 Worker 线程，每个 Worker 都绑定了一个本地任务队列（Local Queue）、I/O 和定时器驱动（Driver），并准备好参与异步任务调度。其中：

创建本地任务队列和任务窃取队列。本地任务队列是一个无锁双端队列，可以用于其他线程的窃取，有关任务窃取在后文详细介绍。

也创建了Handle，该Handle可以用来提交新任务、同步执行 Future和提交阻塞任务等。

（隐式）通过参数传入 Driver，在线程中即可以通过 Driver 和 Driver Handle 完成 Wake 挂载、I/O事件、推进定时器等。

每个Worker 会被传入到 Launch，启动调度循环（无限循环从队列中拿出任务poll）。

构造出基本的 runtime 架构后，就等待有任务被加入到 runtime 中被调度与执行，这一部分详细说明任务从被构造到执行完成的流程。

如上图所示，Worker 在创建后执行调度循环，不断地从任务队列中取任务，执行poll，若结果为阻塞则注册waker并挂起，之后取新任务poll。当 Driver 有新事件时会调用 waker 来唤醒任务，重新加入到任务队列中待新一轮调用。

任务队列

全局队列（global queue） 有且仅有一个，全局队列是必要的，因为有些任务不属于某个worker，只能加到全局队列中。全局队列是FIFO的设计架构。

只有全局队列就会面临所有 worker都从全局队列拿任务，需要加锁影响性能。因此每个worker一个维护本地队列（local run queue），在worker内产生的任务会直接加到自己的本地队列中。

本地队列也是FIFO的，保证了公平性，但是不同任务之间的资源会被割裂，调度会浪费CPU缓存，因此又多增了LIFO slot。LIFO slot可以理解为本地队列中的“特权”任务，例如某些任务spawn出新的任务，且该新任务对旧任务有大量的资源依赖，此时可以将新任务加入到LIFO slot中；或者某些任务通过信号通知其他任务可以被执行，此时该任务可以被加入到LIFO slot中，避免排队带来的延迟。由于LIFO slot会带来不公平的问题，因此只有一个槽位，被占就只能到本地队列的末尾排队。

任务窃取：当本地和全局队列中都没有要执行的任务时（此时该worker已经空闲），会尝试窃取其他worker的本地队列的任务。这一机制保障了线程的负载均衡，同时提高系统整体的运行效率。窃取时会从末端开始，因此不会干扰worker的正常进行，该队列也无需加锁。

最终，任务队列的执行顺序是：本地LIFO slot --->> 本地任务队列 --->> 全局任务队列 --->> 窃取其他线程的任务。

任务饥饿问题

饥饿问题有以下两种场景：

1.某任务是密集计算型任务，不断占据cpu而不释放；

2.本地任务更新太快太频繁，全局任务无法被执行到；

第一种场景，Tokio 从 1.x开始，引入了抢占式调度来缓解饿死问题，简单来说就是会定期强制任务挂起来让出资源。但是需要说明的是，这种场景本质上和rust的异步并发冲突，更加推荐使用tokio::task::spawn_blocking，来将任务转化为并行计算任务。

第二种场景经常会遇到，本质上是由于三种不同的队列有优先级，可能会导致低优先级的队列被饿死。例如I/O频繁的TCP连接会不断地加入到本地队列，而无法处理全局队列任务。Tokio 的解决的方法是为每个任务加入循环次数，当其循环加入队列次数超过一定上限后会先搁置，优先处理低优先级（例如全局队列）的任务。

总之，Tokio 设计了相关的机制来平衡公平性和效率，同时还有一些其他算法或异步runtime优化了部分过程，取得了更好的效果（例如horaedb（Apache、Ant）、Monoio（bytedance））。虽然并非完美，但是各方都在努力完善公平性和性能，这或许就是rust设计开放runtime的初衷。

Nginx采用 多worker进程单线程 + 非阻塞I/O + 事件驱动 的模型。

多进程单线程：最开始时，Nginx会创建多个worker进程，每个进程创建后即可以视为是完全独立的存在，后续的任务执行和资源占用互不干预。所有的worker进程会统一绑定监听某个或某些端口，当某端口有数据时，操作系统会分配给某个worker。（分配方法又分为 SO_REUSEPORT 和 accept_mutex机制，这里的详细机制后续会出一篇文章来详细说明，简单来说就是 SO_REUSEPORT 减少了惊群效应，去除了锁，提高了CPU负载均衡，但是会增加时延不均衡性）。

事件驱动：当某个worker 接收到数据后，会将其注册到epoll事件中，并在相应的阶段调用相应的回调函数，主进程（即线程）会轮询执行这些事件回调。主进程是串行执行，无抢占式调度和锁的开销。

非阻塞I/O：系统采用非阻塞I/O与多路复用机制（即epoll）来完成高并发处理。

两者的对比如下：

在性能方面：Nginx更有利于处理高并发 但是 简单或静态请求，独立进程+事件驱动可以轻松处理高并发，但是进程间隔离不利于复杂处理；Tokio更有利于处理复杂场景，且开发灵活，能够支持许多新协议开发。

在开发方面：Nginx基于回调函数开发，同一过程可能需要拆成多个同步函数，面向状态编程较为混乱容易遗忘细节，门槛较高；而Tokio可以基于过程开发，开发逻辑简单，门槛较低。

绑核问题

Tokio本身并不支持绑CPU核，要实现绑核有以下三种方法：

直接给进程绑核。不同于Nginx的多进程程序，Tokio本身是单进程多线程程序，因此可以直接在系统层面给进程绑核。

taskset -c [CPU NUMBER] -p PID

Docker绑核。类似于上述方法，若Tokio运行于docker上可以直接docker绑核。

docker run --cpuset-cpus [CPU NUMBER]

core_affinity_rs 第三方rust库。该库支持线程级别设置cpu核，可以在创建tokio::runtime时进行绑核设置

runtime::Builder::new_multi_thread()
.on_thread_start(move || {
    core_affinity::set_for_current(core_id.clone());
})

IO Uring

当前Tokio官方还没有全面支持 io_uring，但是在社区中已经出现了不少支持：例如tokio-uring，其基本思想是在IO Driver中的mio 进行封装，注册在 Tokio(mio) 上一个 uring fd，而基于这个 fd 和一套自己的 Pending Op 管理系统又对外作为 Reactor 暴露了事件源的能力。

扩展协议栈

日志与调试支持

Tokio 正在推动对测试工具的支持，例如：提供 mock I/O 接口；支持 determinism 测试；提供 tracing、instrumentation 集成，便于调试异步程序。相关的社区实践包括 tokio-tesing等。

内部调度算法更新

前文也说过，内部的调度算法决定了不同场景下的效果，当前已经有许多 runtime库提出了新的算法来优化某些过程，Tokio 也在积极探索和演进。

不同平台、形式支持

Tokio 也在积极探索在不同平台的支持，例如嵌入式平台。同时也在开发WASM支持，可以在WASM中运行Tokio。

声明：Tokio更新频繁，本文主要针对1.44.1版本分析。

后续我们也会基于 Qwen3 实验哪种方法在复杂任务的工具调用效果最好，敬请期待。

Tokio源码：https://github.com/tokio-rs/tokio

Tokio官方文档：https://tokio.rs/tokio/tutorial

字节monoio：https://rustmagazine.github.io/rust_magazine_2021/chapter_12/monoio.html

apache-haoraedb：https://github.com/apache/horaedb

https://tony612.github.io/tokio-internals/01_intro_async.html

https://tidb.net/blog/18804515

阅读原文

跳转微信打开