C++高性能网络服务保姆级教程 day02 真正的高并发还得看IO多路复用

上节从一个基础的socket服务说起我们实现了一个基本的socket服务器，并留了个思考题

先启动server，然后启动一个client，不输入数据，这个时候在另外一个终端上再启动一个client，并在第二个client终端中输入数据，会发生什么呢？
实际操作后，我们会发现，在第二个client输入后，服务端并没有响应，直到第一个client也输入数据完成交互后，第二个client才会有数据返回。

这是由于服务端accept获取到第一个client的套接字后，由于第一个client未输入数据，所以服务端进程会阻塞在等待客户端数据那一行。

…
int read_num = read(accept_fd, read_msg, 100);
…
所以，第二个client完成三次握手后，连接一直在服务端的全连接队列中，等待accept获取处理。

多线程，一个线程一个连接
后续的client无法得到处理是由于服务端只有一个线程，获取client套接字还有连接通信全在一个线程中。

那我们直接开多个线程就好了，主线程只负责accept获取客户端套接字。每来一个连接，我们就新起一个线程去处理客户端和服务端的通信。这样多个连接之间就不会互相影响了。服务端程序如下：

// per_conn_per_thread_server.cpp
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#include
#include <arpa/inet.h>
#include <string.h>
#include
#include <errno.h>

void handleConn(int accept_fd) {
char read_msg[100];
int read_num = read(accept_fd, read_msg, 100);
printf(“get msg from client: %s\n”, read_msg);
int write_num = write(accept_fd, read_msg, read_num);
close(accept_fd);
}

int main() {
int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in server_addr;
bzero(&server_addr, sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = inet_addr(“127.0.0.1”);
server_addr.sin_port = htons(8888);
if (bind(listen_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) {
printf(“bind err: %s\n”, strerror(errno));
close(listen_fd);
return -1;
}

if (listen(listen_fd, 2048) < 0) {
printf(“listen err: %s\n”, strerror(errno));
close(listen_fd);
return -1;
}

struct sockaddr_in client_addr;
bzero(&client_addr, sizeof(struct sockaddr_in));
socklen_t client_addr_len = sizeof(client_addr);
int accept_fd = 0;
while((accept_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_addr_len)) > 0) {
printf(“get accept_fd: %d from: %s:%d\n”, accept_fd, inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port));
std::thread handleThread(handleConn, accept_fd);
// 将线程设置为后台线程，避免阻塞主线程
handleThread.detach();
}
}
使用thread库时，如果使用g++进行编译需要添加-lpthread,完整编译命令：

g++ -std=c++11 xxx.cpp -lpthread
看似解决阻塞问题了，但其实这种方案有大缺陷，只要我们稍微加大下客户端的并发度，就会发现服务端会处理不过来。每来一个连接都创建一个新线程，处理完后再销毁线程，这种处理方式成本太大。

IO多路复用和Reactor模型
我们仔细分析下，「per connection per thread」出现性能瓶颈有以下几个原因：

一个系统能同时创建的线程数量是有限的，而且线程数量