为什么需要协程，解决什么问题？

​ 在现在的 CS、BS 开发模式下，服务器的吞吐量是一个很重要的参数。其实吞吐量是 IO 处理时间加上业务处理。为了简单起见，比如，客户端与服务器 之间是长连接的，客户端定期给服务器发送心跳包数据。客户端发送一次心跳包到服务器，服务器更新该新客户端状态的。心跳包发送的过程，业务处理时长等于 IO 读取（RECV 系统调用）加上业务处理（更新客户状态）。吞吐量等于1s 业务处理次数。

业务处理（更新客户端状态）时间，业务不一样的，处理时间不一样，就不做讨论。 那如何提升 recv 的性能。若只有一个客户端，recv 的性能也没有必要提 升，也不能提升。若在有百万计的客户端长连接的情况，该如何提升。以Linux 为例，在这里需要介绍一个“网红”就是 epoll。服务器使用 epoll 管理百万计的客户端长连接，代码框架如下：

while (1) {   int nready = epoll_wait(epfd, events, EVENT_SIZE, -1);   for (i = 0;i < nready;i ++) {int sockfd = events[i].data.fd;if (sockfd == listenfd) {    int connfd = accept(listenfd, xxx, xxxx);    setnonblock(connfd);    ev.events = EPOLLIN | EPOLLET;    ev.data.fd = connfd;    epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);} else {    handle(sockfd);}    }  }

对于响应式服务器，所有的客户端的操作驱动都是来源于这个大循环。来源于 epoll_wait 的反馈结果。

对于服务器处理百万计的 IO。Handle(sockfd)实现方式有两种。

第一种，handle(sockfd)函数内部对 sockfd 进行读写动作。代码如下：

int handle(int sockfd) {   recv(sockfd, rbuffer, length, 0);   parser_proto(rbuffer, length);   send(sockfd, sbuffer, length, 0);}

handle 的 io 操作（send,recv）与 epoll_wait 是在同一个处理流程里面的。

这就是 IO 同步操作。

优点：

1. sockfd 管理方便。

2. 操作逻辑清晰。

缺点：

1. 服务器程序依赖 epoll_wait 的循环响应速度慢。

2. 程序性能差。

第二种，handle(sockfd)函数内部将 sockfd 的操作，push 到线程池中，代码如下：

int thread_cb(int sockfd) { // 此函数是在线程池创建的线程中运行。 // 与 handle 不在一个线程上下文中运行    recv(sockfd, rbuffer, length, 0);    parser_proto(rbuffer, length);    send(sockfd, sbuffer, length, 0);}int handle(int sockfd) { //此函数在主线程 main_thread 中运行 //在此处之前，确保线程池已经启动。    push_thread(sockfd, thread_cb); //将 sockfd 放到其他线程中运行。}

Handle 函数是将 sockfd 处理方式放到另一个已经其他的线程中运行，如此做法，将 io 操作（recv，send）与 epoll_wait 不在一个处理流程里面，使得 io操作（recv,send）与 epoll_wait 实现解耦。这就叫做 IO 异步操作。

优点：

1. 子模块好规划。

2. 程序性能高。

缺点：

正因为子模块好规划，使得模块之间的 sockfd 的管理异常麻烦。每一个子线程都需要管理好 sockfd，避免在 IO 操作的时候，sockfd 出现关闭或其他异常。

上文有提到 IO 同步操作，程序响应慢，IO 异步操作，程序响应快。

下面来对比一下 IO 同步操作与 IO 异步操作。

伪代码如下：

// 7400ms，检测io epoll、读写io recv/send在同一个流程中，按顺序的，是同步的func () {    while (1) { epoll_wait(); for(;;) { //对每一个fd进行recv / send     recv();     send(); }    }}// 1400ms，检测io epoll、读写io recv/send不在同一个流程中，是异步的thread_cb(void *arg) {//子线程    poll();  //在recv前再对fd做一次判断，判断这个fd是否真的可读，避免多个线程使用同一个fd。（这是治标不治本的操作，不能根除多个线程使用同一个fd）    recv();    send();}func () {    while (1) { epoll_wait(); for (;;) {     push_other_thread(); //线程池，检测io可读后，抛到子线程中 }    }}

可以看出，测试接入量的结果：

IO 异步操作，每 1000 个连接接入的服务器响应时间（1400ms 左右）；

IO 同步操作，每 1000 个连接接入的服务器响应时间（7400ms 左右）。

IO异步操作与IO同步操作对比：

那有没有一种方式，既能够有异步性能，又能够有同步的代码逻辑，来方便编程人员对 IO 操作的组件呢？ 肯定的说，有。那就是采用一种轻量级的协程来实现，在每次 send 或者 recv 之前进行切换，再由调度器来处理epoll_wait 的流程。