搜索
  • Rust如何创建多线程web server
  • 发布于 2个月前
  • 308 热度
    0 评论
创建一个 http server，处理 http 请求。
创建一个单线程的 web 服务
web server 中主要的两个协议是 http 和 tcp。tcp 是底层协议，http 是构建在 tcp 之上的。
通过std::net库创建一个 tcp 连接的监听对象，监听地址为127.0.0.1:8080.
use std::net::TcpListener;

fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();

    for stream in listener.incoming() {
        let stream = stream.unwrap();

        println!("connected!");
    }
}

运行cargo run，在浏览器中访问http://127.0.0.1:8080,可以看到控制台输出。浏览器中显示链接被重置，无法被访问，因为没有响应任何数据。通过listener.incoming()方法返回一个迭代器，它是客户端与服务端之间打开的连接。称之为stream流，可以用来处理请求、响应。


首先处理请求，需要读取请求的参数，通过std::io库处理流信息，引入std::io::prelude::*包含一些读写流需要的特定 trait。
use std::io::{prelude::*, BufReader};
use std::net::TcpListener;

fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();

    for stream in listener.incoming() {
        let mut stream = stream.unwrap();
        // 堆代码 duidaima.com
        // 处理请求
        let buf_reader = BufReader::new(&stream);

        let http_request: Vec<_> = buf_reader
            .lines()
            .map(|result| result.unwrap())
            .take_while(|line| !line.is_empty())
            .collect();

        println!("requrest:{:#?}", http_request);
    }
}

BufReader 实现了BufReadtrait,提供了lines方法，通过换行符切割数据流返回一个Result<String,std::io::Error>迭代器。通过map获取到每一个结果值，take_while处理值直到为空结束，然后collect收集结果值。


http_request必须指定类型Vec<_>来收集。在闭包那一节中，迭代器适配器，必须调用消费适配器获取结果。

现在尝试给请求作出一个响应，响应状态码200表示成功响应。一个简单的响应头包括了协议、协议版本、响应状态、状态语句。 

let res = "HTTP/1.1 200 OK\r\n\r\n";
stream.write_all(res.as_bytes()).unwrap();
重新启动，再次浏览器访问地址，可以看到空白页面，F12查看网络请求，可以看到请求成功。

可以增加请求路径http://127.0.0.1:8080/home或增加参数看看请求信息的不同。将请求处理、响应处理放到一个函数中handle_request
接着可以返回一个html文件，这样页面就有了基础的展示效果。新建一个index.html文件
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=<device-width>, initial-scale=1.0" />
    <title>堆代码 duidaima.com</title>
  </head>
  <body>
    <p>hello world</p>
  </body>
</html>
读取index.html文件，并将文件内容作为响应返回
let res_status = "HTTP/1.1 200 OK\r\n";
let contents = fs::read_to_string("index.html").unwrap();
let len = contents.len();
let res = format!("{res_status}Content-Length:{len}\r\n\r\n{contents}");
stream.write_all(res.as_bytes()).unwrap();

再次运行，浏览器访问可以看到页面上已经展示信息。现在只要是所有的请求访问都会返回index.html文件，通常我们会根据访问路径来处理响应，比如http://127.0.0.1:8080/home


限制如果有请求路径或者是参数，则响应一个404.html页面,获取http_request第一个元素匹配GET / HTTP/1.1,响应 200，其他访问都是返回 404.
fn handle_request(mut stream: TcpStream) {
    // 处理请求
    let buf_reader = BufReader::new(&stream);
    let http_request: Vec<_> = buf_reader
        .lines()
        .map(|result| result.unwrap())
        .take_while(|line| !line.is_empty())
        .collect();

    if http_request[0] == "GET / HTTP/1.1" {
        let res_status = "HTTP/1.1 200 OK\r\n";
        let contents = fs::read_to_string("index.html").unwrap();
        let len = contents.len();
        let res = format!("{res_status}Content-Length:{len}\r\n\r\n{contents}");
        stream.write_all(res.as_bytes()).unwrap();
    } else {
        let res_status = "HTTP/1.1 404 NOT FOUND\r\n";
        let contents = fs::read_to_string("404.html").unwrap();
        let len = contents.len();
        let res = format!("{res_status}Content-Length:{len}\r\n\r\n{contents}");
        stream.write_all(res.as_bytes()).unwrap();
    }
}
优化一下if else里的代码,只有响应状态、响应的文件不一样，其他逻辑都一样。
let (res_status, file_name) = if http_request[0] == "GET / HTTP/1.1" {
    ("HTTP/1.1 200 OK\r\n", "index.html")
} else {
    ("HTTP/1.1 404 NOT FOUND\r\n", "404.html")
};
let contents = fs::read_to_string(file_name).unwrap();
let len = contents.len();
let res = format!("{res_status}Content-Length:{len}\r\n\r\n{contents}");
stream.write_all(res.as_bytes()).unwrap();
main方法中的简化，调用处理请求的函数。
fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();

    for stream in listener.incoming() {
        let mut stream = stream.unwrap();
        // 处理请求
        handle_request(stream);
    }
}

现在一个简易的 web 服务就好了，可以处理请求、可以处理响应。在这过程出现的错误我们都用unwrap方法处理，只要遇到错误，直接停止程序，而在真实环境中，需要处理这些错误，避免程序的不可访问。


创建多线程 server 服务

已经构建了单线程的服务，但是它每次只能处理一个请求，只要完成上一个请求之后才能处理下一个连接。如果请求很多，则需要等待，这种表现使得服务性能很差。


首先，来模拟演示一下单线程的堵塞行为，通过线程休眠模拟慢请求
use std::thread::{self};
use std::time::Duration;


fn handle_request(mut stream: TcpStream) {
    // ...

    // 将if部分改为match匹配，增加/sleep 路径匹配，用以堵塞线程
    let (res_status, file_name) = match &http_request[0][..] {
        "GET / HTTP/1.1" => ("HTTP/1.1 200 OK\r\n", "index.html"),
        "GET /sleep HTTP/1.1" => {
            // 线程堵塞5s
            thread::sleep(Duration::from_secs(5));
            ("HTTP/1.1 200 OK", "index.html")
        }
        _ => ("HTTP/1.1 404 NOT FOUND", "404.html"),
    };
    // ...
}

然后我们打开两个浏览器的 tab 页，访问不同的地址带路径/sleep和不带路径/的，先访问带路径的，可以看到浏览器正在加载，再访问不带路径的也发现浏览器正在加载。等 5 秒过后，全部加载完成，如果直接访问不带路径/则瞬间访问成功。为了处理这种情况，我们尝试为每一个请求都分配一个线程独立去处理请求任务。


构建一个线程池，当程序每收到新请求时，分配一个线程去处理该请求；其余线程等待处理其他接收到的请求，当线程处理完请求后，返回到线程池等待处理新的请求。这样我们就可以并发处理请求，这样就是服务的吞吐量。线程池的线程数不易过多，以固有数量的线程等待处理请求。这可以防止拒绝式服务攻击DOS

除了多线程处理服务，还有其他方法改善服务吞吐量，fork/join模型、单线程异步 I/O 模型、多线程异步 I/O 模型。
修改main方法，thread::spawn会创建一个新线程并运行闭包里的代码。
fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();
    for stream in listener.incoming() {
        let stream = stream.unwrap();

        thread::spawn(|| {
            handle_request(stream);
        });
        // handle_request(stream);
    }
}

现在可以再次尝试请求/sleep和/，可以发现/瞬间就响应了，/sleep还需要等待 5s。如果有上千、上万个请求，我们就要开同等数量的线程，在占用完所有资源后，就会使系统奔溃。通过线程池，创建有限的线程数量。在处理请求时，内部执行的方法execute会检测空闲的线程并执行之后的请求任务，如果请求超过线程池线程数量，则排队等待。 


fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();

    // 创建线程池
    let threadPool = ThreadPool::new(4);
    for stream in listener.incoming() {
        let stream = stream.unwrap();

        // thread::spawn(|| {
        //     handle_request(stream);
        // });
        threadPool.execute(|| {
            handle_request(stream);
        })
        // handle_request(stream);
    }
}


实现ThreadPool线程池类型
ThreadPool 类型并不存在于 rust 库中，需要我们自己实现ThreadPool。在rust-lib项目中，新建库thread_pool, 在src/lib.rs中,通过new函数实现创建ThreadPool实例，它接受一个参数size为线程的数量；通过定义execute函数接受一个闭包参数，闭包作为参数可以使用三个不同的 traitFn\FnMut\FnOnce,要决定用哪个取决于最终的调用，最终是要调用thread::spawn()的，它是使用了FnOnce的，还需要Send来将闭包从一个线程转移到另一个线程，绑定生命周期'static是因为不知道线程会执行多久。
pub struct ThreadPool;

impl ThreadPool {
    /// 创建线程池
    ///
    /// 线程池中线程的数量
    pub fn new(size: usize) -> ThreadPool {
        ThreadPool
    }

    pub fn execute<F>(&self, f: F)
    where
        F: FnOnce() + Send + 'static,
    {
    }
}
定义完之后，回到项目rust-web项目，引入依赖,在Cargo.toml,
[dependencies]
thread_pool = {path="../rust-lib/thread_pool"}
然后在src/main.rs使用依赖use thread_pool::ThreadPool;, 运行程序cargo run，没有报错正常运行。在new方法中要保证初始化的线程数是一个有效的值，即size不能为分数或等于 0.这没有意义。然后初始化 vector 实例来存储线程实例,thread::spawn()执行后返回的类型为thread::JoinHandle，它可以管理并等待创建的线程完成任务。
use std::thread;

pub struct ThreadPool {
    threads: Vec<thread::JoinHandle<()>>,
}

impl ThreadPool {
    /// 创建线程池
    ///
    /// 线程池中线程的数量
    ///
    /// # Panics
    ///
    /// `new`函数在size为0 时panicthread_pool
    pub fn new(size: usize) -> ThreadPool {
        assert!(size > 0);

        let mut threads = Vec::with_capacity(size);

        for _ in 0..size {
            // 创建对应数量的线程，并把它们存储到vec中
        }

        ThreadPool { threads }
    }
    // ...
}

之前一直在使用thread::spawn()来创建线程，并执行任务。现在在线程池中，需要提前创建线程，等待任务传入后再执行。标准的 rust 库中没有这样的定义，仍需要自己实现，可以称之为Worker数据结构，这样我们在ThreadPool存储的是Worker实例，在 worker 实例中存储一个单独的JoinHandle<()>实例，并赋予该实例一个唯一的id,方便日志和调用栈区分。


同样的，在ThreadPoolsrc/lib.rs 定义结构体Worker类型,对于外部 worker 类型是私有的，不需要pub定义。
use std::thread;

pub struct ThreadPool {
    // threads: Vec<thread::JoinHandle<()>>,
    workers: Vec<Worker>,
}
impl ThreadPool {
    /// 创建线程池
    ///
    /// 线程池中线程的数量
    pub fn new(size: usize) -> ThreadPool {
        assert!(size > 0);

        // let mut threads = Vec::with_capacity(size);
        let mut workers = Vec::with_capacity(size);

        for id in 0..size {
            // 创建对应数量的线程，并把它们存储到vec中
            workers.push(Worker::new(id))
        }

        ThreadPool { workers }
    }
    // ...
}

struct Worker {
    id: usize,
    thread: thread::JoinHandle<()>,
}

impl Worker {
    fn new(id: usize) -> Worker {
        let thread = thread::spawn(|| {});

        Worker { id, thread }
    }
}
运行我们的代码，正常运行。现在需要解决的是向创建的线程传递要处理的请求任务，通过之前文章中学过的channel信道来传递信息.在ThreadPool中存在一个信道实例充当发送者；并新建一个Job结构体存放用于向信道发送的闭包；execute方法会发送期望执行的任务。
use std::{sync::mpsc, thread};

pub struct ThreadPool {
    // threads: Vec<thread::JoinHandle<()>>,
    workers: Vec<Worker>,
    sender: mpsc::Sender<Job>,
}

struct Job;

impl ThreadPool {
    pub fn new(size: usize) -> ThreadPool {
        assert!(size > 0);
        // let mut threads = Vec::with_capacity(size);
        let mut workers = Vec::with_capacity(size);
        // 创建信道实例，提供一个发送者、接收者
        let (sender, receiver) = mpsc::channel();

        for id in 0..size {
            // 创建对应数量的线程，并把它们存储到vec中
            workers.push(Worker::new(id,receiver))
        }

        ThreadPool { workers, sender }
    }
}
ThreadPool实例存储信道发送者对象sender,需要将接受者实例receiver传递给Worker用于接收传递的信息。
impl Worker {
    fn new(id: usize, receiver: mpsc::Receiver<Job>) -> Worker {
        let thread = thread::spawn(|| {
            receiver;
        });

        Worker { id, thread }
    }
}

这会有一个错误信息，因为在 rust 中信道实现是多生产者、单消费者，不能将receiver接受者传递多个 work 实例。我们希望有一个任务列表，每个任务只允许处理一次。已经解决过在线程间共享状态，通过线程安全智能指针Arc<Mutex<T>>，多个线程共享所有权并允许线程修改其值。Arc使得多个 worker 拥有接受端，而Mutex确保一次只有一个 worker 能接收到任务。 

use std::{
    sync::{mpsc, Arc, Mutex},
    thread,
};


impl ThreadPool {
    pub fn new(size: usize) -> ThreadPool {
        assert!(size > 0);

        // let mut threads = Vec::with_capacity(size);
        let mut workers = Vec::with_capacity(size);

        let (sender, receiver) = mpsc::channel();

        // 通过`Arc<T>`创建多所有者,Mutex<T>共享数据
        let receiver = Arc::new(Mutex::new(receiver));

        for id in 0..size {
            // 创建对应数量的线程，并把它们存储到vec中
            workers.push(Worker::new(id, Arc::clone(&receiver)))
        }

        ThreadPool { workers, sender }
    }
}

impl Worker {
    fn new(id: usize, receiver: Arc<Mutex<mpsc::Receiver<Job>>>) -> Worker {
        // ...
    }
}
最后处理execute方法，它接受的闭包需要分配给空闲的线程并执行，修改Job结构体，它不是一个结构体，是接受execute方法接受的闭包类型的类型别名。
// struct Job;
type Job = Box<dyn FnOnce() + Send + 'static>;
在execute方法被调用后，新建Job实例，将任务从信道发送端发出，因为发送可能会失败，所以需要unwrap处理错误的发生。
impl ThreadPool {
    pub fn execute<F>(&self, f: F)
    where
        F: FnOnce() + Send + 'static,
    {
        let job = Box::new(f);

        self.sender.send(job).unwrap();
    }
}
继续优化接受端执行任务的逻辑，在接收到任务后，通过lock获取互斥器来锁定资源，防止其他地方使用资源。通过unwrap处理错误时的情况，在获取了互斥器锁定了资源后，调用recv()方法接受任务Job，这会阻塞当前线程，所有如果当前线程没有任务，则会一直等待直到有用的任务。Mutex<T>可以确保一次只有一个 Worker 线程请求任务。
impl Worker {
    fn new(id: usize, receiver: Arc<Mutex<mpsc::Receiver<Job>>>) -> Worker {
        let thread = thread::spawn(move || loop {
            let job = receiver.lock().unwrap().recv().unwrap();

            println!("开始执行任务{id}");

            job();
        });

        Worker { id, thread }
    }
}
通过loop循环执行闭包，一直向信道的接受端请求任务，并在得到任务时执行它们。
现在执行cargo run,并在浏览器中打开多个 tab 请求地址，可以看到打印输出

不能使用其他循环,比如while let \ if let \ match是因为它们循环时相关的代码块结束都不会丢弃临时值，导致锁守护的资源不能释放，不能被访问。


程序停止与清理
当我们终止程序后，如何去处理未执行完的任务，如何清理资源。为ThreadPool实现Drop,当线程池被丢弃时，应该join所有线程以确保任务完成。
impl Drop for ThreadPool {
    fn drop(&mut self) {
        for worker in &mut self.workers {
            println!("stop worker {}", worker.id);

            worker.thread.join().unwrap();
        }
    }
}
这里会有一个错误，不能编译，提示没有 worker 所有权，因为我们只得到了一个可变借用，不能调用join来消费线程。通过修改来使得thread实例成为一个Option值，这样就可以通过take方法来获取到其中Some成员值进行处理。清理时可以直接将thread赋值为None
struct Worker {
    id: usize,
    // thread: thread::JoinHandle<()>,
    thread: Option<thread::JoinHandle<()>>,
}
通过 rust 代码检测提示信息来修改其他需要调整的地方。Workernew 方法创建实例时，接收thread使用Some(thread)
在停止程序，清理时，通过take()获取到成员值后，再调用join()方法等待线程执行结束。
impl Drop for ThreadPool {
    fn drop(&mut self) {
        for worker in &mut self.workers {
            println!("stop worker {}", worker.id);

            if let Some(thread) = worker.thread.take() {
                thread.join().unwrap();
            }
        }
    }
}
正常逻辑来说调用了join()之后会关闭线程，但是由于之前的线程逻辑是循环闭包调用等待接受任务，也就是会导致线程一直不会执行完毕，导致阻塞。一直阻塞在第一个线程结束上。通过修改ThreadPool的Drop方法来显式丢弃sender。为了转移sender所有权，同样的使用Option类型来传递
pub struct ThreadPool {
    // threads: Vec<thread::JoinHandle<()>>,
    workers: Vec<Worker>,
    sender: Option<mpsc::Sender<Job>>,
}

impl ThreadPool {
    pub fn new(size: usize) -> ThreadPool {
    // ...
    // ...
    ThreadPool {
        workers,
        sender: Some(sender),
    }
    }

    pub fn execute<F>(&self, f: F)
    where
        F: FnOnce() + Send + 'static,
    {
        let job = Box::new(f);

        //  self.sender.send(job).unwrap();
        self.sender.as_ref().unwrap().send(job).unwrap();
    }
}

impl Drop for ThreadPool {
    fn drop(&mut self) {
        // 显示的丢弃sender
        drop(self.sender.take());

        for worker in &mut self.workers {
            println!("stop worker {}", worker.id);

            if let Some(thread) = worker.thread.take() {
                thread.join().unwrap();
            }
        }
    }
}
Drop()方法调用显示的丢弃sender后，这会关闭信道，表明了后续不会有消息发送，这时在Worker中无限循环调用接受消息的方法都会返回错误，此时可以修改逻辑在遭遇错误后退出循环。
impl Worker {
    fn new(id: usize, receiver: Arc<Mutex<mpsc::Receiver<Job>>>) -> Worker {
        let thread = thread::spawn(move || loop {
            let message = receiver.lock().unwrap().recv();

            match message {
                Ok(job) => {
                    println!("开始执行任务{id}");

                    job();
                }
                Err(_) => {
                    println!("worker {id} disconnected");
                    break;
                }
            }
        });

        Worker {
            id,
            thread: Some(thread),
        }
    }
}
现在可以正常清理、停机了，如果希望在服务停止前再处理几个请求，通过take()方法模拟只两个请求进行处理，来验证停机的逻辑。它是Iteratortrait
fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").unwrap();

    // 创建线程池
    let pool = ThreadPool::new(4);
    for stream in listener.incoming().take(2) {
        let stream = stream.unwrap();

        pool.execute(|| {
            handle_request(stream);
        })
    }
}
现在运行程序cargo run，同时在浏览器请求三次，看看控制台如何打印信息，第三个请求不会被执行。可以看到只执行完了两次请求，在第一次请求处理完成后，调用了Drop方法显示的丢弃了信道发送者sender,这样整个就导致所有 worker 关闭连接。

用户评论
可能感兴趣的话题