CN109743137A - 一种支持更新的分布式延迟消息队列处理系统 - Google Patents

Abstract

本发明涉及消息队列的技术领域，公开了一种支持更新的分布式延迟消息队列处理系统，包括消息队列、消息生产端、消息消费端，延迟消息包括队列名称、消息体、延迟发送的时间戳；消息生产端用于执行以下模块，判断模块，用于获取当前的延迟消息并判断消息队列中是否存在延迟消息；若是，则删除消息队列中延迟发送的时间戳并向消息队列中添加当前延迟消息中携带的延迟发送的时间戳；若否，则向消息队列中添加延迟消息。通过采用上述技术方案，在判断模块判断是时，只需更新延迟发送的时间戳即可完成延迟消息的延迟时间的更新，在中/高并发、分布式环境中实现了延迟消息的更新。

Description

一种支持更新的分布式延迟消息队列处理系统

技术领域

本发明涉及消息队列的技术领域，具体涉及一种支持更新的分布式延迟消息队列处理系统。

背景技术

消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息，消息队列是随内核持续的。

延迟消息队列在互联网产品中被广泛的应用，比如用户行为统计要求页面操作事件是顺序的：BeforeLoad必须先于Unload；比如数据分析系统会同步各个业务系统的数据，在计算时常存在数据依赖，即获取到B系统的某条数据时需要等待A系统的某条数据已同步时才能执行后续操作；比如对每个未付款的订单5分钟后发短信提醒、1天后关闭这种与记录实例相关的定时任务。对于这类需求比较通用的解决方案是使用延迟消息队列。

在一些场景下延迟的时间需要可以更新，比如用户行为统计要求用户5分钟内没有操作（页面点击、滑动等）视为离开，服务端需要获取离开消息，离开消息的时间是会随着用户的操作而顺延的，所以需要在用户有操作时更新延迟发送消息的时间。这就是支持更新的延迟队列。

延迟消息队列通常有如下几种实现：

1.类库中的定时任务与延迟队列：比如Java下的Timer、ScheduleExecutorService、DelayQueue；

2.封装数据库轮询：将任务写入到数据库、内存或其它存储介质中，启线程定期轮询是否到时间并执行相应的动作；

3.封装Quartz：Quartz这知名的调度类库，基于此可实现分布式下的延迟调度；

4.MQ：一些MQ自带延迟消息，如阿里开源的RocketMQ，RabbitMQ通过插件 及DeadLetter Exchanges 变相实现；

5.封装TimerWheel ：时间轮是一种高效的延迟设计方案，RocketMQ的内核正是基于此方案。

以上几种延迟消息队列实现都有一定的场景限制：类库中的定时任务与延迟队列只支持单机环境不支持分布式，分布式计算是一门计算机科学，它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多计算机进行处理，最后把这些计算结果综合起来得到最终的结果。分布式网络存储技术是将数据分散的存储于多台独立的机器设备上。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，不但解决了传统集中式存储系统中单存储服务器的瓶颈问题，还提高了系统的可靠性、可用性和扩展性。

封装数据库轮询及Quartz的方案存在一定的性能瓶颈，RocketMQ、RabbitMQ、封装TimerWheel都不支持延迟时间更新。

依赖IT技术的业务越发地复杂导致了问题场景的细化，不同场景都需要有针对性的解决方案，目前在中/高并发、分布式环境中支持更新的延迟消息队列并没有太好的解决方案。

发明内容

针对上述现有技术存在的不足，本发明的目的在于提供一种支持更新的分布式延迟消息队列处理系统，具有在中/高并发、分布式环境中支持延迟消息更新的效果。

为实现上述目的，本发明提供了如下技术方案：

一种支持更新的分布式延迟消息队列处理系统，包括消息队列、用于向消息队列内加入延迟消息的消息生产端、用于消费消息队列中的延迟消息的消息消费端，延迟消息包括队列名称、消息体、延迟发送的时间戳；消息生产端用于执行以下模块，

判断模块，用于获取当前的延迟消息并判断消息队列中是否存在延迟消息；

若是，则删除消息队列中延迟发送的时间戳并向消息队列中添加当前延迟消息中携带的延迟发送的时间戳；

若否，则向消息队列中添加延迟消息。

通过采用上述技术方案，队列名称携带有消息体的名称，每一个队列名称对应多个消息体，消息体携带有延迟消息需要执行的操作，延迟发送的时间戳携带有消息体延迟发送的时间。判断模块判断是，则删除原有的延迟发送的时间戳，并添加当前延迟消息对应的延迟发送的时间戳；判断模块中判断否，则向消息队列中添加延迟消息。在判断模块判断是时，只需更新延迟发送的时间戳即可完成延迟消息的延迟时间的更新，在中/高并发、分布式环境中实现了延迟消息的更新。

本发明的进一步设置为：消息队列中包含有队列名称集合、消息体集合、有序集合，其中，队列名称集合用于存储队列名称，消息体集合用于存储队列名称和消息体，有序集合用于存储队列名称和延迟发送的时间戳；

判断模块中通过判断队列名称集合中是否存在有与当前延迟消息对应的队列名称和消息体集合中是否存在有与当前延迟消息对应的消息体来判断消息队列中是否存在延迟消息。

通过采用上述技术方案，本地队列名称集合中仅存储有队列名称，消息体集合中存储消息体，有序集合中存储有时间戳，判断模块判断过程中产生消息互相干扰的概率小。判断模块判断过程主要包含以下步骤：

K1.判断本地队列名称集合中是否存在有与当前延迟消息对应的队列名称。当步骤K1判断否时，向队列名称集合中添加队列名称并向消息体集合中添加消息体。当步骤K1判断是时，则不执行向队列名称中添加队列名称的操作，之后向消息体集合中添加消息体。

K2.向消息体集合中添加消息体并判断消息体集合中是否存在有与当前延迟消息对应的消息体。向消息体集合中加入消息体后，消息体集合发出反馈消息，根据反馈消息即可判断消息体集合中是否存在有与延迟消息对应的消息体。在消息体集合中存在与延迟消息对应的消息体时，删除原有消息体从而完成了消息体的更新操作。

当步骤K1、K2同时为是时，判断模块判断是，反之，判断模块判断否。

本发明的进一步设置为：消息体集合与有序集合中均存储有与队列名称对应的消息ID。

通过采用上述技术方案，通过有序集合中的消息ID即可寻找到消息体集合中与消息ID对应的消息体，从而发送执行，消息体选择快速。

本发明的进一步设置为：系统启动时，将队列名称集合加载至本地队列名称集合中。

通过采用上述技术方案，在后续获取队列名称时，直接从本地队列名称集合中获取队列名称，提升了后续操作的性能。

本发明的进一步设置为：消息消费端用于执行以下模块，

准备模块，用于从本地队列名称集合中获取要消费的队列集合并为每一个队列启动一个新线程；

选择模块，用于将队列中的节点排序后获取要消费的节点；

采集模块，用于从有序集合中获取需发送的消息ID的集合；

获取模块，基于消息ID的集合获取消息体集合中的消息体并发送执行；

删除模块，用于删除有序集合和消息体集合中对应的记录。

通过采用上述技术方案，每个队列名称对应一个线程，便于队列名称对应的消息体的处理。选择模块将队列中的节点进行排序，通过领导者选举，获取其中的领导者并消费其中的领导者。采集模块中获取了消息ID，获取模块根据消息ID获取了消息体集合中的消息体并用来发送执行。删除模块删除了有序集合和消息体集合中对应的记录，从而完成了整个流程。

本发明的进一步设置为：有序集合中对应的记录删除后异步删除消息体集合中对应的记录。

通过采用上述技术方案，有序集合中的记录和消息体集合中的记录异步删除，减小整个系统发生混乱的概率。

本发明的进一步设置为：选择模块中同一个队列仅允许一个节点进行消费。

通过采用上述技术方案，选择模块仅执行一个节点，避免了资源竞争。

本发明的进一步设置为：消息队列基于Redis、Ignite、Hazelcast或数据库实现。

本发明的进一步设置为：消息生产端和消息消费端通过I/O适配器实现针对不同I/O方式的接入，支持Kafka、RabbitMQ、HTTP的集成。

本发明具有以下优点：

1、通过删除原有的延迟时间的时间戳并添加当前的延迟时间的时间戳，从而完成了延迟时间的更新，在中/高并发、分布式环境中实现了延迟消息的更新；

2、提升了系统性能；

3、减少了资源竞争。

附图说明

图1为处理系统的整体流程图。

具体实施方式

参照附图对本发明做进一步说明。

如图1所示：一种支持更新的分布式延迟消息队列处理系统，本系统包括消息队列、消息生产端、消息消费端。消息队列用来存储延迟消息，消息生产端用于向消息队列内加入延迟消息，消息消费端用于消费消息队列中的延迟消息。消息队列基于Redis、Ignite、Hazelcast或数据库实现，优选使用Redis。消息生产端和消息消费端通过I/O适配器实现针对不同I/O方式的接入，支持诸如Kafka、RabbitMQ、HTTP等主流方式的集成。

延迟消息包括队列名称、消息体、延迟发送的时间戳。队列名称携带有消息体的名称，每一个队列名称对应多个消息体，消息体携带有延迟消息需要执行的操作，延迟发送的时间戳携带有消息体延迟发送的时间。

消息生产端用于执行判断模块。消息队列中包含有队列名称集合、消息体集合、有序集合，其中，队列名称集合用于存储队列名称，消息体集合用于存储队列名称和消息体，有序集合用于存储队列名称和延迟发送的时间戳。消息体集合与有序集合中均存储有与队列名称对应的消息ID。

系统启动时，从Redis中加载（使用hkeys）队列名称集合加载至本地队列名称集合中，在后续获取队列名称时，直接从本地队列名称集合中获取队列名称，提升了后续操作的性能。

判断模块用于获取当前的延迟消息并判断消息队列中是否存在延迟消息。判断模块中通过判断本地队列名称集合中是否存在有与当前延迟消息对应的队列名称和消息体集合中是否存在有与当前延迟消息对应的消息体来判断消息队列中是否存在延迟消息。

判断模块判断过程主要包含以下步骤：

K1.判断本地队列名称集合中是否存在有与当前延迟消息对应的队列名称。当步骤K1判断否时，向队列名称集合中添加队列名称并向消息体集合中添加消息体。当步骤K1判断是时，则不执行向队列名称中添加队列名称的操作，之后向消息体集合中添加消息体。

K2.向消息体集合中添加消息体并判断消息体集合中是否存在有与当前延迟消息对应的消息体。向消息体集合中加入消息体后，消息体集合发出反馈消息，根据反馈消息即可判断消息体集合中是否存在有与延迟消息对应的消息体。在消息体集合中存在与延迟消息对应的消息体时，删除原有消息体从而完成了消息体的更新操作。

当步骤K1、K2同时为是时，判断模块判断是，反之，判断模块判断否。

若判断模块判断是，则删除消息队列中延迟发送的时间戳并向消息队列中添加当前延迟消息中携带的延迟发送的时间戳。

若判断模块判断是，则本地队列名称集合中存储有与延迟消息对应的队列名称，消息体集合中存储有与延迟消息对应的消息体，有序集合中存储有与队列名称对应的延迟发送的时间戳。判断模块具体执行以下步骤：

S1.删除有序集合中存储的与队列名称对应的延迟发送的时间戳；

S2.获取当前延迟消息的延迟发送的时间戳；

S3.添加步骤2中获取的延迟发送的时间戳至有序集合中。

通过删除有序集合中的延迟发送的时间戳，并添加当前的延迟消息的延迟发送的时间戳，从而完成了延迟消息的延迟发送的时间戳的更新。在延迟发送的时间戳的更新的过程中，只需删除有序集合中的延迟发送的时间戳和添加有序集合中延迟发送的时间戳即可完成整个流程。

若判断模块判断否，则向消息队列中的有序集合中添加延迟消息的时间戳。在向有序集合中添加延迟消息时，在有序集合与消息体集合中生成与消息体对应的消息ID。

消息消费端用于执行准备模块、选择模块、采集模块、获取模块、删除模块。

准备模块用于从本地队列名称集合中获取要消费的队列集合并为每一个队列启动一个新线程。

Redis是单线程来处理命令的，每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个队列中，然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行，不会产生并发问题，这就是Redis的单线程基本模型。

Redis中，数据存放在内存中，内存的响应时间大约是100纳秒，这是Redis每秒万亿级别访问的重要基础。Redis采用epoll做为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了时间，不在I/O上浪费过多的时间。单线程避免了线程切换和竞态产生的消耗。

选择模块用于将队列中的节点排序后获取要消费的节点。选择模块中同一个队列仅允许一个节点进行消费。将队列中的节点进行排序，通过领导者选举，获取其中的领导者并消费其中的一个节点，避免了资源竞争。

采集模块用于从有序集合中获取需发送的消息ID的集合。需发送的消息ID的集合均需满足延迟时间戳小于等于当前时间，多个需发送的消息ID组合形成了需发送的消息ID的集合。

获取模块基于消息ID的集合获取消息体集合中的消息体并发送执行。采集模块中仅获取了消息ID，获取模块获取了消息体集合中的消息体并用来发送执行。

删除模块用于删除有序集合和消息体集合中对应的记录。在获取模块中的消息体发送成功后，删除有序集合中对应的记录，之后异步删除消息体集合中对应的记录。有序集合中对应的记录删除后异步删除消息体集合中对应的记录。

以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (9)

1.一种支持更新的分布式延迟消息队列处理系统，包括消息队列、用于向消息队列内加入延迟消息的消息生产端、用于消费消息队列中的延迟消息的消息消费端，其特征是：延迟消息包括队列名称、消息体、延迟发送的时间戳；消息生产端用于执行以下模块，

判断模块，用于获取当前的延迟消息并判断消息队列中是否存在延迟消息；

若是，则删除消息队列中延迟发送的时间戳并向消息队列中添加当前延迟消息中携带的延迟发送的时间戳；

若否，则向消息队列中添加延迟消息。

2.根据权利要求1所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：消息队列中包含有队列名称集合、消息体集合、有序集合，其中，队列名称集合用于存储队列名称，消息体集合用于存储队列名称和消息体，有序集合用于存储队列名称和延迟发送的时间戳；

判断模块中通过判断队列名称集合中是否存在有与当前延迟消息对应的队列名称和消息体集合中是否存在有与当前延迟消息对应的消息体来判断消息队列中是否存在延迟消息。

3.根据权利要求2所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：消息体集合与有序集合中均存储有与队列名称对应的消息ID。

4.根据权利要求3所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：系统启动时，将队列名称集合加载至本地队列名称集合中。

5.根据权利要求4所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：消息消费端用于执行以下模块，

准备模块，用于从本地队列名称集合中获取要消费的队列集合并为每一个队列启动一个新线程；

选择模块，用于将队列中的节点排序后获取要消费的节点；

采集模块，用于从有序集合中获取需发送的消息ID的集合；

获取模块，基于消息ID的集合获取消息体集合中的消息体并发送执行；

删除模块，用于删除有序集合和消息体集合中对应的记录。

6.根据权利要求5所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：有序集合中对应的记录删除后异步删除消息体集合中对应的记录。

7.根据权利要求6所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：选择模块中同一个队列仅允许一个节点进行消费。

8.根据权利要求1-7任一所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：消息队列基于Redis、Ignite、Hazelcast或数据库实现。

9.根据权利要求1-7任一所述的一种支持更新的分布式延迟消息队列处理系统，其特征是：消息生产端和消息消费端通过I/O适配器实现针对不同I/O方式的接入，支持Kafka、RabbitMQ、HTTP的集成。