NGINX 定时器
写在前面
写NGINX系列的随笔，一来总结学到的东西，二来记录下疑惑的地方，在接下来的学习过程中去解决疑惑。
也希望同样对NGINX感兴趣的朋友能够解答我的疑惑，或者共同探讨研究。
整个NGINX系列的文章中，我会将我的疑惑用红色标出，希望能遇到前辈在评论中给我解答迷津。
定时器
在介绍定时器之前，先简要说下nginx处理事件的流程和方式。
Worker进程的主要流程：
1 static void 2 ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data){ 3 for(;;) { 4 if(ngx_exiting) {} 5 ngx_process_events_and_timers(cycle); 6 if (ngx_terminate) {} 7 if (ngx_quit) {} 8 if (ngx_reopen) {} 9 } 10 11 void 12 ngx_process_events_and_timers(ngx_cycle_t *cycle) { 13 (void) ngx_process_events(cycle, timer, flags); 14 }
ngx_process_events调用epoll(linux下）实现事件的处理。
ngx_process_events处理事件有两种方式：一是直接调用处理函数处理，二是将事件放到post队列中，函数返回后再处理队列中的事件。
在使用了 NGX_POST_EVENTS标记时，ngx_process_events不直接处理事件，将事件放到Post队列中，待函数返回，再在队列中取出事件处理。
因为调用ngx_process_events会加锁（为什么加锁？），函数返回后，将锁释放再处理事件，可以减少锁的占用时间。
以上是nginx处理事件的大体方式，下面介绍nginx中定时器的实现。
Nginx定时器使用红黑树组织（为什么使用红黑树，红黑树效率高到哪？可以研究下）存储，这个不多说。
Nginx定时器的触发有两种方式，第一种是设置时间信号。
ngx_event_process_init函数中 ，设置了时间信号，每隔固定时间触发，时间信号的处理函数，只是设置ngx_event_timer_alarm = 1，但他会中断ngx_process_events中epoll_wait的处理，epoll_wait返回后，调用ngx_time_update更新时间，接着返回到函数ngx_process_events_and_timers中处理，ngx_process_events_and_timers中，会调用ngx_event_expire_timers，查询超时的事件并处理。
但这种方式有个问题，如果事件信号是在处理IO事件时（epoll_wait调用之后）发生的，那么定时器的查询遍历，只能到下一次epoll_wait调用时才会处理，如果这时有IO事件发生，那么epoll_wait可以立即返回，然后因为上次信号发生已经置ngx_event_timer_alarm = 1，可以立即更新时间，ngx_process_events返回后可以处理定时器事件。但如果没有IO事件发生，epoll_wait会阻塞到下次时间信号到来，然后处理定时器事件，这样岂不大大降低了定时器的精确度。这块nginx怎么处理的？
另外每隔固定时间（具体设置的时间信号的时间）才更新时间值，甚至可能是两倍时间信号的时间才更新时间值，那么代码中在插入的定时器，实际触发时间和理论时间就会有这么大的误差。是不是这样呢？
Nginx定时器的第二种触发方式是利用epoll_wait的超时。
每次在调用epoll_wait之前，nginx都会取得下一个最小（最早要触发）的定时器的时间值，然后拿这个值作为epoll_wait的超时时间。这样epoll_wait在返回后就可以处理超时事件了。既可以在频繁IO的情况下处理超时，又可以在IO少量的情况下处理超时。
这种方式epoll_wait返回后，都会先更新时间，这样epoll_wait返回后，在IO事件的处理代码中加入定时器，误差不会太大，因为时间刚刚被更新。
但这个方法的问题是，IO频繁的情况下，也会频繁更新时间，是否会影响性能？
这两种方式各自的优缺点是哪些呢？
