经典高并发服务器设计逻辑

最新推荐文章于 2023-12-22 04:52:21 发布

机械猿--

最新推荐文章于 2023-12-22 04:52:21 发布

阅读量692

点赞数

文章标签：服务器 java 运维开发语言

本文链接：https://blog.csdn.net/weixin_38420245/article/details/131027724

版权

都是面试必问的八股，不管理不理解用不用得上，背就完事了。

服务器模型

对于并发量比较大的服务器，即listen监听端口一直忙碌于处理新建连接的场景，一般在主线程里面accept新的客户端连接并生成新连接的socket，然后将这些新连接的socket按既定规则（如轮询、哈希等）传递给工作线程池；每个工作线程各自持有一个epollfd，管理主线程分配过来的socket事件，由这些工作线程处理新连接上的网络IO事件（即收发数据+处理数据）。此外，工作线程还处理系统中的另外一些事务，如定时器等。

总体来说就是1+N+M模型，一个主线程专门用于处理新建连接事件，N个工作线程处理网络消息，M个线程做数据加工（如操作数据库等）。

经典服务器的优点在于：

主线程只关注处理新连接，不用处理网络IO事件，可以尽快响应新建客户端请求。主线程接受的新连接（每个连接对应一个socket fd）可以根据配置的负载均衡策略分配给各个工作线程。主线程记录各个工作线程上在线的socket fd数量，平衡服务器资源。此外还可以在工作线程做其他的处理逻辑。

如果不是高并发类的业务场景，listenfd所在的主线程比较空闲，可以不让listenfd独占一个线程，即主线程也参与clientfd的读写事件处理。新版本redis的多线程实现方式就是这样的。

工作线程设计逻辑

每个工作线程函数里面有一个循环流程，这些循环流程里面做的都是相同的事情。这个线程函数的内容细节如下：

//工作线程
void thread_func(void* thread_arg)
{
//这初始化资源
  while (没有接收到主线程发送过来的要求工作线程退出的信号)
  {
    //检查定时器，定时器任务一般放在最开始处理，保证时间间隔更精确
    check_and_handle_timers();
    //调用select/poll/epoll等多路复用接口，分离出读写事件
    epoll_or_select_func();
    //处理读事件或写事件
    handle_io_events();
    //其他的事情放最后做
    handle_other_things();
  }
//执行线程退出的资源清理工作
}

一些额外的工作如定时任务、信号处理任务等可以放到 handle_other_thing() 中处理，这些事件采用特殊的唤醒策略。如管道fd、enevtfd、socketpair。为什么epoll能管理这些异构的fd呢？在设备驱动层面实现了file_operations.poll方法的fd可以交给epoll管理，包括：socket、eventfd、timerfd。相反，反而是文件系统fd没有实现file_operations.poll方法，无法由epoll管理。

业务处理

void handle_io_events()
{
  //收发数据
  recv_or_send_data();
  //解包并处理数据
  decode_packages_and_process();
}

如果解析包及处理数据比较耗时，需要将业务处理逻辑单独拆出来交给另外的业务工作线程池处理。

发消息逻辑设计

处理后的数据需要从业务线程交给网络线程发送。

1、最简单的办法就是直接调用相应的发数据的接口，此时可能出现多个线程同时调用该socket的send函数。一个socket描述符如果在多个线程之间共享，就会出现竞态条件。为了保证数据正确性，需要对该socket发送加锁，确保同一时刻只有一个线程调用socket send方法。相当于业务线程做了网络线程的事。

2、业务线程将需要发送的数据放入共享区域，由定时器定时从共享区域取出来，再发送出去。缺点是存在延迟。

3、使用pipe等通知机制，唤醒epoll，在工作线程循环体的handle_other_things()中完成处理发送工作。这里发送数据也可以使用缓冲区缓存。

如果业务不耗时，可以直接放在网络IO工作线程中处理，直接在网络线程中发送。

可写事件与可读事件不太一样，有新连接到来时可以立即设置可读，但是只有有数据需要发送时才设置可写。所以在数据都发出去以后，要移除可写事件。

缓冲区设计

每一个socket连接都需要配置各自的缓冲区，业务层的缓冲区分为读缓冲区和写缓冲区，缓存的本质就是空间换时间。接收缓冲区主要用于HTTP等协议解析，写缓冲区用于业务层可持续追加发送数据。

如何设置大小呢？可以参考redis的设置，读缓冲限制大小，防止客户端乱搞。写缓冲不设置大小，使用链表或者vector自动适配，毕竟是自己生成的数据。

缓冲区内存的有效时间必须比I/O操作的时间要长，实现方式为：连接类需要继承自enabled_shared_from_this，然后在内部保存它需要的缓冲区，而且每次异步调用都要传递一个智能指针（shared_from_this()）给this操作。

流量控制

使用流量统计可以对所有客户端或者某一个客户端做一个限速。

当客户端连接数目比较多的时候，服务器在处理网络数据的时候，如果同时有多个socket上有数据要处理，由于cpu核数有限，根据上面先检测iO事件再处理IO事件可能会出现工作线程一直处理前几个socket的事件，直到前几个socket处理完毕后再处理后面几个socket的数据。

对于epollwait返回的客户端可读事件，对客户端进行流量统计，如果同时触发的可读事件超过某个阈值（按CPU核数设置），且某个客户端流量超过阈值，那么该轮循环不处理这个客户端的读事件。同时启动一个100ms的定时器，100ms后清除该客户端的流量统计值，该客户端又可以被服务器处理了。该项优化不适用于某些要求强顺序性的业务如游戏对战等业务场景。

异步connect实现方式

一般业务场景是不会调用connect接口的，但是代理服务器等场景会用到。为了让多路复用IO支持异步connect事件，流程如下：

1.创建socket，并将socket设置成非阻塞模式；

2.调用connect函数，此时无论是否连接成功都会立即返回；如果返回-1且错误码是EINPROGRESS，说明在连接中；

3. 接着调用select/epoll函数，在指定的时间内判断该socket是否可写，如果可写说明连接成功，反之则为连接失败。

setsockopt、bind、accept等接口的最后一个参数socklen_t既是入参又是出参，需要根据该参数来决定读取的用户内存区长度，因此传入的值需要初始化。这一点容易忽视。

Writev加速写的逻辑

也就是IO向量机制。

write操作的是连续内存块，writev操作的是分散的数据块，两个函数的最终操作结果都是将内容写入连续的空间。writev的固有开销比write大，因此对于小内存的写而言，很可能也没有copy+write高效。

wirte返回值处理

write经常不能够一次写完，此时会返回已经写了多少字节，如果业务继续写，此时就会阻塞；对于非阻塞socket而言，write会在buf不可写时返回的EAGAIN，那么在下一次write时，便可通过之前返回的值重新确定基址和长度。

writev也会返回已经写入的长度或者EAGAIN(errno)。此时writev并不是每次传同样的iovec就能解决问题，需要调用者重新处理iovec，即需要通过遍历iovec来计算新的基址。

writev适用于磁盘IO，对于写socket，尤其是非阻塞socket，尽量不要用writev，实现连续的内存块反而可以简化实现。

信号创建

在handle_other_thing()中需要对一些信号进行响应。采用signation，而不是signal调用来设置信号处理函数，因为signal调用会有一些未解决的已知问题。此外在使用signation设置信号处理函数时，可以设置SA_RESTART来自动恢复被信号中断的系统调用。如果不设置自动恢复，在有信号时read/write会返回-1且errno被设置为 EINTR，表示被信号打断，需要手动重新调用。

SIGPIPE

对一个已经收到FIN包的socket调用recv方法，如果接收缓冲已空，则返回0，表明连接关闭。
对一个已经收到FIN包的socket第一次调用send方法时，如果发送缓冲区未阻塞，则send调用会返回写入的数据量，同时进行数据发送。但是发送出去的报文会触发对端发回RST报文，因为对端的socket已经调用了close进行了完全关闭（不然本端不会收到FIN报文）。所以第二次调用send方法时（需要在收到RST之后）会触发SIGPIPE信号，这就是为什么第二次send才能触发 SIGPIPE的原因。

可以使用signation对SIGPIPE信号进行捕获，这样当第二次调用write方法时，会返回 -1，同时 errno错误码会被设置成 EPIPE，而不是直接杀死进程。

NONBLOCK

为避免返回值0具有二义性，对一个非阻塞的描述符如果无数据可读，则read返回-1，而且errno被设置为 EAGAIN。返回0，表示接收到对端的FIN，即对端写关闭。

Unix域协议

Unix域协议并不是一个网络协议族，而是在单个主机上执行客户/服务通信的一种方式。是进程间通信（IPC）的一种方式。
它提供了两类套接字：字节流套接字（类似TCP）和数据报套接字（类似UDP，但是是可靠的）。
UNIX域数据报服务是可靠的，不会丢失消息，也不会传递出错。（如何实现可靠的？）

线程安全

1、当一个进程正在阻塞在epoll_wait的时候，另一个线程调用epoll_ctl是否安全？eventpoll中有mutex互斥锁，添加、修改或者删除监听fd的时候, 以及epoll_wait返回, 向用户空间传递数据时都会持有这个互斥锁。

2、在ET模式下，如果用多线程epoll_wait同一个epoll-fd，那么当其监听的fd产生了事件，此时epoll采用的排它式唤醒，也就是仅唤醒等待队列的第一个线程。

如果此时fd又触发了新的事件，那么就会唤醒新的线程，这将会导致多个线程操作同一个fd，可能导致线程安全问题。

解决方案是使用EPOLLNESHOT标志，即在一次wait返回后禁止fd再产生事件，并在处理完成后使用epoll_ctl的MOD操作重新开启。

综上，可以说epoll_wait是多线程安全的。

3、对于客户端，只会有一个异步操作在等待。假如在某些情况，一个客户端有两个异步方法在等待，就需要互斥量了。这是因为两个等待的操作可能正好在同一个时间完成，然后会在两个不同的线程中间同时调用他们的完成处理函数。

io_service

io_service就是基于select/epoll等多路复用IO实现的I/O事件循环的框架，它提供了对同步异步I/O，定时器以及信号等事件的支持。

io_service可以将需要操作的文件描述符socket、定时器、信号等注册到epoll实例中，如下所示：

epoll_create(1)

epoll_ctl(epfd, EPOLL_CTL_ADD, socket1, &event1);

epoll_ctl(epfd, EPOLL_CTL_ADD, socket2, &event2);// ...

然后，io_service不断地调用epoll_wait函数阻塞在事件循环中，直到某个文件描述符有事件被触发。在每个循环迭代中，io_service会检查是否有“就绪”(ready)的I/O事件，并将其添加到事件队列中。这样，io_service就可以调度这些事件的回调函数来处理I/O操作。在回调函数中，可以使用socket.async_read_some、socket.async_write_some等函数来启动异步读写操作，然后将读写缓冲区和回调函数的handler参数一起传递给底层的I/O系统函数，比如read和write等。

为什么一个io_service实例可以有多个处理线程呢？推测是内部io_service采用经典服务器模型实现了1+N的线程模型，通过特定的分发策略将新事件分发至多个线程处理。

关于io_service::strand

strand实现有序的原理是，内部维护一个任务队列，将所有异步操作包装成handler回调函数，并将这些回调函数绑定到strand上。

惊群现象

商用服务器系统如CentOS7中使用多线程对同一listenfd调用accept接口是没有惊群现象的，不过也可以参考一下。

1、由一个主进程进行accept监听，接受一个新连接之后再fork出一个子进程，把连接丢给子进程去进行业务处理，然后主进程继续监听。此时只有一个进程监听，无惊群现象。

2、由主进程fork出一批子进程，子进程继承了父进程的这个监听端口，多进程/线程共享该listenfd，然后都调用accept监听。多个子进程的PID挂在fd的waitqueue队列上，当全连接队列触发唤醒accept时，内核采用exclusive排他唤醒，即只唤醒队列头的PID，不会将waitqueue队列上的所有线程唤醒。

排他唤醒机制

linux对进程/线程唤醒提供了两种模式，一种是prepare_to_wait，一种是prepare_to_wait_exclusive。linux大部分接口都通过调用__wake_up_common唤醒任务等，该函数都会判断waitflags是否互斥，也就是通过prepare_to_wait_exclusive( )进行排他唤醒，不会有惊群现象。

综上，linux解决epoll惊群的方式如下：

1、给epoll添加一个EPOLLEXCLUSIVE的标志位，如果设置了这个标志位，那epoll将进程挂到等待队列时将会设置一下互斥标志位，此时内核在唤醒时判断该标志位，完成排他唤醒。

2、给socket提供SO_REUSEPORT标志，该flag允许不同进程的socket绑定到同一个端口。不同于父子进程共享socket监听的方式，此时每个进程的监听socket将指向open_file_tables下的不同节点，即不同的socket，也就是说不同进程是在自己的设备等待队列waitqueue下被挂起的，不存在共享fd的问题。内核中将设置了SO_REUSEPORT并且绑定同一端口的这些socket分到同一个group中，当有tcp连接事件到达的时候，内核将会对源IP+源端口取hash然后指定这个group中其中一个进程来接受连接，相当于内核实现了一个负载均衡。