事件驱动
事件驱动（Event Driven）是一种核心的编程范式，其根本特征是控制反转（Inversion of Control，IoC）。在这种模型中，程序的执行流不再由代码的顺序调用决定，而是由一系列异步发生的事件来驱动。应用程序的角色从主动轮询或等待，转变为被动地对事件做出响应，这构成了现代高性能系统的基础。
一个完整的事件驱动架构由四个基本部分组成，它们协同工作，构成了高效的事件处理流程。
1）事件源（Event Source）：事件的产生者。在网络编程中，最典型的事件源就是操作系统内核，它负责监视网络连接、文件句柄等资源的状态变化。
2）事件（Event）：对状态变化的封装。例如，一个数据包到达网卡，内核会生成一个“读就绪”事件；一个TCP连接请求被接受，会生成一个“连接就绪”事件。每个事件都包含了足够的信息（如关联的文件描述符）以供后续处理。
3）事件循环（Event Loop）：整个范式的引擎。它是一个持续运行的循环，其唯一职责就是向事件源查询是否有新事件发生。一旦获取到事件，它并不会自己处理，而是将事件分发给预先注册的处理器。基于epoll的while (true) { epoll_wait(...); }结构就是最经典的事件循环实现。
4）事件处理器（Event Handler）：预先定义的、用于处理特定事件的逻辑代码。这通常是一个函数或一个对象的方法。当事件循环将事件分发过来时，相应的处理器被调用，执行具体的业务逻辑，如读取数据、发送响应或关闭连接。
为什么需要Reactor模型
C10K问题（即同时处理1万个并发连接）是客户端-服务器模型在高并发场景下的典型挑战，由Dan Kegel于1999年提出。传统多线程模型在处理大规模并发连接时面临严重瓶颈：每一个连接创建一个线程（Thread-per-Connection）会导致内存消耗过高、上下文切换开销过大以及文件描述符资源耗尽。此外，阻塞I/O操作会使线程在等待数据时闲置，降低处理器利用率。
一种优化策略是使用线程池：服务器启动时创建固定数量的线程，组成线程池。当新连接到达时，从线程池分配空闲线程处理连接，处理完成后线程返回池中等待下一个任务。然而，由于使用阻塞I/O，当并发连接数过大时，线程池中的线程可能全部处于等待I/O操作的状态，导致处理器资源浪费。
为解决这些问题，Reactor模型应运而生。Reactor模型是事件驱动思想在网络I/O领域最经典的实现，它利用操作系统的I/O多路复用机制（如Linux的epoll），使少数线程甚至单个线程能够同时处理大量客户端连接。此外，它还支持轻松修改或扩展请求处理逻辑，尽管存在编程复杂度较高和调试难度较大的局限性。
在Reactor模式中，服务器不再为每个连接创建线程，而是将所有连接的文件描述符统一注册到一个中央事件循环中。这个事件循环通过epoll_wait等调用，以极低的成本同时监视海量连接。只有当某个连接上真正有事件发生时（如数据到达），操作系统才会唤醒事件循环，后者再将事件精确地分发给对应的处理器去执行非阻塞的读写操作。处理完毕后，控制权立刻返回事件循环，继续等待下一批事件。
未完待续
很高兴与你相遇！如果你喜欢本文内容，记得关注哦
