延时消息的消息投递系统的制作方法

1.本发明涉及计算机技术领域，具体提供一种延时消息的消息投递系统。


背景技术：

2.延时消息是指在被生产者生成之后在指定的投递延时时间投递给消费者，而并不是立即投递给消费者的消息。目前常规的延时消息的投递方法主要是利用rabbitmq（rabbit message queue）进行延时消息投递，该方法包括在rabbitmq中创建一个没有消费者的消息队列，生产者将延时消息及投递延时时间发送到rabbitmq中的消息队列，在时间达到投递延时时间后由于延时消息未被消费者消费而被转发到死信队列，消费者通过监听死信队列监听到相应的延时消息后对延时消息进行消费。然而，由于延时消息在到期后要先由rabbitmq转发至死信队列，再由消费者监听死信队列来消费延时消息，使得延时消息的投递会存在延迟，无法在投递延时时间准时地将延时消息投递至消费者。
3.相应地，本领域需要一种新的技术方案来解决上述问题。


技术实现要素：

4.为了克服上述缺陷，提出了本发明，以提供解决或至少部分地解决如何准时地对任意投递延时时间的延时消息进行投递的技术问题的延时消息的消息投递系统，所述系统包括数据库、延时消息处理集群、zookeeper集群和rocketmq集群；所述延时消息处理集群包括多个延时消息处理节点，所述延时消息处理节点包括数据预加载组件、数据变更监听组件和数据消费组件；所述数据预加载组件被配置成每隔预设时长从所述数据库中获取投递延时时间在未来一段时间内的延时消息并将所述延时消息发送至所述zookeeper集群，所述zookeeper集群被配置成在预设的延时节点下面对接收到的每个延时消息分别建立一个永久节点，其中，所述未来一段时间的时长至少是所述预设时长的2倍；所述数据变更监听组件被配置成在监听到所述预设的延时节点下面新建了一个永久节点时与其他延时消息处理节点一起竞争新建的永久节点的消费资格，并在竞争到所述消费资格时从所述新建的永久节点中获取延时消息，将所述延时消息存储至所述数据消费组件；所述数据消费组件被配置成对自身存储的延时消息的投递延时时间进行监测，在时间达到相应延时消息的投递延时时间后将所述延时消息发送至所述rocketmq集群进行信息投递。
5.在上述延时消息的消息投递系统的一个技术方案中，所述延时消息处理节点还包括接入组件，所述接入组件包括延时消息接收模块、第一延时消息处理模块和第二延时消息处理模块；所述延时消息接收模块被配置成接收消息生产者发送的延时消息，对所述延时消息的投递延时时间与所述预设时长进行比较；
所述第一延时消息处理模块被配置成在所述投递延时时间小于所述预设时长时将所述延时消息发送至所述zookeeper集群，将所述延时消息存储至所述数据库并将所述数据库中所述延时消息的消息状态设置成已投递；所述第二延时消息处理模块被配置成在所述投递延时时间大于等于所述预设时长时将所述延时消息存储至所述数据库并将所述数据库中所述延时消息的消息状态设置成未投递。
6.在上述延时消息的消息投递系统的一个技术方案中，所述数据变更监听组件包括消费资格竞争模块；所述消费资格竞争模块被配置成基于zookeeper的主从选举机制与其他延时消息处理节点一起竞选主节点，根据主节点的竞选结果确定是否竞争到所述新建的永久节点的消费资格；若竞选到主节点，则确定竞争到所述消费资格；若未竞选到主节点，则确定未竞争到所述消费资格。
7.在上述延时消息的消息投递系统的一个技术方案中，所述消费资格竞争模块被进一步配置成基于zookeeper的主从选举机制与其他延时消息处理节点一起在所述新建的永久节点下面竞争注册临时节点，根据当前延时消息处理节点注册的临时节点的节点顺序，确定当前延时消息处理节点是否竞选到主节点；若所述节点顺序是第一位，则确定竞选到所述主节点；若所述节点顺序不是第一位，则确定未竞选到所述主节点。
8.在上述延时消息的消息投递系统的一个技术方案中，所述延时消息处理节点还被配置成在监听到主节点发生异常后将自身注册的临时节点的节点顺序提前1位。
9.在上述延时消息的消息投递系统的一个技术方案中，所述数据变更监听组件还包括消费资格变更模块；所述消费资格变更模块被配置成在监听到当前延时消息处理节点的节点状态由从节点切换成主节点后将当前延时消息处理节点由未竞争到所述消费资格变更成竞争到所述消费资格。
10.在上述延时消息的消息投递系统的一个技术方案中，所述数据消费组件还被配置成通过数据消费线程监听位于所述数据消费组件的组件内存中能够处理延时消息的阻塞队列，从所述阻塞队列中获取延时消息。
11.在上述延时消息的消息投递系统的一个技术方案中，所述延时消息处理节点还包括消息投递组件；所述数据消费组件被进一步配置成在时间达到相应延时消息的投递延时时间后将所述延时消息发送至所述消息投递组件；所述消息投递组件被配置成将所述延时消息发送至所述rocketmq集群进行信息投递，删除所述zookeeper集群中所述延时消息对应的永久节点及将所述数据库中所述延时消息的消息状态由已投递修正成已处理。
12.在上述延时消息的消息投递系统的一个技术方案中，所述延时消息处理节点还包括数据清理组件，所述数据清理组件被配置成定时地删除所述数据库中消息状态为已处理的延时消息。
13.在上述延时消息的消息投递系统的一个技术方案中，所述延时消息处理节点还包括初始化组件；所述初始化组件被配置成在当前延时消息处理节点启动时与其他延时消息处理节点一起竞争所述zookeeper集群中预设的延时节点下面每个永久节点的消费资格。
14.本发明上述一个或多个技术方案，至少具有如下一种或多种有益效果：在实施本发明的技术方案中，延时消息的消息投递系统主要包括数据库、延时消息处理集群、zookeeper集群和rocketmq集群，其中，延时消息处理集群可以包括多个延时消息处理节点，每个延时消息处理节点均包括数据预加载组件、数据变更监听组件和数据消费组件。具体地，数据预加载组件可以被配置成每隔预设时长从数据库中获取投递延时时间在未来一段时间内的延时消息并将延时消息发送至zookeeper集群，zookeeper集群可以被配置成在预设的延时节点下面对接收到的每个延时消息分别建立一个永久节点。数据变更监听组件可以被配置成在监听到预设的延时节点下面新建了一个永久节点时与其他延时消息处理节点一起竞争新建的永久节点的消费资格，并在竞争到消费资格时从新建的永久节点中获取延时消息，将延时消息存储至数据消费组件。数据消费组件可以被配置成对自身存储的延时消息的投递延时时间进行监测，在时间达到相应延时消息的投递延时时间后将延时消息发送至rocketmq集群进行信息投递。
15.通过数据预加载组件每隔预设时长将投递延时时间在未来一段时间内的延时消息发送至zookeeper集群，可以使延时消息处理节点在投递延时时间之前提前获取到延时消息，进而可以在时间达到投递延时时间后及时地将延时消息发送至rocketmq集群进行信息投递，不会存在投递延迟。同时，通过每隔预设时长将投递延时时间在未来一段时间内的延时消息发送至zookeeper集群，可以实现对任意投递延时时间的延时消息进行投递。
附图说明
16.参照附图，本发明的公开内容将变得更易理解。本领域技术人员容易理解的是：这些附图仅仅用于说明的目的，而并非意在对本发明的保护范围组成限制。此外，图中类似的数字用以表示类似的部件，其中：图1是根据本发明的一个实施例的延时消息的消息投递系统的主要结构框图示意图；图2是根据本发明的一个实施例的zookeeper集群中预设的延时节点delay_node及其下面的永久节点msg的示意图；图3是根据本发明的另一个实施例的延时消息的消息投递系统的主要结构框图示意图。
17.附图标记列表：1：数据库；2：延时消息处理节点；21：数据预加载组件；22：数据变更监听组件；23：数据消费组件；24：消息投递组件；25：数据清理组件；26：初始化组件；27：接入组件；3：zookeeper集群；4：rocketmq集群。
具体实施方式
18.下面参照附图来描述本发明的一些实施方式。本领域技术人员应当理解的是，这
些实施方式仅仅用于解释本发明的技术原理，并非旨在限制本发明的保护范围。
19.在本发明的描述中，“模块”可以包括硬件、软件或者两者的组合。一个模块可以包括硬件电路，各种合适的感应器，通信端口，存储器，也可以包括软件部分，比如程序代码，也可以是软件和硬件的组合。此外，本领域技术人员能够理解的是，可以对系统中的各个模块进行适应性地拆分或合并。对具体模块的这种拆分或合并并不会导致技术方案偏离本发明的原理，因此，拆分或合并之后的技术方案都将落入本发明的保护范围内。
20.这里先解释本发明涉及到的一些术语。
21.zookeeper是计算机技术领域中的一种分布式应用程序协调服务软件，zookeeper集群是指由能够加载并运行zookeeper的计算机设备组成的集群（cluster）。
22.rocketmq（rocket message queue）是计算机技术领域中的一种基于java语言编写的分布式、队列模型的开源消息中间件，rocketmq集群是指由能够加载并运行rocketmq的计算机设备组成的集群（cluster）。
23.参阅附图1，图1是根据本发明的一个实施例的延时消息的消息投递系统的主要结构框图示意图。如图1所示，本发明实施例中的延时消息的消息投递系统主要包括数据库1、延时消息处理集群、zookeeper集群3和rocketmq集群4，延时消息处理集群可以包括多个延时消息处理节点2，其中，延时消息处理节点2分别与数据库1 、zookeeper集群3和rocketmq集群4通信连接，延时消息处理节点2可以包括数据预加载组件21、数据变更监听组件22和数据消费组件23。
24.数据库1可以是单个数据库，也可以是由多个数据库组成的数据库集群，数据库1可以被配置成存储延时消息及其投递延时时间等数据。例如，数据库1中存储的数据可以如下表1所示，其中，msgid表示延时消息message的编号id，msgtime表示延时消息message的投递延时时间，msgdata表示延时消息message的消息内容。
25.表1数据预加载组件21可以被配置成每隔预设时长从数据库1中获取投递延时时间在未来一段时间内的延时消息并将延时消息发送至zookeeper集群3，zookeeper集群3可以被配置成在预设的延时节点下面对接收到的每个延时消息分别建立一个永久节点（persistent），其中，所述未来一段时间的时长至少是预设时长的2倍。具体地，在本实施例中数据预加载组件21可以被配置成获取投递延时时间在以当前时刻为起点的未来一段时间内的延时消息，将获取到的延时消息发送至zookeeper集群3。本领域技术人员可以根据实际需求灵活设置定时获取延时消息的时间间隔以及上述未来一段时间的具体时长，本发明实施例对此不进行具体限定。此外，在本发明实施例中数据预加载组件21可以被配置成
从数据库1中获取消息状态为未投递的延时消息，将这些未投递的延时消息发送至zookeeper集群3，而不再获取已投递的延时消息。
26.在一些优选实施方式中，可以将每隔预设时长获取延时消息的预设时长设置成1分钟，将上述未来一段时间设置成3分钟。例如，假设当前时刻是2022年1月01日的08：00，在当前时刻可以将投递延时时间在08:00至08:03这段时间内的延时消息发送至zookeeper集群3，在08:01可以将投递延时时间在08:01至08:04这段时间内的延时消息发送至zookeeper集群3，在08:02可以将投递延时时间在08:02至08:05这段时间内的延时消息发送至zookeeper集群3。
27.参阅附图2，图2是本发明实施例中zookeeper集群中预设的延时节点delay_node及其下面三个永久节点msg的示意图。如图2所示，zookeeper集群在接收到数据预加载组件21发送的第一个延时消息message1之后，可以在预设的延时节点delay_node下面为第一个延时消息message1建立一个永久节点msg1。类似地，zookeeper集群还可以在预设的延时节点delay_node下面为第二个延时消息message2和第三个延时消息message3分别建立一个永久节点msg2和永久节点msg3。
28.需要说明的是，在本发明实施例可以采用zookeeper中常规的永久节点建立方法为延时消息message建立永久节点，本发明实施例不对永久节点的建立方法进行赘述。
29.数据变更监听组件22可以被配置成在监听到zookeeper集群中预设的延时节点下面新建了一个永久节点时与其他延时消息处理节点一起竞争新建的永久节点的消费资格，并在竞争到消费资格时从新建的永久节点中获取延时消息，将延时消息存储至数据消费组件。继续参阅附图2，假设延时消息处理集群包括两个延时消息处理节点server1和server2，当zookeeper集群为第一个延时消息message1建立永久节点msg1之后，延时消息处理节点server1和server2会同时竞争永久节点msg1的消费资格。
30.数据消费组件23可以被配置成对自身存储的延时消息的投递延时时间进行监测，在时间达到相应延时消息的投递延时时间后将延时消息发送至rocketmq集群进行信息投递。在本发明实施例中可以采用rocketmq的常规信息投递方法对延时消息进行信息投递，本发明实施例不对通过rocketmq进行信息投递的方法作具体限定。
31.通过数据预加载组件21每隔预设时长将投递延时时间在未来一段时间内的延时消息发送至zookeeper集群3，可以使延时消息处理节点2在投递延时时间之前提前获取到延时消息，进而可以在时间达到投递延时时间后及时地将延时消息发送至rocketmq集群4进行信息投递，不会存在投递延迟。同时，通过每隔预设时长将投递延时时间在未来一段时间内的延时消息发送至zookeeper集群3，可以实现对任意投递延时时间的延时消息进行投递。此外，在本发明实施例中还可以通过增加延时消息处理节点的数量和/或提高单个延时消息处理节点处理的内存（memory）总量，来提高整个消息投递系统在上述未来一段时间内的延时消息处理总量，延时消息处理总量可以根据单个延时消息处理节点处理的内存总量与延时消息处理节点的数量的乘积来确定，本领域技术人员可以根据实际需求灵活地调整消息处理节点的数量和/或单个延时消息处理节点处理的内存总量。
32.数据库1存储了全量的未投递延时消息，zookeeper集群3存储了未来一段时间内全量的未投递延时消息，每个延时消息处理节点2分别存储了未来一段时间内一部分的未投递延时消息，通过数据库1、zookeeper集群3和延时消息处理节点2形成了漏斗式的消息
投递结构，能够支持更高并发量的延时消息。此外，通过消息投递系统可以对延时消息实现从接收到投递的全程跟踪，提高了延时消息的投递可靠性，不会发生漏发的情况。
33.下面结合附图3对延时消息处理节点作进一步说明。
34.一、数据消费组件在本发明实施例的一些实施方式中数据消费组件23可以被配置成通过数据消费线程（thread）监听位于数据消费组件的组件内存中能够处理延时消息的阻塞队列（blocking queue），从阻塞队列中获取延时消息。
35.具体地，阻塞队列用于存储延时消息处理节点2从zookeeper集群3获取到的延时消息，当阻塞队列不为空时数据消费线程会从阻塞队列中获取延时消息，当阻塞队列为空时数据消费线程会进行等待，等到阻塞队列不为空时再从阻塞队列中获取延时消息。通过这种方式，可以保证在时间达到数据消费组件23自身存储的延时消息对应的投递延时时间时可以及时地将延时消息发送至rocketmq集群4进行信息投递。在一些实施方式中可以采用delay queue或hashed wheel timer构建能够处理延时消息的阻塞队列，此外本领域技术人员也以采用其他方式构建阻塞队列，只要能够使数据消费组件可以通过数据消费线程监听位于数据消费组件的组件内存中的阻塞队列，从阻塞队列中获取延时消息即可。
36.进一步，在一些实施方式中，如图3所示，延时消息处理节点2还可以包括消息投递组件24。在本实施方式中，数据消费组件23可以被进一步配置成在时间达到相应延时消息的投递延时时间后将延时消息发送至消息投递组件24，进而通过消息投递组件24将延时消息发送至rocketmq集群4进行信息投递。具体地，消息投递组件24可以被配置成将延时消息发送至rocketmq集群4进行信息投递，删除zookeeper集群3中延时消息对应的永久节点以及将数据库1中延时消息的消息状态由已投递修正成已处理。如图3所示，假设数据消费组件23将第一延时消息message1发送至消息投递组件24，消息投递组件24可以将第一延时消息message1发送至rocketmq集群4进行信息投递，删除永久节点msg1以及将数据库1中第一延时消息message1的消息状态修正成已处理。通过这种方式，不仅可以实现延时消息的及时投递，还可以同时减少zookeeper集群3的数据存储量，以便于更好地对其他延时消息进行投递。
37.此外，在一些实施方式中，延时消息处理节点2除了可以包括上述数据消费组件23和消息投递组件24以外，还可以包括数据清理组件25。在本实施方式中数据清理组件25可以被配置成定时地删除数据库1中消息状态为已处理的延时消息，使得数据库1能够释放更多地存储空间来存储未投递的延时消息。
38.二、数据变更监听组件在本发明实施例的一些实施方式中数据变更监听组件22可以包括消费资格竞争模块，在本实施方式中消费资格竞争模块可以被配置成基于zookeeper的主从选举机制与其他延时消息处理节点一起竞选主节点，根据主节点的竞选结果确定是否竞争到新建的永久节点的消费资格。具体地，若当前延时消息处理节点竞选到主节点，那么可以确定当前延时消息处理节点同样竞争到了消费资格；若当前延时消息处理节点没有竞选到主节点，那么可以确定当前延时消息处理节点没有竞争到消费资格。其中，zookeeper的主从选举机制是zookeeper中常规的主节点和从节点的选举机制，本发明对此不进行具体限定。此外，如果当前延时消息处理节点竞选到主节点，那么当前延时消息处理节点的节点状态就是主节
点；如果当前延时消息处理节点没有竞选到主节点，那么当前延时消息处理节点的节点状态就是从节点。
39.通过多个延时消息处理节点竞争永久节点的消费资格，可以使延时消息处理集群具备较高的高可用性，进而提高延时消息的投递可靠性。为了进一步提高延时消息的投递可靠性，在一些实施方式中数据变更监听组件22还可以包括消费资格变更模块。在本实施方式中，消费资格变更模块可以被配置成在监听到当前延时消息处理节点的节点状态由从节点切换成主节点后将当前延时消息处理节点由未竞争到消费资格变更成竞争到消费资格，从而能够正常地将相应永久节点中的延时消息发送至数据消费组件23。
40.进一步，在一些优选实施方式中，延时消息处理节点可以通过注册临时节点的方式来竞选主节点。具体而言，消费资格竞争模块可以被进一步配置成基于zookeeper的主从选举机制与其他延时消息处理节点一起在新建的永久节点下面竞争注册临时节点，根据当前延时消息处理节点注册的临时节点的节点顺序，确定当前延时消息处理节点是否竞选到主节点。如果节点顺序是第一位，则确定当前延时消息处理节点竞选到了主节点；如果节点顺序不是第一位，则确定当前延时消息处理节点没有竞选到主节点。如图2所示，在第一延时消息message1的永久节点msg1下面，第一延时消息处理节点和第二延时消息处理节点分别注册了一个临时节点server1和server2，由于临时节点server1的节点顺序是第一位，临时节点server2的节点顺序是第二位，因而可以确定第一延时消息处理节点竞选到了永久节点msg1的主节点，其具备永久节点msg1的消费资格。
41.为了进一步提高延时消息的投递可靠性，在一些实施方式中延时消息处理节点还可以被配置成在监听到主节点发生异常后将自身注册的临时节点的节点顺序提前1位，这样使得节点顺序位为第二位的从节点可以自动地变成主节点，从而能够正常地将相应永久节点中的延时消息发送至数据消费组件23。
42.通过上述介绍可知，数据变更监听组件22可以在消息投递系统启动后对zookeeper集群中的永久节点进行监听，保证在通过消息投递系统进行延时消息投递的过程中能够及时准确地将延时消息发送至数据消费组件。而在一些实施方式中，在消息投递系统启动的过程中特别是在延时消息处理节点启动时还可以通过初始化组件26对延时消息处理节点的消费资格进行初始化。具体地，初始化组件26可以被配置成在当前延时消息处理节点启动时与其他延时消息处理节点一起竞争zookeeper集群中预设的延时节点下面每个永久节点的消费资格。其中，竞选永久节点的消费资格的方法与前述系统实施例中的相关方法相同，在此不再进行赘述。在通过初始化组件对延时消息处理节点的消费资格进行初始化之后，延时消息处理节点也会根据各自拥有的消费资格将相应永久节点中的延时消息发送至数据消费组件23。此外，初始化组件26除了可以对延时消息处理节点的消费资格进行初始化，还可以对消息投递系统中其他组件的组件参数进行初始化，本领域技术人员可以根据实际需求灵活设置需要进行初始化的组件参数，本发明实施例对此不作具体限定。
43.在本发明实施例中延时消息处理节点启动包括但不限于系统上电后的首次启动和重启动如由于发生故障导致的重启动。
44.三、接入组件参阅附图3，在本发明实施例的一些实施方式中，延时消息处理节点2还可以包括
接入组件27，在本实施方式中接入组件27可以包括延时消息接收模块、第一延时消息处理模块和第二延时消息处理模块。具体地，延时消息接收模块可以被配置成接收消息生产者发送的延时消息，对延时消息的投递延时时间与预设时长进行比较。第一延时消息处理模块可以被配置成在投递延时时间小于预设时长时将延时消息发送至zookeeper集群3，将延时消息存储至数据库1并将数据库1中延时消息的消息状态设置成已投递。第二延时消息处理模块可以被配置成在投递延时时间大于等于预设时长时将延时消息存储至数据库1并将数据库1中延时消息的消息状态设置成未投递。
45.投递延时时间小于预设时长，表明时间即将达到投递延时时间，因而为了保证能够在投递延时时间及时地进行信息投递，此时可以将延时消息直接发送至zookeeper集群3。而投递延时时间大于等于预设时长，表明距离投递延时时间还有一段时间，不着急进行信息投递，因而可以按照正常的信息投递流程，将延时消息先存储至数据库1，再由数据预加载组件21从数据库1中将延时消息发送至zookeeper集群3。此外，在一些优选实施方式中，为了减轻数据传输的压力，接入组件27可以被配置成采用异步发送的方式，先将延时消息发送至zookeeper集群3，再将延时消息发送至数据库1。
46.需要说明的是，在本发明实施例中预设时长与前述方法实施例中数据预加载组件21每隔预设时长从数据库1中获取投递延时时间在未来一段时间内的延时消息并将延时消息发送至zookeeper集群3中采用的预设时长相同。如图2所示，接入组件27会将投递延时时间为30s的延时消息分别发送至zookeeper集群3和数据库1，接入组件27会将投递延时时间为1min、2min和5min的延时消息发送至zookeeper集群3。
47.至此，已经结合附图所示的优选实施方式描述了本发明的技术方案，但是，本领域技术人员容易理解的是，本发明的保护范围显然不局限于这些具体实施方式。在不偏离本发明的原理的前提下，本领域技术人员可以对相关技术特征作出等同的更改或替换，这些更改或替换之后的技术方案都将落入本发明的保护范围之内。