【LInux内核中IO多路复用 背景+原理+直白总结+优缺点】EPoll篇 及大总结

Linux内核中的epoll多路复用原理是基于事件驱动的一种高效I/O处理机制，它主要用于监视多个文件描述符（file descriptors，简称fd）的状态并进行事件驱动的I/O操作。epoll相比传统的select和poll机制，在处理大量并发连接时具有更高的效率和更低的资源消耗。以下是epoll多路复用原理的详细解释：

事件驱动模型：

1. epoll是基于事件驱动的模型，通过将文件描述符注册到epoll内核事件表中，然后等待内核通知有事件发生，从而避免了阻塞式I/O和传统的轮询方式。
2. 当某个文件描述符上的事件发生时（如可读、可写等），内核会通知epoll，然后epoll再将事件通知给应用程序。

资源节省：

1. epoll使用一个文件描述符来管理多个连接，而不是每个连接都需要一个文件描述符，从而节省了资源。
2. 在Linux系统中，一个进程可以打开的最大文件描述符数量是有限的，而epoll可以突破这个限制，支持更多的并发连接。
3. 高效的空间复杂度：
   epoll内核事件表采用红黑树数据结构，对于大量的文件描述符，查找和插入的时间复杂度为O(log n)，保证了高效的性能。

工作原理：

1. 创建epoll实例：通过调用epoll_create()函数或epoll_create1()函数创建一个epoll实例，返回一个文件描述符，即epoll文件描述符。
2. 注册事件：使用epoll_ctl()函数将需要监视的文件描述符和对应的事件（如EPOLLIN表示可读事件）注册到epoll内核事件表中。
3. 等待事件：调用epoll_wait()函数等待内核通知有事件发生。该函数会阻塞调用线程，直到有注册的事件发生或者超时。
4. 处理事件：当epoll_wait()函数返回时，会告诉应用程序哪些文件描述符上有事件发生，应用程序可以根据这些信息进行相应的处理。

优势：

高效性：epoll避免了select和poll机制的轮询方式，只在有事件发生时通知应用程序，因此具有更高的效率。
可扩展性：epoll支持的文件描述符数量远大于select和poll，可以处理更多的并发连接。
灵活性：epoll除了提供水平触发（Level Triggered）外，还提供了边缘触发（Edge Triggered），使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。

进行系统的直白总结

1. epoll与select和poll相比，第一点是底层创建了一棵红黑树（不同的linux系统或内核不一样），红黑树会将接收的文件描述符进行存储维护，当文件描述符的个数发生改变时，只需要通过epoll_ctl系统调用告诉红黑树进行新增、删除、修改等操作，相比于select和poll每次拷贝一份新的文件描述符集给内核，节省了不少的资源；同时红黑树的数据结构相比于结构体数组、位图，时间复杂度方面优势更高；另外（epoll的另一个优点是它的可伸缩性。由于它只跟踪感兴趣的文件描述符（即那些已注册到epoll实例中的文件描述符），因此它可以处理比select和poll更多的文件描述符，而不会遇到文件描述符数量限制的问题（尽管这种限制在现代系统上通常很高））；
2. 第一点基本上就将底层思想平铺了一遍。第二点就是epoll的延伸。epoll相比于select、poll的代码量是比较高的，原因大概就是因为新的文件描述符集存储管理形式优化，而正是如此，延伸出了两种文件描述符状态变化的监听机制：水平触发和边沿触发（EPOLLET）。
3. 当一次收到的消息（缓存区数据）超出单次读取的范围（以读缓冲区为例）：
   3.1 水平触发：水平触发的监视（epoll_wait系统调用）会不停返回，直到所有缓存区数据都被读完；
   3.2 边沿触发：边沿触发的监视（epoll_wait系统调用）只返回一次，只有再次收到新的消息才会再次触发监视机制；
4. 接收一次消息却进行多次系统调用，很明显是非常不推荐的，于是在接收数据时，我们以边沿触发为例，但边沿触发可能会有单次监视读取数据不全的问题。
5. 而为了解决单次监视读取的数据有限，需要将接收的socket文件描述符设置为非阻塞状态，并通过循环反复的读取缓存区数据，直至缓存区数据为空。
6. 至此。

综上所述，Linux内核中的epoll多路复用原理通过事件驱动的方式、资源节省的策略、高效的空间复杂度以及灵活的工作流程，实现了高效、可扩展的并发I/O处理机制。