大概做高性能服务器的,都绕不开事件处理模块来,一般一个事件模块,会分为以下几部分:

  • 如何定义一个描述事件的数据结构。
  • 如何在事件模块中支持定时器。
  • 如果需要支持多平台,事件模块需要考虑如何统一以及区分各平台的具体实现。

下面就这三部分展开Nginx事件处理模块的分析。

ngx_event_t

描述事件的数据结构,一般至少需要以下几部分数据:

  • 用于保存用户相关的数据。
  • 用于保存事件触发之后的回调函数。
  • 用于表示事件状态、类型的数据。

nginx中,描述事件采用的数据结构是ngx_event_t中,其内部成员就是按照前面的三部分来划分了。

  • void *data:事件相关的数据。
  • ngx_event_handler_pt handler:事件被触发时的回调函数。
  • 第三类数据,ngx_event_t中划分的比较仔细:
    • unsigned write:1:可写标志位
    • unsigned active:1:活跃标志位
    • unsigned disabled:1:禁用标志位
    • unsigned eof:1:为1表示字节流已经结束
    • unsigned error:1:处理事件出错
    • unsigned timedout:1:事件超时
    • unsigned timer_set:1:为1表示这是一个超时事件
    • unsigned deferred_accept:1:为1表示需要延迟接收TCP连接
  • 除了以上三部分,还有其他一些重要的数据:
    • ngx_rbtree_node_t timer:红黑树节点,用于实现定时器的,下面讨论定时器再展开。
    • ngx_queue_t queue:延迟队列,如果事件不在轮询循环中直接处理,而是之后被处理,就放在这个队列中。

总体来看,event这个结构体为了涵盖所有可能的事件,做的大而全,不只是用来描述一般的IO事件,还包括了定时器事件,还包括了接收连接相关的数据。

定时器的实现

Nginx内部使用红黑树来实现定时器,目的在于能够快速的查询到哪些定时器超时了。不同的事件结构中,这部分实现采用的数据结构不一样,libevent、libuv采用的是最小堆,redis比较挫,这部分采用的是链表。

在一个事件循环中,因为既要考虑到一般的IO事件,又要考虑到定时器事件,所以都会以一个最近被触发的定时器来做为查询IO事件被触发的时间,即以下的伪代码:

查询最近将被触发的定时器超时时间返回t
将t做为epoll_wait之类的查询IO事件的超时时间,即最长等待t时间看有没有IO事件被触发
遍历定时器,查询已经超时的定时器进行回调处理

从这里可以看出,“迅速查询到距离当前最近被触发的定时器时间”以及“迅速查询到当前哪些定时器超时”,是这个定时器模块速度的关键。

由于红黑树、最小堆这种平衡数据结构,每次查询都排除掉当前一半的元素,可以做到时间复杂度O(logn),所以就常用来实现定时器了。

事件模块的实现

由于nginx需要跑在多个平台下面,而不同平台使用的事件机制又不一样,比如linux是epoll,bsd是kqueue等,需要实现事件模块的时候,既需要统一事件模块的共性部分,又需要区分不同平台的差异部分。

这看上去又是一个面向对象的设计问题了:基类负责实现共性的部分,子类具体再来实现各平台相关的部分。

前面分析libuv的时候提到过,libuv多使用宏来模拟C++中的继承,不是很认可这个代码风格,来看看nginx类似场景的实现。

nginx中,将事件相关的操作函数统一放在结构体ngx_event_actions_t中,可以把这部分类比于子类需要实现的函数接口:

typedef struct {
  ngx_int_t  (*add)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
  ngx_int_t  (*del)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);

  ngx_int_t  (*enable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);
  ngx_int_t  (*disable)(ngx_event_t *ev, ngx_int_t event, ngx_uint_t flags);

  ngx_int_t  (*add_conn)(ngx_connection_t *c);
  ngx_int_t  (*del_conn)(ngx_connection_t *c, ngx_uint_t flags);

  ngx_int_t  (*notify)(ngx_event_handler_pt handler);

  ngx_int_t  (*process_events)(ngx_cycle_t *cycle, ngx_msec_t timer,
    ngx_uint_t flags);

  ngx_int_t  (*init)(ngx_cycle_t *cycle, ngx_msec_t timer);
  void       (*done)(ngx_cycle_t *cycle);
} ngx_event_actions_t;

前面在分析到nginx如何解析配置的时候提到过,nginx中的配置是分层次的,event模块做为一个顶层的core模块,内部又有子模块,而这里的事件模块就是event模块中的子模块:

typedef struct {
  ngx_str_t              *name;

  void                 *(*create_conf)(ngx_cycle_t *cycle);
  char                 *(*init_conf)(ngx_cycle_t *cycle, void *conf);

  ngx_event_actions_t     actions;
} ngx_event_module_t;

在具体实现中,每个平台的事件模块创建自己的ngx_event_module_t结构,在create_conf、init_conf中完成对事件模块的初始化,然后填充模块的actions结构体。

最后,具体调用actions结构体中的函数,封装到宏里面,毕竟虽然有多平台的实现,最后也只能用上一个而已:

#define ngx_process_events   ngx_event_actions.process_events
#define ngx_done_events      ngx_event_actions.done

#define ngx_add_event        ngx_event_actions.add
#define ngx_del_event        ngx_event_actions.del
#define ngx_add_conn         ngx_event_actions.add_conn
#define ngx_del_conn         ngx_event_actions.del_conn

#define ngx_notify           ngx_event_actions.notify

而前面提到的事件处理部分共性的地方,全都放在函数ngx_process_events_and_timers里,那个函数里面再通过宏ngx_process_events调用具体事件模块的处理函数。

这里有个细节,其实前面的分析也提到过,nginx的事件模块里,不一定在检查到事件触发之后就会被马上调用回调函数来处理,而是可能放在一个post队列中,在轮询完所有事件之后再进行回调:

if (flags & NGX_POST_EVENTS) {
		// 有NGX_POST_EVENTS标志位的情况,将accept事件放到ngx_posted_accept_events队列中
		// 等待后续被回调
		queue = rev->accept ? &ngx_posted_accept_events
												: &ngx_posted_events;

		ngx_post_event(rev, queue);

} else {
		// 否则直接处理
		rev->handler(rev);
}