原文地址:http://blog.csdn.net/mindfloating/article/details/8033340
最近自己在写一个网络服务程序时需要管理大量客户端连接的,其中每个客户端连接都需要管理它的 timeout 时间。
通常连接的超时管理一般设置为30~60秒不等,并不需要太精确的时间控制。
另外由于服务端管理着多达数万到数十万不等的连接数,因此我们没法为每个连接使用一个Timer,那样太消耗资源不现实。
最早面临类似问题的应该是在操作系统和网络协议栈的实现中,以TCP协议为例:
其可靠传输依赖超时重传机制,因此每个通过TCP传输的 packet 都需要一个 timer 来调度 timeout 事件。
根据George Varghese 和 Tony Lauck 1996 年的论文
提出了一种定时轮的方式来管理和维护大量的 timer 调度,本文主要根据该论文讨论下实现一种定时轮的要点。
定时轮是一种数据结构,其主体是一个循环列表(circular buffer),每个列表中包含一个称之为槽(slot)的结构(附图)。
至于 slot 的具体结构依赖具体应用场景。
以本文开头所述的管理大量连接 timeout 的场景为例,描述一下 timing wheel的具体实现细节。
定时轮的工作原理可以类比于始终,如上图箭头(指针)按某一个方向按固定频率轮动,每一次跳动称为一个 tick。
这样可以看出定时轮由个3个重要的属性参数,ticksPerWheel(一轮的tick数),tickDuration(一个tick的持续时间)
以及 timeUnit(时间单位),例如 当ticksPerWheel=60,tickDuration=1,timeUnit=秒,这就和现实中的始终的秒针走动完全类似了。
这里给出一种简单的实现方式,指针按 tickDuration 的设置进行固定频率的转动,其中的必要约定如下:
在 Timing Wheel 模型中包含4种操作:
Client invoke:
1. START_TIMER(Interval, Request_ID, Expiry_Action)
2. STOP_TIMER(Request_ID)
Timer tick invoke:
3. PER_TICK_BOOKKEEPING
4. EXPIRY_PROCESSING
Timing Wheel 实现中主要考察的是前3种操作的时间和空间复杂度,而第4种属于超时处理通常实现为回调方法,由调用方的实现决定其效率,下面看一个用 java 实现的 Timing Wheel 的具体例子:
TimingWheel.java
ExpirationListener.java
我们分析一下这个简化版本 TimingWheel 实现中的 4 个主要操作的实现:
START_TIMER(Interval, Request_ID, Expiry_Action) ,这段伪代码的实现对应于TimingWheel的 add(E e) 方法。
STOP_TIMER(Request_ID),这段伪代码的实现对应于TimingWheel的 remove(E e) 方法。
PER_TICK_BOOKKEEPING,伪代码对应于 TimingWheel 中 TickerWorker 中的 run() 方法。
EXPIRY_PROCESSING,伪代码对应于TimingWheel 中的 notifyExpired() 方法
在维护大量连接的例子中:
这个简化版的 TimingWheel 实现一个实例只能支持一个固定的 timeout 时长调度,不能支持对于每个元素特定的 timeout 时长。
一种改进的做法是设计一个函数,计算每个元素特定的deadline,并根据deadline计算放置在wheel中的特定位置,这个以后再完善。