Linux高性能服务器编程模式与Rust异步编程

落日映苍穹つ 2022-10-29 09:24 198阅读 0赞

Rust中文社区投稿,[投稿地址][Link 1],好文将在以下地方直接展示

1.  [Rust中文社区首页][Rust]
2.  Rust中文社区[Rust文章栏目][Rust 1]
3.  知乎专栏[Rust语言][Rust 2]

高性能服务器至少要满足如下几个需求：

*  效率高：既然是高性能，那处理客户端请求的效率当然要很高了
 *  高可用：不能随便就挂掉了
 *  编程简单：基于此服务器进行业务开发需要足够简单
 *  可扩展：可方便的扩展功能
 *  可伸缩：可简单的通过部署的方式进行容量的伸缩，也就是服务需要无状态

而满足如上需求的一个基础就是高性能的IO!

讲到高性能IO绕不开Reactor模式，它是大多数IO相关组件如Netty、Redis在使用的IO模式

几乎所有的网络连接都会经过读请求内容——》解码——》计算处理——》编码回复——》回复的过程

## Socket ##

Socket之间建立链接及通信的过程！实际上就是对TCP/IP连接与通信过程的抽象:

*  服务端Socket会bind到指定的端口上，Listen客户端的"插入"
 *  客户端Socket会Connect到服务端
 *  当服务端Accept到客户端连接后
 *  就可以进行发送与接收消息了
 *  通信完成后即可Close

## 阻塞IO(BIO)、非阻塞IO(NBIO)、同步IO、异步IO ##

*  一个IO操作其实分成了两个步骤：发起IO请求和实际的IO操作
 *  阻塞IO和非阻塞IO的区别在于第一步：发起IO请求是否会被阻塞，如果阻塞直到完成那么就是传统的阻塞IO;如果不阻塞，那么就是非阻塞IO
 *  同步IO和异步IO的区别就在于第二个步骤是否阻塞，如果实际的IO读写阻塞请求进程，那么就是同步IO，因此阻塞IO、非阻塞IO、IO复用、信号驱动IO都是同步IO;如果不阻塞，而是操作系统帮你做完IO操作再将结果返回给你，那么就是异步IO

BIO优点

*  模型简单
 *  编码简单

BIO缺点

*  性能瓶颈低

缺点：主要瓶颈在线程上。每个连接都会建立一个线程。虽然线程消耗比进程小，但是一台机器实际上能建立的有效线程有限，且随着线程数量的增加，CPU切换线程上下文的消耗也随之增加，在高过某个阀值后，继续增加线程，性能不增反降！而同样因为一个连接就新建一个线程，所以编码模型很简单！

就性能瓶颈这一点，就确定了BIO并不适合进行高性能服务器的开发！

NBIO:

*  Acceptor注册Selector，监听accept事件
 *  当客户端连接后，触发accept事件
 *  服务器构建对应的Channel，并在其上注册Selector，监听读写事件
 *  当发生读写事件后，进行相应的读写处理

优点

*  性能瓶颈高

缺点

*  模型复杂
 *  编码复杂
 *  需处理半包问题

NBIO的优缺点和BIO就完全相反了!性能高，不用一个连接就建一个线程，可以一个线程处理所有的连接！相应的，编码就复杂很多，从上面的代码就可以明显体会到了。还有一个问题，由于是非阻塞的，应用无法知道什么时候消息读完了，就存在了半包问题！需要自行进行处理!例如，以换行符作为判断依据，或者定长消息发生，或者自定义协议！

NBIO虽然性能高，但是编码复杂，且需要处理半包问题！为了方便的进行NIO开发，就有了Reactor模型!

## Proactor和Reactor ##

Proactor和Reactor是两种经典的多路复用I/O模型，主要用于在高并发、高吞吐量的环境中进行I/O处理。

I/O多路复用机制都依赖于一个事件分发器，事件分离器把接收到的客户事件分发到不同的事件处理器中，如下

![1e88d697e3b9b5bb8703bb7b994626e2.png][]

## select，poll，epoll ##

在操作系统级别select，poll，epoll是3个常用的I/O多路复用机制，简单了解一下将有助于我们理解Proactor和Reactor。

## select ##

select的原理如下：

![9fbeec75de70a2d8f116ab6a2a545f64.png][]

用户程序发起读操作后，将阻塞查询读数据是否可用，直到内核准备好数据后，用户程序才会真正的读取数据。

poll与select的原理相似，用户程序都要阻塞查询事件是否就绪，但poll没有最大文件描述符的限制。

## epoll ##

epoll是select和poll的改进，原理图如下：

![de4ecad2ea4fd514338c38cf69613b7c.png][]

epoll使用“事件”的方式通知用户程序数据就绪，并且使用内存拷贝的方式使用户程序直接读取内核准备好的数据，不用再读取数据

## Proactor ##

Proactor是一个异步I/O的多路复用模型，原理图如下：

![faaa00f98deabc2e30cc065d71d77868.png][]

*  用户发起IO操作到事件分离器
 *  事件分离器通知操作系统进行IO操作
 *  操作系统将数据存放到数据缓存区
 *  操作系统通知分发器IO完成
 *  分离器将事件分发至相应的事件处理器
 *  事件处理器直接读取数据缓存区内的数据进行处理

## Reactor ##

Reactor是一个同步的I/O多路复用模型，它没有Proactor模式那么复杂，原理图如下：

![1dfaf18a57e95a331a867c23ff3991d3.png][]

*  用户发起IO操作到事件分离器
 *  事件分离器调用相应的处理器处理事件
 *  事件处理完成，事件分离器获得控制权，继续相应处理

## Proactor和Reactor的比较 ##

*  Reactor模型简单，Proactor复杂
 *  Reactor是同步处理方式，Proactor是异步处理方式
 *  Proactor的IO事件依赖操作系统，操作系统须支持异步IO
 *  同步与异步是相对于服务端与IO事件来说的，Proactor通过操作系统异步来完成IO操作，当IO完成后通知事件分离器，而Reactor需要自己完成IO操作

## Reactor单线程模型 ##

前面已经简单介绍了Proactor和Reactor模型，在实际中Proactor由于需要操作系统的支持，实现的案例不多，有兴趣的可以看一下Boost Asio的实现，我们主要说一下Reactor模型，Netty也是使用Reactor实现的。

但单线程的Reactor模型每一个用户事件都在一个线程中执行：

*  性能有极限，不能处理成百上千的事件
 *  当负荷达到一定程度时，性能将会下降
 *  单某一个事件处理器发送故障，不能继续处理其他事件

## 多线程Reactor ##

使用线程池的技术来处理I/O操作，原理图如下：

![95b132493aa0cfed8e9520f22227cdf6.png][]

*  Acceptor专门用来监听接收客户端的请求
 *  I/O读写操作由线程池进行负责
 *  每个线程可以同时处理几个链路请求，但一个链路请求只能在一个线程中进行处理

## 主从多线程Reactor ##

在多线程Reactor中只有一个Acceptor，如果出现登录、认证等耗性能的操作，这时就会有单点性能问题，因此产生了主从Reactor多线程模型，原理如下：

![961f46972d38af7ef1d31201312e0771.png][]

*  Acceptor不再是一个单独的NIO线程，而是一个独立的NIO线程池
 *  Acceptor处理完后，将事件注册到IO线程池的某个线程上
 *  IO线程继续完成后续的IO操作
 *  Acceptor仅仅完成登录、握手和安全认证等操作，IO操作和业务处理依然在后面的从线程中完成

## Reactor模式结构 ##

在解决了什么是Reactor模式后，我们来看看Reactor模式是由什么模块构成。图是一种比较简洁形象的表现方式，因而先上一张图来表达各个模块的名称和他们之间的关系：

![d281cbedb99e4cf697cf17dee6f0eb38.png][]

*  Handle：即操作系统中的句柄，是对资源在操作系统层面上的一种抽象，它可以是打开的文件、一个连接(Socket)、Timer等。由于Reactor模式一般使用在网络编程中，因而这里一般指Socket Handle，即一个网络连接（Connection，在Java NIO中的Channel）。这个Channel注册到Synchronous Event Demultiplexer中，以监听Handle中发生的事件，对ServerSocketChannnel可以是CONNECT事件，对SocketChannel可以是READ、WRITE、CLOSE事件等。
 *  Synchronous Event Demultiplexer：阻塞等待一系列的Handle中的事件到来，如果阻塞等待返回，即表示在返回的Handle中可以不阻塞的执行返回的事件类型。这个模块一般使用操作系统的select来实现。在Java NIO中用Selector来封装，当Selector.select()返回时，可以调用Selector的selectedKeys()方法获取Set<SelectionKey>，一个SelectionKey表达一个有事件发生的Channel以及该Channel上的事件类型。上图的“Synchronous Event Demultiplexer ---notifies--> Handle”的流程如果是对的，那内部实现应该是select()方法在事件到来后会先设置Handle的状态，然后返回。不了解内部实现机制，因而保留原图。
 *  Initiation Dispatcher：用于管理Event Handler，即EventHandler的容器，用以注册、移除EventHandler等；另外，它还作为Reactor模式的入口调用Synchronous Event Demultiplexer的select方法以阻塞等待事件返回，当阻塞等待返回时，根据事件发生的Handle将其分发给对应的Event Handler处理，即回调EventHandler中的handle\_event()方法。
 *  Event Handler：定义事件处理方法：handle\_event()，以供InitiationDispatcher回调使用。
 *  Concrete Event Handler：事件EventHandler接口，实现特定事件处理逻辑。

## 优点 ##

1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；

2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；

3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；

4）可复用性，reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；

## 缺点 ##

1）相比传统的简单模型，Reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试。

2）Reactor模式需要底层的Synchronous Event Demultiplexer支持，比如Java中的Selector支持，操作系统的select系统调用支持，如果要自己实现Synchronous Event Demultiplexer可能不会有那么高效。

3） Reactor模式在IO读写数据时还是在同一个线程中实现的，即使使用多个Reactor机制的情况下，那些共享一个Reactor的Channel如果出现一个长时间的数据读写，会影响这个Reactor中其他Channel的相应时间，比如在大文件传输时，IO操作就会影响其他Client的相应时间，因而对这种操作，使用传统的Thread-Per-Connection或许是一个更好的选择，或则此时使用Proactor模式。

## Reactor中的组件 ##

*  Reactor:Reactor是IO事件的派发者。
 *  Acceptor:Acceptor接受client连接，建立对应client的Handler，并向Reactor注册此Handler。
 *  Handler:和一个client通讯的实体，按这样的过程实现业务的处理。一般在基本的Handler基础上还会有更进一步的层次划分， 用来抽象诸如decode，process和encoder这些过程。比如对Web Server而言，decode通常是HTTP请求的解析， process的过程会进一步涉及到Listener和Servlet的调用。业务逻辑的处理在Reactor模式里被分散的IO事件所打破， 所以Handler需要有适当的机制在所需的信息还不全（读到一半）的时候保存上下文，并在下一次IO事件到来的时候（另一半可读了）能继续中断的处理。为了简化设计，Handler通常被设计成状态机，按GoF的state pattern来实现。

## Rust异步网络编程 ##

Rust的高性能异步网络编程模式目前是基于[mio][]和[futures][]这两个库构建的生态。

[Tokio][]则连接这2个库构建了一个异步非阻塞事件驱动编程平台。

## 什么是 mio,futures,tokio ##

## 1- Mio ##

Mio是Rust的轻量级快速低级IO库，专注于非阻塞API,事件通知以及用于构建高性能IO应用程序的其他有用实用程序.

## 特征 ##

*  快速 - 相当于OS设施级别的最小开销（epoll，kqueue等..）
 *  非阻塞TCP，UDP。
 *  由epoll，kqueue和IOCP支持的I/O事件通知队列。
 *  运行时零分配
 *  平台特定扩展。

## 平台支持 ##

*  Linux
 *  OS X
 *  Windows
 *  FreeBSD
 *  NetBSD
 *  Solaris
 *  Android
 *  iOS
 *  Fuchsia (experimental)

## 2- futures ##

Rust中的零成本异步编程库,Futures可在没有标准库的情况下工作，例如在裸机环境中。

提供了许多用于编写异步代码的核心抽象：

*  Future是由异步计算产生的单一最终值。一些编程语言（例如JavaScript）将此概念称为“promise”。
 *  Streams表示异步生成的一系列值。
 *  Sinks支持异步写入数据。
 *  Executors负责运行异步任务。

还包含异步I/O和跨任务通信的抽象。

所有这些是任务系统的基础，它是轻量级线程(**协程**)的一种形式。使用Future，Streams和Sinks构建大型异步计算，然后将其生成作为独立完成的任务运行，但不阻塞运行它们的线程。

## 3- Tokio ##

Tokio : Rust编程语言的异步运行时,提供异步事件驱动平台，构建快速，可靠和轻量级网络应用。利用Rust的所有权和并发模型确保线程安全

*  基于多线程，工作窃取的任务调度程序。
 *  一个反应器操基于作系统的事件队列（epoll的，kqueue的，IOCP等）的支持。
 *  异步TCP和UDP套接字。

这些组件提供构建异步应用程序所需的运行时组件。

## 快速 ##

Tokio构建于Rust之上，提供极快的性能，使其成为高性能服务器应用程序的理想选择。

1:零成本抽象

与完全手工编写的等效系统相比，Tokio的运行时模型不会增加任何开销。

使用Tokio构建的并发应用程序是开箱即用的。Tokio提供了针对异步网络工作负载调整的多线程，工作窃取任务调度程序。

2:非阻塞I/O

Tokio由操作系统提供的非阻塞，事件I/O堆栈提供支持。

## 可靠 ##

虽然Tokio无法阻止所有错误，但它的目的是最小化它们。Tokio在运送关键任务应用程序时带来了安心。

1- 所有权和类型系统

Tokio利用Rust的类型系统来提供难以滥用的API。

2- Backpressure

Backpressure开箱即用，无需使用任何复杂的API。

3- 取消

Rust的所有权模型允许Tokio自动检测何时不再需要计算。Tokio将自动取消它而无需用户调用cancel函数。

## 轻量级 ##

Tokio可以很好地扩展，而不会增加应用程序的开销，使其能够在资源受限的环境中茁壮成长。

1- 没有垃圾收集器

因为Tokio使用Rust，所以不包括垃圾收集器或其他语言运行时。

2- 模块化

Tokio是一个小组件的集合。用户可以选择最适合手头应用的部件，而无需支付未使用功能的成本。

[Link 1]: https://link.zhihu.com/?target=https%3A//github.com/rustlang-cn/articles
[Rust]: https://link.zhihu.com/?target=https%3A//rustlang-cn.org/
[Rust 1]: https://link.zhihu.com/?target=https%3A//rustlang-cn.org/read/rust/2018/Linux%25E9%25AB%2598%25E6%2580%25A7%25E8%2583%25BD%25E6%259C%258D%25E5%258A%25A1%25E5%2599%25A8%25E7%25BC%2596%25E7%25A8%258B%25E6%25A8%25A1%25E5%25BC%258F.html
[Rust 2]: https://zhuanlan.zhihu.com/tianqingse
[1e88d697e3b9b5bb8703bb7b994626e2.png]: /images/20221024/65f35d2bb8464f0e98fefe972d667978.png
[9fbeec75de70a2d8f116ab6a2a545f64.png]: /images/20221024/1019b5eff4ed41bc8a4d2da2eda6a559.png
[de4ecad2ea4fd514338c38cf69613b7c.png]: /images/20221024/d08b447d6ef04bb3ad2ac2c769f593ca.png
[faaa00f98deabc2e30cc065d71d77868.png]: /images/20221024/f3356a16f0954b4fb866710269afee47.png
[1dfaf18a57e95a331a867c23ff3991d3.png]: /images/20221024/3473543fd8c24225b0abbf9058ecf7d5.png
[95b132493aa0cfed8e9520f22227cdf6.png]: /images/20221024/f7ed4dda81f247c9b61cf5c2aaf1d00c.png
[961f46972d38af7ef1d31201312e0771.png]: /images/20221024/e9cd4898f1d0437daa4ed1a9abca53b3.png
[d281cbedb99e4cf697cf17dee6f0eb38.png]: /images/20221024/9ba35423eefe4d5480719849942dfc7f.png
[mio]: https://link.zhihu.com/?target=https%3A//github.com/carllerche/mio
[futures]: https://link.zhihu.com/?target=https%3A//github.com/rust-lang-nursery/futures-rs
[Tokio]: https://link.zhihu.com/?target=https%3A//github.com/tokio-rs/tokio