1分钟实现“延迟消息”功能和 10w定时任务, 如何高效触发超时

架构师之路
https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959961&idx=1&sn=afec02c8dc6db9445ce40821b5336736&chksm=bd2d07458a5a8e5314560620c240b1c4cf3bbf801fc0ab524bd5e8aa8b8ef036cf755d7eb0f6&scene=21#wechat_redirect

1分钟实现“延迟消息”功能

原创： 58沈剑架构师之路 2017-03-15

一、缘起

很多时候，业务有“在一段时间之后，完成一个工作任务”的需求。

例如：滴滴打车订单完成后，如果用户一直不评价，48小时后会将自动评价为5星。

一般来说怎么实现这类“48小时后自动评价为5星”需求呢？

常见方案：启动一个cron定时任务，每小时跑一次，将完成时间超过48小时的订单取出，置为5星，并把评价状态置为已评价。

假设订单表的结构为：t_order(oid, finish_time, stars, status, …)，更具体的，定时任务每隔一个小时会这么做一次：

select oid from t_order where finish_time > 48hours and status=0;

update t_order set stars=5 and status=1 where oid in[…];

如果数据量很大，需要分页查询，分页update，这将会是一个for循环。

方案的不足：

（1）轮询效率比较低

（2）每次扫库，已经被执行过记录，仍然会被扫描（只是不会出现在结果集中），有重复计算的嫌疑

（3）时效性不够好，如果每小时轮询一次，最差的情况下，时间误差会达到1小时

（4）如果通过增加cron轮询频率来减少（3）中的时间误差，（1）中轮询低效和（2）中重复计算的问题会进一步凸显

如何利用“延时消息”，对于每个任务只触发一次，保证效率的同时保证实时性，是今天要讨论的问题。

二、高效延时消息设计与实现

高效延时消息，包含两个重要的数据结构：

（1）环形队列，例如可以创建一个包含3600个slot的环形队列（本质是个数组）

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

同时，启动一个timer，这个timer每隔1s，在上述环形队列中移动一格，有一个Current Index指针来标识正在检测的slot。

Task结构中有两个很重要的属性：

（1）Cycle-Num：当Current Index第几圈扫描到这个Slot时，执行任务

（2）Task-Function：需要执行的任务指针

假设当前Current Index指向第一格，当有延时消息到达之后，例如希望3610秒之后，触发一个延时消息任务，只需：

（1）计算这个Task应该放在哪一个slot，现在指向1，3610秒之后，应该是第11格，所以这个Task应该放在第11个slot的Set<Task>中

（2）计算这个Task的Cycle-Num，由于环形队列是3600格（每秒移动一格，正好1小时），这个任务是3610秒后执行，所以应该绕3610/3600=1圈之后再执行，于是Cycle-Num=1

Current Index不停的移动，每秒移动到一个新slot，这个slot中对应的Set<Task>，每个Task看Cycle-Num是不是0：

（1）如果不是0，说明还需要多移动几圈，将Cycle-Num减1

（2）如果是0，说明马上要执行这个Task了，取出Task-Funciton执行（可以用单独的线程来执行Task），并把这个Task从Set<Task>中删除

使用了“延时消息”方案之后，“订单48小时后关闭评价”的需求，只需将在订单关闭时，触发一个48小时之后的延时消息即可：

（1）无需再轮询全部订单，效率高

（2）一个订单，任务只执行一次

（3）时效性好，精确到秒（控制timer移动频率可以控制精度）

三、总结

环形队列是一个实现“延时消息”的好方法，开源的MQ好像都不支持延迟消息，不妨自己实现一个简易的“延时消息队列”，能解决很多业务问题，并减少很多低效扫库的cron任务。

另外，关于MQ的可达性、幂等性未来撰文另述。

如果对文章和配图满意的话，帮忙转发一下哈。

==【完】==

10w定时任务，如何高效触发超时

原创： 58沈剑架构师之路 2017-03-09

一、缘起

很多时候，业务有定时任务或者定时超时的需求，当任务量很大时，可能需要维护大量的timer，或者进行低效的扫描。

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

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

一般来说怎么实现这类需求呢？

“轮询扫描法”

1）用一个Map<uid, last_packet_time>来记录每一个uid最近一次请求时间last_packet_time

2）当某个用户uid有请求包来到，实时更新这个Map

3）启动一个timer，当Map中不为空时，轮询扫描这个Map，看每个uid的last_packet_time是否超过30s，如果超过则进行超时处理

“多timer触发法”

1）用一个Map<uid, last_packet_time>来记录每一个uid最近一次请求时间last_packet_time

2）当某个用户uid有请求包来到，实时更新这个Map，并同时对这个uid请求包启动一个timer，30s之后触发

3）每个uid请求包对应的timer触发后，看Map中，查看这个uid的last_packet_time是否超过30s，如果超过则进行超时处理

方案一：只启动一个timer，但需要轮询，效率较低

方案二：不需要轮询，但每个请求包要启动一个timer，比较耗资源

特别在同时在线量很大时，很容易CPU100%，如何高效维护和触发大量的定时/超时任务，是本文要讨论的问题。

二、环形队列法

废话不多说，三个重要的数据结构：

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

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

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

同时：

1）启动一个timer，每隔1s，在上述环形队列中移动一格，0->1->2->3…->29->30->0…

2）有一个Current Index指针来标识刚检测过的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中应该都没有元素。

优势：

（1）只需要1个timer

（2）timer每1s只需要一次触发，消耗CPU很低

（3）批量超时，Current Index扫到的slot，Set中所有元素都应该被超时掉

三、总结

这个环形队列法是一个通用的方法，Set和Map中可以是任何task，本文的uid是一个最简单的举例。

HashedWheelTimer也是类似的原理，有兴趣的同学可以百度一下这个数据结构，Netty中的一个工具类，希望大家有收获，帮忙转发一下哈。

==【完】==