1.Tornado之ioloop源码学习
2.搞懂epoll和select和poll的码下区别|Linux高并发网络编程
3.Redis——Epoll网络模型
4.Linux内核源码解析---EPOLL实现4之唤醒等待进程与惊群问题
5.浅析Linux服务器网络开发模型
6.select，poll，码下epoll的码下区别以及使用方法

Tornado之ioloop源码学习

       在闲暇之余，我研究了tornado的码下源码，并计划以系列文章的码下形式记录关键部分，旨在总结学习心得并可能对使用该框架的码下jfinal 源码分析朋友有所帮助。如有疏漏，码下欢迎私信或评论指正。码下

       在研究开源项目时，码下我通常选择原始版本的码下tornadoweb/tornado，因为我认为其核心功能通常在1.0.0版本就已经完备，码下后续的码下改进主要集中在细节，而非重大功能。码下代码风格的码下统一性可能会因不同开发者提交的代码而有所差异。

       在阅读之前，码下我建议您对Linux的IO模型有所了解，特别是epoll和kqueue（在Mac或BSD系统中）的概念。Python 2.6及以上版本的select库提供了相关实现，但2.6以下版本则需要依赖tornado对底层epoll的封装。以下代码正是处理这个选择过程的。

       接下来，让我们深入探讨tornado的内部。首先，我们关注的是底层的 epoll 实现，如 GitHub 上的代码。它提供了常规的epoll功能，熟悉该技术的开发者一眼就能看懂。

       然后是 IOLoop 类，我们从头开始分析。其中定义了 epoll 中的关键事件，如 _EPOLLIN 和 _EPOLLOUT，公司聊天软件源码分别表示文件描述符的读写就绪状态。

       在代码中，_set_close_exec 方法的作用是解决子进程 fork 后可能遇到的问题。当子进程仅被 fork 并执行 exec 时，原有的文件描述符可能会消失，这个方法确保在 exec 时关闭这些描述符。

       r, w = os.pipe() 则创建了一个管道，用于高效地中断 IOLoop 循环。当管道另一端写入数据时，会阻塞 poll() 方法，从而停止循环。

       此外，IOLoop 通过 signal 模块监控 block 时间，当超过设定时间，将执行预先定义的 handler。信号 SIGALRM 和 ITIMER_REAL 通常一起使用。

       至关重要的 start 方法下，有几个辅助方法。_callbacks 存储了将在下一次 IOLoop 循环前调用的函数，保证跨线程安全。相比之下，_timeouts 保存了执行函数和截止时间的对应关系，允许延迟执行。

       关于 poll_timeout 的设置，它决定了 IOLoop 等待就绪事件的时间。默认值为 0.2 秒，如果存在可以执行的回调，会调整为尽快执行。最后，IOLoop 通过 poll 函数获取就绪事件，会员充值下载源码使用 signal.ITIMER_REAL 进行计时，处理后利用 pop 方法而非遍历，避免映射关系在处理过程中变化。

       以上就是对 IOLoop 的基本介绍，期待你的反馈和指正。

搞懂epoll和select和poll的区别|Linux高并发网络编程

       在深入理解Linux高并发网络编程中，理解epoll、select和poll的原理至关重要。它们都是多路复用机制，让单个线程能同时处理多个socket的I/O事件，但实现方式有所不同。

       首先，select和poll的共同点是，用户进程将待监控的socket的描述符（fd）传递给内核，内核会检查这些socket是否有活动。如果没有活动，线程会阻塞，等待socket被唤醒。它们的局限性在于，select的fd集合大小有的限制，而poll虽然改善了fd结构，但实际使用中已不太常见。

       epoll则是在优化上做了重大改进。它在内核中维护一个socket集合，通过epoll_ctl动态添加或删除socket，避免了每次调用都拷贝描述符。epoll使用红黑树存储socket，当socket有数据时，回调仅在ready_list中唤醒，减少了无用遍历。dll解密查看源码此外，epoll还利用内存映射技术，避免了拷贝，提高了效率。

       ET和LT模式是epoll的不同实现。ET是边沿触发，socket被读取事件后不再加入ready_list，若后续出现数据包，需要新事件触发。而LT是水平触发，每次读取后socket会再次加入ready_list，确保不会错过后续数据包。

       理解这些原理后，尽管源码阅读和深入探究是提升理解的途径，但到这个程度，基本能应对大部分场景。对于更深入的学习，视频课程是个不错的选择。

Redis——Epoll网络模型

       Redis 的高效性在于其使用多路复用技术管理大量连接，通过单线程事件循环处理请求，实现每秒数万 QPS 的性能。在深入了解 Redis 的 Epoll 实现之前，需要先对 Epoll 有清晰的认识。上一篇文章已对此进行深入浅出的讲解，涉及 select、poll、epoll 的实现。

       在掌握了 Epoll 的核心原理后，让我们深入 Redis 如何具体利用 Epoll。通过查阅 Redis 源码怎么搭建WORDPRESS5.0.0 版本的源码，我们可以清楚地看到 Redis 如何实现 Epoll。通过本文，我们重点探讨以下三个关键点：

       1. Epoll 是 Linux 内核提供的一种高效事件多路复用机制，核心方法有三个。它通过红黑树、双向链表和事件回调机制实现高效率。

       2. Redis 采用 Epoll 实现了 IO 多路复用，其原理是利用 Epoll 进行事件监听，通过事件循环处理各种请求。

       3. Redis 的事件驱动机制处理网络 IO 和时间事件，采用成熟的 I/O 多路复用模型（如 select、epoll）进行文件事件处理，对模型进行封装。

       事件驱动的核心组件在 src/ae.c 文件中实现，它通过 aeCreateEventLoop、aeMain 和 aeDeleteEventLoop 函数管理事件循环。aeMain 函数是事件循环的主体，调用 aeProcessEvents 处理就绪事件。

       Redis 采用自定义的事件驱动库 ae_event 实现 IO 多路复用，支持 select、epoll、evport 和 kqueue 等技术。在不同的操作系统上，Redis 会选择合适的多路复用技术。

       Redis 的实现细节如下：

       1. initServerConfig 函数初始化服务器配置，确保内部数据结构和参数正确。

       2. initServer 函数创建事件管理器 aeEventLoop。

       3. aeCreateEventLoop 创建事件管理器并初始化关键属性，如事件表、就绪事件数组等。

       4. aeCreateFileEvent 注册文件事件到底层多路复用系统。

       5. aeMain 作为事件循环的主体，无限循环处理文件事件和时间事件。

       6. aeProcessEvents 处理就绪事件，调用底层多路复用实现。

       Redis 的 Epoll 实现展示了其对底层技术的深入理解和灵活应用，通过高效的事件处理机制实现了高性能。

Linux内核源码解析---EPOLL实现4之唤醒等待进程与惊群问题

       在Linux内核源码的EPOLL实现中，第四部分着重探讨了数据到来时如何唤醒等待进程以及惊群问题。当网卡接收到数据，DMA技术将数据复制到内存RingBuffer，通过硬中断通知CPU，然后由ksoftirqd线程处理，最终数据会进入socket接收队列。虽然ksoftirqd的创建过程不在本节讨论，但核心是理解数据如何从协议层传递到socket buffer。

       在tcp_ipv4.c中，当接收到socket buffer时，会首先在连接表和监听表中寻找对应的socket。一旦找到，进入tcp_rcv_established函数，这里会检查socket是否准备好接收数据，通过调用sock_data_ready，其初始值为sock_def_readable，进而进入wake_up函数，唤醒之前挂上的wait_queue_t节点。

       在wake_up方法中，会遍历链表并回调ep_poll_callback，这个函数是epoll的核心逻辑。然而，如果epoll的设置没有启用WQ_FLAG_EXCLUSIVE，就会导致惊群效应，即唤醒所有阻塞在当前epoll的进程。这在default_wake_function函数中体现，如果没有特殊标记，进程会立即被唤醒并进入调度。

       总结来说，epoll的唤醒过程涉及socket buffer、协议层处理、链表操作以及回调函数，其中惊群问题与默认的唤醒策略密切相关。理解这些细节，有助于深入理解Linux内核中EPOLL的异步操作机制。

浅析Linux服务器网络开发模型

       为什么Nginx的性能要比Apache高得多?

       这主要是因为Nginx使用了最新的epoll(Linux 2.6内核)和kqueue(FreeBSD)网络I/O模型，而Apache则使用的是传统的select模型。曾在一篇博客上看到有这么个实例：

       假设你在大学中读书,要等待一个朋友来访,而这个朋友只知道你在A号楼,但是不知道你具体住在哪里,于是你们约好了在A号楼门口见面.如果你使用的阻塞IO 模型来处理这个问题,那么你就只能一直守候在A号楼门口等待朋友的到来,在这段时间里你不能做别的事情,不难知道,这种方式的效率是低下的.现在时代变化了,开始使用多路复用IO模型来处理这个问题.你告诉你的朋友来了A号楼找楼管大妈,让她告诉你该怎么走.这里的楼管大妈扮演的就是多路复用IO的角色。

       解释select和epoll模型的工作方式：

       select版大妈做的是如下的事情:比如同学甲的朋友来了,select版大妈比较笨,她带着朋友挨个房间进行查询谁是同学甲,你等的朋友来了。如果每到来一个朋友楼管大妈都要全楼的查询同学,那么处理的效率必然就低下了,过不久楼底就有不少的人了。

       epoll版大妈就比较先进了,她记下了同学甲的信息,比如说他的房间号,那么等同学甲的朋友到来时,只需要告诉该朋友同学甲在哪个房间即可,不用自己亲自带着人满大楼的找人了。epoll大妈可以不用吹灰之力就可以定位到同学甲。一看就很明白 epoll和select 模型的区别了吧。

       在Linux内核中，select所用到的FD_SET是有限的，即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个数，在内核源码中 /usr/include/linux/posix_types.h 中

       #undef __FD_SETSIZE#define __FD_SETSIZE

       如果想要同时检测个句柄的可读状态或 可写状态 ，select是不能实现的。在内核中实现select是使用轮询方法，即每次检测都会遍历所有FD_SET中的句柄，显然，select函数的执行时间与 FD检测的句柄数越多就会越费时。

       epoll是多路复用IO(I/O Multiplexing) 中的一种方式,仅用于linux2.6以上内核。而epoll模型它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于,举个例子,在1GB内存的机器上大约是万左右，具体请查看：cat /proc/sys/fs/file-max ,这个数目和系统内存关系很大。

       传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

       epoll有两种工作模式:Edge Triggered (ET)、Level Triggered (LT)

       LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。

       ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误)。

select，poll，epoll的区别以及使用方法

       在Linux网络编程中，I/O多路复用技术如select、poll和epoll，旨在提高服务器与多个客户端连接的并发处理能力。原生socket的阻塞特性限制了它无法同时处理多个请求。为了解决这个问题，我们有以下选项：

       1. select：最早出现在年的4.2BSD中，它允许监控多个描述符，一旦就绪即通知程序。尽管跨平台支持好，但存在最大文件描述符数量（Linux默认）的限制，且随着文件描述符增多，复制开销和扫描所有socket的开销会增加。

       2. poll：年System V Release 3引入，没有select的最大文件描述符限制。同样会复制大量描述符，开销随描述符数量线性增加。poll也采用水平触发机制，但处理大量就绪描述符时效率较低。

       3. epoll：Linux 2.6及以后引入，是最高效的方法。epoll支持事件回调，减少拷贝开销，对大量描述符更友好。它支持水平触发和边缘触发，边缘触发理论上性能更高，但实现复杂。epoll_wait只需检查就绪链表，而不是遍历所有描述符，节省CPU时间。

       总结来说，epoll通过内核回调机制，优化了描述符的管理，降低了开销，并提供了灵活性。使用epoll时，可以借助epoll_create、epoll_ctl和epoll_wait这三个核心函数，如在echo服务器的示例中操作。具体实现和详细机制请参考《select，poll，epoll的区别以及使用方法》文章及源代码。