跟Kafka学技术系列之时间轮

写在前面

kafka是一个分布式消息中间件，其高可用高吞吐的特点是大数据领域首选的消息中间件，Kafka是分布式消息队列的顺序读写文件分段组织串联起来思想的鼻祖，包括RocketMq这些消息队列都是借鉴了Kafka早期的架构和设计思路改造而来，所以在架构设计层面，Kafka有非常多值得借鉴的地方。本文是作者介绍Kafka优秀架构设计文章中的一篇，文中的代码和流程图均是base on 0.10.2.0版本。

引出环形队列和延迟队列

从2个面试题说起，第1个问题，如果一台机器上有10w个定时任务，如何做到高效触发？

具体场景是：

有一个APP实时消息通道系统，对每个用户会维护一个APP到服务器的TCP连接，用来实时收发消息，对这个TCP连接，有这样一个需求：“如果连续30s没有请求包（例如登录，消息，keepalive包），服务端就要将这个用户的状态置为离线”。

其中，单机TCP同时在线量约在10w级别，keepalive请求包较分散大概30s一次，吞吐量约在3000qps。

怎么做？

常用方案使用time定时任务，每秒扫描一次所有连接的集合Map<uid, last_packet_time>，把连接时间（每次有新的请求更新对应连接的连接时间）比当前时间的差值大30s的连接找出来处理。

另一种方案，使用环形队列法：

三个重要的数据结构：

1）30s超时，就创建一个index从0到30的环形队列（本质是个数组）

2）环上每一个slot是一个Set<uid>，任务集合

3）同时还有一个Map<uid, index>，记录uid落在环上的哪个slot里

这样当有某用户uid有请求包到达时：

1）从Map结构中，查找出这个uid存储在哪一个slot里

2）从这个slot的Set结构中，删除这个uid

3）将uid重新加入到新的slot中，具体是哪一个slot呢 => Current Index指针所指向的上一个slot，因为这个slot，会被timer在30s之后扫描到

4）更新Map，这个uid对应slot的index值

哪些元素会被超时掉呢？

Current Index每秒种移动一个slot，这个slot对应的Set<uid>中所有uid都应该被集体超时！如果最近30s有请求包来到，一定被放到Current Index的前一个slot了，Current Index所在的slot对应Set中所有元素，都是最近30s没有请求包来到的。

所以，当没有超时时，Current Index扫到的每一个slot的Set中应该都没有元素。

两种方案对比：

方案一每次都要轮询所有数据，而方案二使用环形队列只需要轮询这一刻需要过期的数据，如果没有数据过期则没有数据要处理，并且是批量超时，并且由于是环形结构更加节约空间，这很适合高性能场景。

第二个问题：在开发过程中有延迟一定时间