TinyWebSever项目面试题整理

Hush_NUIST

已于 2024-09-30 21:57:40 修改

阅读量602

点赞数 8

文章标签： c++ linux web php c语言

于 2024-09-23 15:36:14 首次发布

本文链接：https://blog.csdn.net/qq_39969848/article/details/142316685

版权

TinyWebSever项目面试题整理

1.为什么要做这样一个项目？

满足高并发和高性能需求：现代Web应用面对大量用户，Web服务器需要高效处理并发连接。比如通过线程池、非阻塞I/O、事件驱动机制（如epoll），Web服务器可以有效管理成千上万的并发请求，确保服务不会因高流量而崩溃或变慢。
理解网络编程：通过使用线程池、非阻塞socket、epoll等技术，项目可以帮助熟悉Linux下的网络编程模型，深入理解如何处理并发连接、如何进行事件驱动的网络通信等核心技术。
实践HTTP协议和Web服务器：构建一个能够解析HTTP请求并进行响应的Web服务器，有助于理解HTTP协议的工作原理，学会如何处理GET和POST请求，增强对Web服务端架构的理解。
提升系统优化意识：通过进行性能测试和优化（例如使用Webbench测试并发性能），这个项目还帮助你了解系统性能瓶颈、提升程序的效率、理解并实现高效的并发模型。

线程池相关

2.手写一下线程池

#include <iostream>
#include <vector>
#include <queue>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <functional>
#include <future>
#include <atomic>

class ThreadPool {
public:
    // 构造函数：创建线程并启动线程池
    ThreadPool(size_t threads) : stop(false) {
        for (size_t i = 0; i < threads; ++i) {
            workers.emplace_back([this] {
                while (true) {
                    std::function<void()> task;

                    {
                        std::unique_lock<std::mutex> lock(this->queue_mutex);
                        // 等待任务队列中有任务，或者停止信号
                        this->condition.wait(lock, [this] {
                            return this->stop || !this->tasks.empty();
                        });

                        if (this->stop && this->tasks.empty()) {
                            return; // 线程退出
                        }

                        // 从任务队列中取出一个任务
                        task = std::move(this->tasks.front());
                        this->tasks.pop();
                    }

                    // 执行任务
                    task();
                }
            });
        }
    }

    // 向线程池添加新任务
    template <class F, class... Args>
    auto enqueue(F&& f, Args&&... args) -> std::future<typename std::result_of<F(Args...)>::type> {
        using return_type = typename std::result_of<F(Args...)>::type;

        // 打包任务，保存到shared_ptr中
        auto task = std::make_shared<std::packaged_task<return_type()>>(
            std::bind(std::forward<F>(f), std::forward<Args>(args)...)
        );

        std::future<return_type> res = task->get_future();
        {
            std::unique_lock<std::mutex> lock(queue_mutex);

            // 禁止在停止线程池后添加任务
            if (stop) {
                throw std::runtime_error("enqueue on stopped ThreadPool");
            }

            // 将任务添加到队列
            tasks.emplace([task]() { (*task)(); });
        }

        // 通知一个线程有任务可以执行
        condition.notify_one();
        return res;
    }

    // 析构函数：等待所有线程完成任务后关闭
    ~ThreadPool() {
        {
            std::unique_lock<std::mutex> lock(queue_mutex);
            stop = true;
        }

        condition.notify_all();
        for (std::thread& worker : workers) {
            worker.join(); // 等待线程结束
        }
    }

private:
    std::vector<std::thread> workers;              // 工作线程
    std::queue<std::function<void()>> tasks;       // 任务队列
    std::mutex queue_mutex;                        // 任务队列互斥锁
    std::condition_variable condition;             // 条件变量，用于任务调度
    std::atomic<bool> stop;                        // 停止标志
};

int main() {
    // 创建一个线程池，包含4个工作线程
    ThreadPool pool(4);

    // 向线程池添加一些任务并获取结果
    auto result1 = pool.enqueue([] { return "Hello, "; });
    auto result2 = pool.enqueue([](const std::string& name) { return name + "World!"; }, "C++ ");

    // 输出任务结果
    std::cout << result1.get() << result2.get() << std::endl;

    return 0;
}

3. 线程的同步机制有哪些？

线程同步机制用于在多线程环境中协调线程的执行，避免数据竞争和资源冲突。常见的线程同步机制有以下几种：

1. 互斥锁（Mutex）

场景： 当多个线程需要安全地修改共享数据时，比如线程要同时操作一个变量、写日志、或者修改数据结构。

特点： 互斥锁就像一个房间的钥匙，只有拿到钥匙的人能进房间修改里面的东西，别人必须等他出来并把钥匙还回去。这种方式确保只有一个线程在修改资源，其他线程必须排队。

适合场景： 适用于简单的“谁进了房间谁就不能让别人进”的场景，比如银行柜台，只有一个人能处理事情，其他人要排队。

2. 读写锁（Read-Write Lock）

场景： 当多个线程需要读取数据，但只有少数线程需要写数据时，比如你有一个资源，大多数线程只是查看它，只有少数线程需要修改它。

特点： 读写锁像图书馆：多个读者（线程）可以同时看书（读取数据），但是一旦有人需要改书（写数据），其他读者必须等这个人改完再看。这种机制允许并发读，减少锁的开销。
写者优先于读者（一旦有写者，则后续读者必须等待，唤醒时优先考虑写者）

适合场景： 适用于“读多写少”的场景，比如在线图书馆，很多人看书，但只有管理员会更新书。

3. 条件变量（Condition Variable）

场景： 适用于某个线程必须等一个条件满足后才能继续工作，比如一个线程在等另一个线程完成任务
。
特点： 条件变量就像开会时等老板发言的场景。线程们在“会议室”里等条件满足（比如任务队列有新任务），一旦条件满足了，其他线程被通知并开始工作。

适合场景： 用于生产者-消费者模型，比如有一个任务队列，消费者线程只有在有新任务时才能干活。

4. 信号量（Semaphore）

场景： 控制资源的访问数量，比如限制某个资源同时只能有固定数量的线程使用（比如数据库连接池）。

特点： 信号量就像停车场的闸机，只允许有限数量的车（线程）进入。停车场满了，其他车只能在外面等。有时可以允许多个线程同时访问，但有上限。

适合场景： 适用于控制资源访问数量的场景，比如一个数据库有5个连接池，你只允许最多5个线程同时连接数据库。

5. 自旋锁（Spinlock）

场景： 当锁的等待时间非常短时，比如线程很快就能拿到锁的情况。

特点： 自旋锁像排队等公交车，如果你知道车马上就到，你可能就会站着等，而不会坐下休息（线程不会睡眠，而是不断检查锁是否可用）。它适用于等待时间非常短的场景，因为忙等很浪费资源。

适合场景： 适合非常短时间的临界区，适合多核处理器上多个线程竞争时，开销低于传统的互斥锁。

每种机制都有特定的使用场景和特点，合理选择可以避免资源争用和死锁，确保程序高效运行。

4. 线程池中的工作线程是一直等待吗？

在run函数中，我们为了能够处理高并发的问题，将线程池中的工作线程都设置为阻塞等待在请求队列是否不为空的条件上，因此项目中线程池中的工作线程是处于一直阻塞等待的模式下的。

5. 你的线程池工作线程处理完一个任务后的状态是什么？

（1）当处理完任务后如果请求队列为空时，则这个线程重新回到阻塞等待的状态

（2）当处理完任务后如果请求队列不为空时，那么这个线程将处于与其他线程竞争资源的状态，谁获得锁谁就获得了处理事件的资格。

6. 如果同时1000个客户端进行访问请求，线程数不多，怎么能及时响应处理每一个呢？

本项目是通过对子线程循环调用来解决高并发的问题的。

首先在创建线程的同时就调用了pthread_detach将线程进行分离，不用单独对工作线程进行回收，资源自动回收。

我们通过子线程的run调用函数进行while循环，让每一个线程池中的线程永远都不会停止，访问请求被封装到请求队列(list)中，如果没有任务线程就一直阻塞等待，有任务线程就抢占式进行处理，直到请求队列为空，表示任务全部处理完成。
除此之外，该项目采用了I/O多路复用技术，当客户连接有事件需要处理时，epoll会进行事件提醒，然后将对应的任务加入请求队列，等待工作线程的竞争，不仅如此，epoll的et（水平触发模式）可以及时的处理每一个线程的请求。

7. 如果一个客户请求需要占用线程很久的时间，会不会影响接下来的客户请求呢，有什么好的策略呢?

会，因为线程池内线程的数量时有限的，如果客户请求占用线程时间过久的话会影响到处理请求的效率，当请求处理过慢时会造成后续接受的请求只能在请求队列中等待被处理，从而影响接下来的客户请求。

应对策略(定时器)：

我们可以为线程处理请求对象设置处理超时时间, 超过时间先发送信号告知线程处理超时，然后设定一个时间间隔再次检测，若此时这个请求还占用线程则直接将其断开连接。

8. 什么是虚假唤醒?

虚假唤醒指的是某个线程被错误地唤醒，而实际上没有任何满足它被唤醒的条件。这种现象常常发生在使用条件变量来实现线程同步时。
举个例子，我们现在有一个生产者-消费者队列和三个线程。

1） 1号线程从队列中获取了一个元素，此时队列变为空。

2） 2号线程也想从队列中获取一个元素，但此时队列为空，2号线程便只能进入阻塞(cond.wait())，等待队列非空。

3）这时，3号线程将一个元素入队，并调用cond.notify()唤醒条件变量。

4）处于等待状态的2号线程接收到3号线程的唤醒信号，便准备解除阻塞状态，执行接下来的任务(获取队列中的元素)。

5）然而可能出现这样的情况：当2号线程准备获得队列的锁，去获取队列中的元素时，此时1号线程刚好执行完之前的元素操作，返回再去请求队列中的元素，1号线程便获得队列的锁，检查到队列非空，就获取到了3号线程刚刚入队的元素，然后释放队列锁。

6）等到2号线程获得队列锁，判断发现队列仍为空，1号线程“偷走了”这个元素，所以对于2号线程而言，这次唤醒就是“虚假”的，它需要再次等待队列非空。

9. 如何避免虚假唤醒?

为了防止这种情况，通常的做法是在等待条件变量时，使用一个条件循环来重新检查唤醒条件。这种结构通常如下：

std::queue<int> queue;
std::mutex mtx;
std::condition_variable cv;

void consumer() {
    std::unique_lock<std::mutex> lock(mtx);
    while (queue.empty()) {
        cv.wait(lock);  // 等待被唤醒
    }
    // 唤醒后再检查队列是否为空，避免虚假唤醒造成的误操作
    int task = queue.front();
    queue.pop();
    // 处理任务
}

void producer() {
    std::unique_lock<std::mutex> lock(mtx);
    queue.push(1);  // 向队列中添加任务
    cv.notify_one();  // 通知消费者线程
}

解释：

当消费者被唤醒时，不是立即执行任务，而是先通过 while(queue.empty()) 重新检查条件是否满足。如果条件不满足，消费者将继续等待，直到条件真正满足（即队列中有任务）。
这种额外的条件检查可以避免虚假唤醒带来的问题，确保线程在正确的条件下执行。

总结来说，在多线程环境中，虚假唤醒是正常现象，但通过在唤醒后重新检查条件的方式，程序可以有效防止虚假唤醒导致的逻辑错误。

10. 如何销毁线程?

1、通过判断标志位，主动退出(比如出现超时和报错)
2、通过Thread类中成员方法interrupt()，主动退出(发送中断信号)
3、通过Thread类中成员方法stop()，强行退出
在这里插入图片描述

11. detach和join有什么区别?

（1）当调用join()，主线程等待子线程执行完之后，主线程才可以继续执行，此时主线程会释放掉执行完后的子线程资源。主线程等待子线程执行完，可能会造成性能损失。

（2）当调用detach()，主线程与子线程分离，他们成为了两个独立的线程遵循cpu的时间片调度分配策略。子线程执行完成后会自己释放掉资源。分离后的线程，主线程将对它没有控制权。

当你确定程序没有使用共享变量或引用之类的话，可以使用detch函数，分离线程。

12. 线程池中有多少个线程，线程池数量如何设定

默认8个

调整线程池中的线程数量的最主要的目的是为了充分并合理地使用 CPU 和内存等资源，从而最大限度地提高程序的性能。

Ncpu 表示 CPU的数量。

如果是CPU密集型任务，就需要尽量压榨CPU，参考值可以设为 Ncpu+1能够实现最优的CPU 利用率，+1 是保证当线程由于页缺失故障（操作系统）或其它原因导致暂停时，额外的这个线程就能顶上去，保证CPU 时钟周期不被浪费

如果是IO密集型任务，参考值可以设置为 2 * Ncpu。因为线程间竞争的不是CPU的计算资源而是IO，IO的处理一般较慢，多于cores数的线程将为CPU争取更多的任务，不至在线程处理IO的过程造成CPU空闲导致资源浪费

最佳线程数量 = （（线程等待时间+线程CPU时间）／线程CPU时间）* CPU个数。

由公式可得，线程等待时间所占比例越高，需要越多的线程，线程CPU时间所占比例越高，所需的线程数越少。

12. 线程越多越好么

随着线程数越多，效率越来越高，但到一个峰值，再增加线程数量时，就会出现问题。线程太多要来回的切换，最终可能线程切换所用时间比执行时间业务所用时间还大。

并发模型相关

1.简单说一下服务器使用的并发模型？

1.线程池
2.非阻塞socket
3.多路复用epoll(et+lt)
4.两种事件处理模式都实现了

2.你用了epoll，说一下为什么用epoll，还有其他复用方式吗？区别是什么？

1）epoll的优点：epoll 是一种更加高效的 IO 复用技术

1、没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）；
2、效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；
即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。

3、内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。

epoll 的使用步骤及原理如下：

1）调用epoll_create()会在内核中创建一个指示epoll内核事件表的文件描述符，该描述符将用作其他epoll系统调用的第一个参数。

在这个结构体中有 2 个比较重要的数据成员：一个是需要检测的文件描述符的信息 struct_root rbr （红黑树），还有一个是就绪列表struct list_head rdlist，存放检测到数据发送改变的文件描述符信息（双向链表）；

2）调用epoll_ctl() 用于操作内核事件表监控的文件描述符上的事件：注册、修改、删除

3）调用epoll_wait() 可以让内核去检测就绪的事件，并将就绪的事件放到就绪列表中并返回，通过返回的事件数组做进一步的事件处理。

epoll 的两种工作模式：

a）LT 模式（水平触发）LT（Level - Triggered）是缺省的工作方式，并且同时支持 Block 和 Nonblock Socket。在这种做法中，内核检测到一个文件描述符就绪了，然后应用程序可以对这个就绪的 fd 进行 IO 操作。应用程序可以不立即处理该事件，如果不作任何操作，内核还是会继续通知。

b）ET 模式（边缘触发） ET（Edge - Triggered）是高速工作方式，只支持 Nonblock socket。在这种模式下，epoll_wait检测到文件描述符有事件发生，则将其通知给应用程序，应用程序必须立即处理该事件。必须要一次性将数据读取完，使用非阻塞I/O，读取到出现EAGAIN。但是，如果一直不对这个 fd 进行 IO 操作（从而导致它再次变成未就绪），内核不会发送更多的通知（only once）。

ET 模式在很大程度上减少了 epoll 事件被重复触发的次数，因此效率要比 LT 模式高。epoll 工作在 ET 模式的时候，必须使用非阻塞套接口，以避免由于一个文件描述符的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

3）select/poll/epoll区别

1）调用函数

select和poll都是一个函数，epoll是一组函数

2）文件描述符数量

select通过线性表描述文件描述符集合，文件描述符有上限（与系统内存关系很大），32位机默认是1024个，64位机默认是2048。

poll是链表描述，突破了文件描述符上限，最大可以打开文件的数目

epoll通过红黑树描述，最大可以打开文件的数目

3）将文件描述符从用户传给内核

select和poll通过将所有文件描述符拷贝到内核态，每次调用都需要拷贝

epoll通过epoll_create建立一棵红黑树，通过epoll_ctl将要监听的文件描述符注册到红黑树上

4）内核判断就绪的文件描述符

select和poll通过线性遍历文件描述符集合，判断哪个文件描述符上有事件发生

epoll_create时，内核除了帮我们在epoll文件系统里建了个红黑树用于存储以后epoll_ctl传来的fd外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。

epoll是根据每个fd上面的回调函数(中断函数)判断，只有发生了事件的socket才会主动的去调用 callback函数，其他空闲状态socket则不会，若是就绪事件，插入list

5）应用程序索引就绪文件描述符

select/poll 只返回发生了事件的文件描述符的个数，若知道是哪个发生了事件，同样需要遍历

epoll 返回的发生了事件的个数和结构体数组，结构体包含socket的信息，因此直接处理返回的数组即可

6）工作模式
select和poll都只能工作在相对低效的LT模式下

epoll则可以工作在ET高效模式，并且epoll还支持EPOLLONESHOT事件，该事件能进一步减少可读、可写和异常事件被触发的次数。

7）应用场景
当所有的fd都是活跃连接，使用epoll，需要建立文件系统，红黑书和链表对于此来说，效率反而不高，不如selece和poll

当监测的fd数目较小，且全部fd都比较活跃，建议使用select或者poll

当监测的fd数目非常大，且单位时间只有其中的一部分fd处于就绪状态，这个时候使用epoll能够明显提升性能

3.介绍一下几种I/O模型

下面是几种常见的 I/O 模型：

1. 阻塞 I/O（Blocking I/O）

**在阻塞 I/O 模型中，应用程序执行 I/O 操作时会被阻塞，直到操作完成。**例如，当应用程序请求从磁盘读取数据时，如果数据不可用，程序将会在调用处停止执行，直到数据被读取完成。这种模型简单但效率较低，因为在等待 I/O 操作完成期间，程序不能执行其他任务。

2. 非阻塞 I/O（Non-blocking I/O）

在非阻塞 I/O 模型中，应用程序执行 I/O 操作时不会被阻塞。如果 I/O 操作不能立即完成（如数据未就绪），操作会立即返回一个错误（通常是 EWOULDBLOCK 或 EAGAIN），应用程序可以继续执行其他任务**。应用程序需要不断地查询 I/O 操作是否完成，这种方式称为轮询。**

3. I/O 多路复用（I/O Multiplexing）

I/O 多路复用允许应用程序同时监控多个 I/O 流的事件。常用的实现有 select、poll 和 epoll（仅在 Linux 上）。应用程序使用这些调用等待多个 I/O 流中的任何一个变为就绪状态。当 I/O 流就绪，即数据可读或可写时，应用程序会被唤醒以处理该事件。这种模型适合处理大量并发连接，因为单个线程可以管理多个网络连接。

4. 信号驱动 I/O（Signal-driven I/O）

在信号驱动 I/O 模型中，应用程序首先对一个 I/O 流进行信号处理配置，然后继续执行其他任务；当 I/O 流就绪时，操作系统会发送一个信号通知应用程序。然后，应用程序可以启动 I/O 操作来处理数据。这种模型允许应用程序异步地处理 I/O 事件，但并不广泛使用。

5. 异步 I/O（Asynchronous I/O）

异步 I/O 模型是最高效的一种，应用程序发起 I/O 操作后可以立即继续执行其他任务。与信号驱动 I/O 不同，异步 I/O 的操作系统不仅通知应用程序 I/O 流就绪，而且会自动完成数据的传输。应用程序在 I/O 操作完成后会收到一个通知。这种模型最大化了程序的运行效率，因为应用程序无需在任何点等待 I/O 操作完成。

总结

这些 I/O 模型各有特点，适用于不同的应用场景。阻塞和非阻塞 I/O 更简单、易于理解，而 I/O 多路复用和异步 I/O 提供了更高的性能和灵活性，特别适合于网络服务和高并发应用。选择合适的 I/O 模型是提升应用性能的关键步骤。

4.简单说一下服务器使用的并发模型？两种高效的事件并发处理模式reactor、proactor？主从reactor模型

事件：I/O事件、信号及定时事件

（1）reactor模式中，主线程(I/O处理单元)只负责监听文件描述符上是否有事件发生，有的话立即通知工作线程(逻辑单元 )，将socket可读写事件放入请求队列，交给工作线程处理，即读写数据、接受新连接及处理客户请求均在工作线程中完成。通常由同步I/O实现（epoll_wait）。

（2）proactor模式中，主线程和内核负责处理读写数据、接受新连接等I/O操作，工作线程仅负责业务逻辑，如处理客户请求。通常由异步I/O实现(aio_read/aio_write)。

由于异步I/O并不成熟，实际中使用较少，本服务器采用：同步I/O模拟Proactor模式

同步I/O模型的工作流程如下（epoll_wait为例）：

主线程往epoll内核事件表注册socket上的读就绪事件。

主线程调用epoll_wait等待socket上有数据可读

当socket上有数据可读，epoll_wait通知主线程,主线程从socket循环读取数据，直到没有更多数据可读，然后将读取到的数据封装成一个请求对象并插入请求队列。

睡眠在请求队列上某个工作线程被唤醒，它获得请求对象并处理客户请求，然后往epoll内核事件表中注册该socket上的写就绪事件

主线程调用epoll_wait等待socket可写。

当socket上有数据可写，epoll_wait通知主线程。主线程往socket上写入服务器处理客户请求的结果。

（3）主从Reactor模式：核心思想是，主反应堆线程只负责分发Acceptor连接建立，已连接套接字上的I/O事件交给sub-reactor负责分发。其中 sub-reactor的数量，可以根据CPU的核数来灵活设置。

主反应堆线程一直在感知连接建立的事件，如果有连接成功建立，主反应堆线程通过accept方法获取已连接套接字，接下来会按照一定的算法选取一个从反应堆线程，并把已连接套接字加入到选择好的从反应堆线程中。主反应堆线程唯一的工作，就是调用accept获取已连接套接字，以及将已连接套接字加入到从反应堆线程中。

5.LT和ET的使用场景

LT适用于并发量小的情况，ET适用于并发量大的情况。

ET在通知用户之后，就会将fd从就绪链表中删除，而LT不会，它会一直保留，这就会导致随着fd增多，就绪链表越大，每次都要从头开始遍历找到对应的fd，所以并发量越大效率越低。ET因为会删除所以效率比较高。

（LT模式下只读一次，ET模式下是无限循环读）

6.为什么ET模式一定要设置非阻塞？

因为ET模式下是无限循环读，直到出现错误为 EAGAIN 或者 EWOULDBLOCK，这两个错误表示socket 为空，然后就停止循环。如果是阻塞，循环读在 socket 为空的时候就会阻塞到那里，主线程的 read（）函数一旦阻塞住，当再有其他监听事件过来就没办法读了，给其他事情造成了影响，所以必须要设置为非阻塞。

HTTP报文解析相关

1. 用了状态机啊，为什么要用状态机？

因为要响应HTTP请求

传统的控制流程都是按照顺序执行的，状态机能处理任意顺序的事件，并能提供有意义的响应—即使这些事件发生的顺序和预计的不同。

项目中使用主从状态机的模式进行解析，从状态机（parse_line）负责读取报文的一行，主状态机负责对该行数据进行解析，主状态机内部调用从状态机，从状态机驱动主状态机。每解析一部分都会将整个请求的m_check_state状态改变，状态机也就是根据这个状态来进行不同部分的解析跳转的

2. 状态机的转移图画一下

在这里插入图片描述

3. https协议为什么安全？

加密传输：HTTPS 通过 SSL/TLS 协议加密数据传输，确保即使数据在传输过程中被截获，也无法被破解或篡改。具体来说，它使用对称加密（AES等）保护数据的隐私。

身份验证：HTTPS 使用数字证书来验证服务器的身份，确保客户端连接的是可信赖的服务器，而不是冒充的攻击者。浏览器会检查服务器提供的证书是否由受信任的证书颁发机构（CA）签发。

数据完整性：通过消息摘要（Hash）技术，HTTPS 确保传输过程中数据没有被篡改。如果数据被篡改，接收方可以检测到，并拒绝接受数据。

总结：HTTPS 的安全性依赖于加密传输、身份验证和数据完整性，从而确保数据在传输过程中不被窃听、伪造或篡改。

4. https的ssl连接过程

5. GET和POST的区别

(1）get主要用来获取数据，post主要用来提交或修改数据。

（2）get的参数有长度限制，最长2048字节，而post没有限制。

（3）get是明文传输，可以直接通过url看到参数信息，post是放在请求体中，除非用工具才能看到。

（4）get的参数会附加在url中，以 " ？"分割url和传输数据，多个参数用 "&"连接，而post会把参数放在http请求体中。

（5）get请求会保存在浏览器历史记录中，也可以保存在web服务器日志中。（6）get请求会被浏览器主动缓存，而post不会，除非手动设置。

（7）get在浏览器回退时是无害的，而post会再次提交请求。

（8）get请求只能进行url编码，而post支持多种编码方式。

（9）get请求的参数数据类型只接受ASCII字符，而post没有限制。

（10）get是幂等的，而post不是幂等的。幂等性：对同一URL的多个请求应该返回同样的结果。

数据库登录注册相关

1.登录说一下？

将数据库中的用户名和密码载入到服务器的map中来，map中的key为用户名，value为密码

服务器端解析浏览器的请求报文，当解析为POST请求时，提取出请求报文的消息体的用户名和密码。

POST请求中最后是用户名和密码，用&隔开。分隔符&，前是用户名，后是密码。

通过m_url定位/所在位置，根据/后的第一个字符，使用分支语句实现页面跳转。具体的，

0 — 跳转注册页面，GET
1 — 跳转登录页面，GET
5 — 显示图片页面，POST
6 — 显示视频页面，POST
7 — 显示关注页面，POST

2.你这个保存状态了吗？如果要保存，你会怎么做？（cookie和session）

可以利用session或者cookie的方式进行状态的保存。

cookie其实就是服务器给客户分配了一串“身份标识”，比如“123456789happy”这么一串字符串。每次客户发送数据时，都在HTTP报文附带上这个字符串，服务器就知道你是谁了；

session是保存在服务器端的状态，每当一个客户发送HTTP报文过来的时候，服务器会在自己记录的用户数据中去找，类似于核对名单.

3.登录中的用户名和密码你是load到本地，然后使用map匹配的，如果有10亿数据，即使load到本地后hash，也是很耗时的，你要怎么优化？

这个问题的关键在于大数据量情况下的用户登录验证怎么进行？将所有的用户信息加载到内存中耗时耗利，对于大数据最遍历的方法就是进行hash，利用hash建立多级索引的方式来加快用户验证。具体操作如下：

首先，将10亿的用户信息，利用大致缩小1000倍的hash算法进行hash，这时就获得了100万的hash数据，每一个hash数据代表着一个用户信息块（一级）；

而后，再分别对这100万的hash数据再进行hash，例如最终剩下1000个hash数据（二级）。

在这种方式下，服务器只需要保存1000个二级hash数据，当用户请求登录的时候，先对用户信息进行一次hash，找到对应信息块（二级），在读取其对应的一级信息块，最终找到对应的用户数据

4.用的mysql啊，redis了解吗？用过吗？

5.为什么要创建数据库连接池？

1）池是资源的容器，这组资源在服务器启动之初就被完全创建好并初始化，本质上是对资源的复用。

当系统开始处理客户请求的时候，如果它需要相关的资源，可以直接从池中获取，无需动态分配；当服务器处理完一个客户连接后,可以把相关的资源放回池中，无需执行系统调用释放资源。
（2）若系统需要频繁访问数据库，则需要频繁创建和断开数据库连接，而创建数据库连接是一个很耗时的操作，也容易对数据库造成安全隐患。

在程序初始化的时候，集中创建多个数据库连接，并把他们集中管理，供程序使用，可以保证较快的数据库读写速度，更加安全可靠。

（3）使用单例模式和链表创建数据库连接池，实现对数据库连接资源的复用。

连接池的功能主要有：初始化，获取连接、释放连接，销毁连接池

连接池中的多线程使用信号量进行通信，使用互斥锁进行同步。

数据库连接的获取与释放通过RAII机制封装，避免手动释放。

RAII机制

RAII全称是“Resource Acquisition is Initialization”，直译过来是“资源获取即初始化”.
RAII的核心思想是将资源或者状态与对象的生命周期绑定，通过C++的语言机制，实现资源和状态的安全管理,智能指针是RAII最好的例子
具体来说：构造函数的时候初始化获取资源，析构函数释放资源

定时器相关

1.为什么要用定时器？

为了定期删除非活跃事件，防止连接资源的浪费。

非活跃，是指浏览器与服务器端建立连接后，长时间不交换数据，一直占用服务器端的文件描述符，导致连接资源的浪费。

定时事件，是指固定一段时间之后触发某段代码，由该段代码处理一个事件，如从内核事件表删除事件，并关闭文件描述符，释放连接资源。

2.说一下定时器的工作原理

定时器利用结构体将定时事件进行封装起来。定时事件，即定期检测非活跃连接。

服务器主循环为每一个连接创建一个定时器，并对每个连接进行定时。另外，利用升序双向链表将所有定时器串联起来，利用alarm函数周期性地触发SIGALRM信号，信号处理函数利用管道通知主循环，主循环接收到该信号后对升序链表上所有定时器进行处理，若该段时间内没有交换数据，则将该连接关闭，释放所占用的资源。

（信号处理函数仅仅发送信号通知程序主循环，将信号对应的处理逻辑放在程序主循环中，由主循环执行信号对应的逻辑代码。）

信号通知的逻辑：创建管道，其中管道写端写入信号值，管道读端通过I/O复用系统监测读事件
为什么管道写端要非阻塞？

send是将信息发送给套接字缓冲区，如果缓冲区满了，则会阻塞，这时候会进一步增加信号处理函数的执行时间，为此，将其修改为非阻塞。

3.双向链表啊，删除和添加的时间复杂度说一下？还可以优化吗？

删除定时器的时间复杂度是O(1)，添加和修改定时器的时间复杂度是O(n)（刚好添加在尾节点时）。

缺点：每次以固定的时间间隔触发SIGALRM信号，调用定时任务处理函数处理超时连接会造成一定的触发浪费。举个例子，若当前的TIMESLOT=5，即每隔5ms触发一次SIGALRM，跳出循环执行定时任务处理函数，这时如果当前即将超时的任务距离现在还有20ms，那么在这个期间，SIGALRM信号被触发了4次，定时任务处理函数也被执行了4次，可是在这4次中，前三次触发都是无意义的。

（1）在双向链表的基础上优化：

在添加新定时器时，除了检测新定时器是否小于头节点定时器，还应该检测是否大于尾节点定时器的时间，都不符合再使用常规插入。

（2）不使用双向链表优化：最小堆。

4.最小堆优化？说一下时间复杂度和工作原理

时间复杂度：添加：O(logn)，删除：O(1)
工作原理：

将所有定时器中超时时间最小的一个定时器的超时值，作为定时任务处理函数的定时值。这样，一旦定时任务处理函数被调用，超时时间最小的定时器必然到期，我们就可以在定时任务处理函数中处理该定时器。

然后，再次从剩余的定时器中找出超时时间最小的一个（堆），并将这段最小时间设置为下一次定时任务处理函数的定时值。如此反复，就实现了较为精确的定时。

日志相关

1.说下你的日志系统的运行机制？

使用单例模式创建日志系统，对服务器运行状态、错误信息和访问数据进行记录，该系统可以实现按天分类，超行分类功能，可以根据实际情况分别使用同步和异步写入两种方式。

其中异步写入方式，将生产者-消费者模型封装为阻塞队列，创建一个写线程，工作线程将要写的内容push进队列，写线程从队列中取出内容，写入日志文件。

超行、按天分文件逻辑，具体的，

日志写入前会判断当前day是否为创建日志的时间，行数是否超过最大行限制
若为创建日志时间，写入日志，否则按当前时间创建新log，更新创建时间和行数
若行数超过最大行限制，在当前日志的末尾加count/max_lines为后缀创建新log
日志文件
局部变量的懒汉模式获取实例
生成日志文件，并判断同步和异步写入方式
同步
判断是否分文件
直接格式化输出内容，将信息写入日志文件
异步
判断是否分文件
格式化输出内容，将内容写入阻塞队列，创建一个写线程，从阻塞队列取出内容写入日志文件

2.为什么要异步？和同步的区别是什么？

同步方式写入日志时会产生比较多的系统调用，若是某条日志信息过大，会阻塞日志系统，造成系统瓶颈。异步方式采用生产者-消费者模型，具有较高的并发能力。

生产者-消费者模型，并发编程中的经典模型。

以多线程为例，为了实现线程间数据同步，生产者线程与消费者线程共享一个缓冲区，其中生产者线程往缓冲区中push消息，消费者线程从缓冲区中pop消息。

阻塞队列，将生产者-消费者模型进行封装，使用循环数组实现队列，作为两者共享的缓冲区。

异步日志，将所写的日志内容先存入阻塞队列，写线程从阻塞队列中取出内容，写入日志。

可以提高系统的并发性能。

同步日志，日志写入函数与工作线程串行执行，由于涉及到I/O操作，当单条日志比较大的时候，同步模式会阻塞整个处理流程，服务器所能处理的并发能力将有所下降，尤其是在峰值的时候，写日志可能成为系统的瓶颈。

写入方式通过初始化时是否设置队列大小（表示在队列中可以放几条数据）来判断，若队列大小为0，则为同步，否则为异步。

若异步,则将日志信息加入阻塞队列,同步则加锁向文件中写

3.现在你要监控一台服务器的状态，输出监控日志，请问如何将该日志分发到不同的机器上？（消息队列）

压测相关

1.服务器并发量测试过吗？怎么测试的？

补充知识：

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

TPS：Transactions Per Second，即服务器每秒响应的事务数

QPS：每秒查询率，每秒的响应请求数量

并发数：系统同时处理的request数

响应时间：一般取平均响应时间

关系：QPS（TPS）= 并发数/平均响应时间

压力测试：每分响应请求数pages/min 和每秒传输数据量bytes/sec

使用Webbench对服务器进行压力测试，创建1000个客户端，并发访问服务器10s，正常情况下有接近8万个HTTP请求访问服务器。

2.webbench是什么？介绍一下原理

WebBench是一款在Linux下使用非常简单的压力测试工具。

原理：父进程 fork 若干个子进程，每个子进程在用户要求时间或默认的时间内对目标 web 循环发出实际访问请求，父子进程通过管道进行通信，子进程通过管道写端向父进程传递在若干次请求访问完毕后记录到的总信息，父进程通过管道读端读取子进程发来的相关信息，子进程在时间到后结束，父进程在所有子进程退出后统计并给用户显示最后的测试结果，然后退出。Webbench最多可以模拟3万个并发连接去测试网站的负载能力。

-c ：子进程的个数，即并发数

-t ：运行webbench的时间