基于Kafka,延迟消息队列的设计

原创 吴就业 205 0 2021-08-15

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/a43f90d2332049008d5753395d5b83cd

作者:吴就业
链接:https://wujiuye.com/article/a43f90d2332049008d5753395d5b83cd
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

本篇文章写于2021年08月15日,从公众号|掘金|CSDN手工同步过来(博客搬家),本篇为原创文章。

由于Kafka不支持延迟消息,而目前公司技术栈中消息中间件使用的是Kafka,业务方希望使用RocketMQ满足延迟消息场景,但如果仅仅只是需要延迟消息功能而引入多一套消息中间件,这会增加运维与维护成本。在此背景下,我们希望通过扩展Kafka客户端提供延迟消息的支持。

本篇将介绍四种延迟消息实现方案的原理,以及分析其优缺点。

方案一:时间轮算法

每个生产者持有一个时间轮延迟消息队列,消息保存在内存中。

截屏2021-08-14 20.48.25.png

缺点分析:

方案二:单轮时间轮算法+文件存储(方案一的改进版)

使用单轮的时间轮算法,单轮的slot数量满足max delay = slot count,并让每个slot指向一个文件。

截屏2021-08-14 21.13.21.png

缺点分析:

方案三:多级分区+自动降级

按等级划分多个分区,根据剩余延时(期望发送时间-当前时间)将消息降级到指定分区,直到降级到真实topic。

截屏2021-08-14 21.03.19.png

缺点分析:

比如都是30~60分钟的等级,如果目前队列中的几条消息按顺序延迟值分别为:50、40、36、56,为了不影响后面的延时消息,前面每个消息都必须要消费,然后重新写回同等级分区。因此,最坏的情况下,延时高的消息可能需要经过上百次发送-订阅才能完成。

方案四:多级延迟,不支持任意时间精度的延迟消息(方案三的改进版)

参考RocketMQ支持延迟消息设计,不支持任意时间精度的延迟消息,只支持特定级别的延迟消息,将消息延迟等级分为1s、5s、10s 、30s、1m、2m、3m、4m、5m、6m、7m、8m、9m、10m、20m、30m、1h、2h,共18个级别,只创建一个有18个分区的延时topic,每个分区对应不同延时等级。

截屏2021-08-14 20.48.59.png

举例:

优点:

我们最终采用的是方案四,在实现上,我们为每个进程启动一个KafkaConsumer,使用正则表达式订阅以’.delay’结尾的topic,以此减少线程资源的消耗。在将消息发送到延迟topic时,将延迟等级作为消息key,而将原消息key存储在消息头,等发送到实际topic时再从延迟消息的消息头获取real key以及real topic。

#中间件

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

重构XXL-JOB,使用响应式编程实现异步RPC提升调度吞吐量

如果同一时刻需要下发几百个执行job的请求给执行器,使用这种阻塞的RPC,意味着需要开启几百个线程,使用几百个连接发送请求,而这几百个线程都需要阻塞等待响应,Job越多,需要的线程数就会越多,对调动中心的性能影响就越大。

重构支持多租户的XXL-JOB,如何实现多个逻辑集群的均衡选主

我们基于XXL-JOB的架构原理,重新架构设计了支持多租户横向扩展的分布式任务调度平台。本篇介绍如何实现多个逻辑集群(多个租户逻辑上是独立的集群)的均衡选主。

BFE原生路由转发功能分析

为什么加上“原生”,因为我们基于BFE开发已经魔改了。路由转发是BFE作为一个七层流量代理服务的核心功能,BFE设计了一套支持多租户、多机房的路由转发模型。