Rust学习～tokio简介

对于 Async Rust，最重要的莫过于底层的异步运行时，它提供了执行器、任务调度、异步 API 等核心服务
使用 Rust 提供的 async/await 特性编写的异步代码要运行起来，就必须依赖于异步运行时

异步运行时

Rust 语言本身只提供了异步编程所需的基本特性，例如 async/await 关键字，标准库中的 Future 特征，官方提供的 futures 实用库
这些特性单独使用没有任何用处，需要一个运行时来将这些特性实现的代码运行起来

异步运行时是由 Rust 社区提供的，它们的核心是一个 reactor 和一个或多个 executor(执行器)
（1）reactor 用于提供外部事件的订阅机制，例如 I/O 、进程间通信、定时器等
（2）executor 用于调度和执行相应的任务( Future )

目前最受欢迎的几个运行时有:
（1）tokio，功能强大，还提供了异步所需的各种工具(例如 tracing )、网络协议框架(例如 HTTP，gRPC )等等
（2）async-std，最大的优点就是跟标准库兼容性较强
（3）smol, 一个小巧的异步运行时

异步运行时的兼容性

使用异步运行时，往往伴随着对它相关的生态系统的深入使用，因此耦合性会越来越强，直至最后很难切换到另一个运行时
例如 tokio 和 async-std ，就存在这种问题。
如果实在有这种需求，可以考虑使用 async-compat，该包提供了一个中间层，用于兼容 tokio 和其它运行时。

运行时之间的不兼容性，必须提前选择一个运行时，并且在未来坚持用下去
那这个运行时就应该是最优秀、最成熟的那个，tokio 几乎成了不二选择

tokio简介

读音 /ˈtəʊkiəʊ/

tokio 是 Rust 最优秀的异步运行时框架，它提供了写异步网络服务所需的几乎所有功能
不仅仅适用于大型服务器，还适用于小型嵌入式设备

主要由以下组件构成：
（1）多线程版本的异步运行时，可以运行使用 async/await 编写的代码
（2）标准库中阻塞 API 的异步版本，例如thread::sleep会阻塞当前线程，tokio中就提供了相应的异步实现版本
（3）构建异步编程所需的生态，甚至还提供了 tracing 用于日志和分布式追踪，提供 console 用于 Debug 异步编程

Rust官方提供的req/s，rust到200万qps/s了，go连30万qps/s都到不了

优点

高性能

因为快所以快，前者是 Rust 快，后者是 tokio 快。
tokio 在编写时充分利用了 Rust 提供的各种零成本抽象和高性能特性

高可靠

Rust 语言的安全可靠性顺理成章的影响了 tokio 的可靠性

曾经有一个调查给出了令人乍舌的结论：软件系统 70%的高危漏洞都是由内存不安全性导致的

在 Rust 提供的安全性之外，tokio 还致力于提供一致性的行为表现：
无论何时运行系统，它的预期表现和性能都是一致的，例如不会出现莫名其妙的请求延迟或响应时间大幅增加

简单易用

通过 Rust 提供的 async/await 特性，编写异步程序的复杂性相比当初已经大幅降低
同时 tokio 提供了丰富的生态，进一步大幅降低了其复杂性

同时 tokio 遵循了标准库的命名规则，让熟悉标准库的用户可以很快习惯于 tokio 的语法
再借助于 Rust 强大的类型系统，用户可以轻松地编写和交付正确的代码

使用灵活性

tokio 支持灵活的定制自己想要的运行时，例如可以选择多线程 + 任务盗取模式的复杂运行时，也可以选择单线程的轻量级运行时。
总之，几乎每一种需求在 tokio 中都能寻找到支持

(强大的灵活性需要一定的复杂性来换取，并不是免费的午餐)

缺点

并行运行 CPU 密集型的任务

tokio 非常适合于 IO 密集型任务，这些 IO 任务的绝大多数时间都用于阻塞等待 IO 的结果
如果应用是 CPU 密集型(例如并行计算)，建议使用 rayon，当然，对于其中的 IO 任务部分，依然可以混用 tokio

读取大量的文件

读取文件的瓶颈主要在于操作系统，因为 OS 没有提供异步文件读取接口，大量的并发并不会提升文件读取的并行性能，反而可能会造成不可忽视的性能损耗，因此建议使用线程（或线程池）的方式

发送少量 HTTP 请求

tokio 的优势是给予并发处理大量任务的能力，对于这种轻量级 HTTP 请求场景，tokio 除了增加代码复杂性，并无法带来什么额外的优势。
因此，对于这种场景，可以使用 reqwest 库，它会更加简单易用。

若使用 tokio，那 CPU 密集的任务尤其需要用线程的方式去处理
例如使用 spawn_blocking 创建一个阻塞的线程去完成相应 CPU 密集任务

原因是：
tokio 是协作式的调度器，如果某个 CPU 密集的异步任务是通过 tokio 创建的，那理论上来说，该异步任务需要跟其它的异步任务交错执行，最终大家都得到了执行，皆大欢喜。
但实际情况是，CPU 密集的任务很可能会一直霸着着 CPU，此时 tokio 的调度方式决定了该任务会一直被执行，这意味着，其它的异步任务无法得到执行的机会，最终这些任务都会因为得不到资源而饿死。

使用 spawn_blocking 后，会创建一个单独的 OS 线程，该线程并不会被 tokio 所调度( 被 OS 所调度 )
因此它所执行的 CPU 密集任务也不会导致 tokio 调度的那些异步任务被饿死