之前在分析ligty的时候提到，它的
超时处理模型大致如下：
注册一个处理alarm信号的回调函数，然后每秒钟触发一次
回调函数每次被触发之后，置某个标志位
在服务器的主循环中，每次循环都会检查这个标志位有没有被置位，如果有，说明一秒钟已经过去，这时轮询所有当前处理的连接，删除超时的连接。
这个模型，最大的问题在于，它的效率与当前连接数量有很大关系，数量大了，轮询一次的成本很高。
Nginx里面，处理超时连接的模型比之ligty高效了很多：
当前所有可能被触发的定时器被保存在红黑树这种数据结构中，通过红黑树，你可以很快的得到距离当前最快发生的定时器事件的时间差。
将这个时间差作为select/poll/epoll等函数的参数，也就是，最多等待这么长时间就返回。
当函数返回时，得到函数调用总共花费了多少时间，根据这个时间取出红黑树的根节点比较查看是否应该触发该定时器时间，如果可以则将该定时器从红黑树中删除，然后继续查看新的成为树根的定时器节点，这个过程一直进行下去直到没有定时器满足被触发的条件，也就是还没有到被触发的事件。
Nginx里面，新接收了一个连接，会保存这个连接上来的时间，并且以这个时间来加入红黑树定时器中。
可以看到，因为引入了红黑树这个数据结构，所有的定时器都可以按照顺序来依次取出，这样不用轮询所有事件来查看是否超时了；而以距离当前最快发生的定时器事件时间差作为轮询的定时，又可以不用使用alarm信号来触发定时，一举两得。
这个处理超时事件的模型，与我之前分析过的
libevent的模型，大体相同，只不过，在那里红黑树被堆代替了。