CN109714409A - 一种消息的管理方法和系统 - Google Patents

一种消息的管理方法和系统 Download PDF

Info

Publication number
CN109714409A
CN109714409A CN201811573289.0A CN201811573289A CN109714409A CN 109714409 A CN109714409 A CN 109714409A CN 201811573289 A CN201811573289 A CN 201811573289A CN 109714409 A CN109714409 A CN 109714409A
Authority
CN
China
Prior art keywords
message
queue
queue server
server
transmitting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811573289.0A
Other languages
English (en)
Other versions
CN109714409B (zh
Inventor
刘刚
邓伟伟
崔阳
巩仔明
邱慧
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mdt Infotech Ltd (shanghai) Mdt Infotech Ltd
Original Assignee
Mdt Infotech Ltd (shanghai) Mdt Infotech Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mdt Infotech Ltd (shanghai) Mdt Infotech Ltd filed Critical Mdt Infotech Ltd (shanghai) Mdt Infotech Ltd
Priority to CN201811573289.0A priority Critical patent/CN109714409B/zh
Publication of CN109714409A publication Critical patent/CN109714409A/zh
Application granted granted Critical
Publication of CN109714409B publication Critical patent/CN109714409B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明公开了一种消息的管理方法和系统,属于计算机技术领域。所述方法包括:消息管理后台接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器;所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;如果所述目标队列服务器检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。采用本发明,可以解决消息积压问题,提高消息管理质量。

Description

一种消息的管理方法和系统
技术领域
本发明涉及计算机技术领域,特别涉及一种消息的管理方法和系统。
背景技术
随着互联网的飞速发展,不同业务场景下的消息,如交易类消息、注册类消息,呈爆发式增长,相应的,消息的管理也愈加重要。
以某网站接收用户的注册消息为例,当某用户想要注册某网站时,首先,该用户可以在任意终端打开该网站的注册页面,之后,该用户可以在该网站的注册页面填写注册信息并点击提交按钮。这样,该网站的对外服务器(可称为消息发送端)可以接收到上述用户提交的注册消息,然后可以将注册消息发送给相应的注册服务器(可称为消息接收端)。之后,注册服务器可以基于该注册消息进行该用户的注册操作,并在注册操作完成后向上述对外服务器反馈相应的注册结果信息。进而,对外服务器可以将注册结果信息返回给用户,完成此次注册操作。
在实现本发明的过程中,发明人发现现有技术至少存在以下问题:
消息发送端只是简单的向消息接收端传递消息,如果消息接收端处理消息时出现异常,将无法及时处理消息发送端传递的消息,造成消息堆积严重,故而消息管理的质量较差。
发明内容
为了解决现有技术的问题,本发明实施例提供了一种消息的管理方法和系统。所述技术方案如下:
第一方面,提供了一种消息的管理方法,所述方法包括:
消息管理后台接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器;
所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;
如果所述目标队列服务器检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。
进一步的,所述在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器,包括:
所述消息管理后台计算所述队列对应的各个队列服务器的负载度,将所述负载度最低的队列服务器确定为传递所述消息的目标队列服务器。
进一步的,所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,包括:
所述目标队列服务器从所述队列中获取所述消息,并基于由所述消息管理后台推送的预设配置文件,在所述目标队列服务器的多个进程中确定传递所述消息的目标进程,其中,所述预设配置文件至少包括进程数量及回调地址;
所述目标进程基于所述回调地址将所述消息传递至消息接收端。
进一步的,所述按照预设重发机制对所述消息进行重新传递,包括:
所述目标队列服务器每隔预设周期,对所述消息进行重新传递;
如果所述目标队列服务器对所述消息进行重新传递的次数超过预设次数,则停止对所述消息进行重新传递,并按照预设通信方式向管理员发送对所述消息的告警信息。
进一步的,所述方法还包括:
如果所述消息管理后台接收到修改命令,则将基于所述修改命令更新的预设配置文件推送至各个队列服务器;
各个所述队列服务器的进程管理器基于更新后的预设配置文件进行进程配置。
第二方面,提供了一种消息的管理系统,所述系统包括消息管理后台和消息队列集群,所述消息队列集群包括至少一个队列服务器,其中:
所述消息管理后台,用于接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个所述队列服务器中确定传递所述消息的目标队列服务器;
所述目标队列服务器,用于从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;
所述目标队列服务器,还用于如果检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。
进一步的,所述消息管理后台,还用于:
计算所述队列对应的各个队列服务器的负载度,将所述负载度最低的队列服务器确定为传递所述消息的目标队列服务器。
进一步的,所述目标队列服务器包括多个进程;
所述目标队列服务器,还用于从所述队列中获取所述消息,并基于由所述消息管理后台推送的预设配置文件,在所述目标队列服务器的多个进程中确定传递所述消息的目标进程,其中,所述预设配置文件至少包括进程数量及回调地址;
所述目标进程,用于基于所述回调地址将所述消息传递至消息接收端。
进一步的,所述目标队列服务器,还用于:
每隔预设周期,对所述消息进行重新传递;
如果对所述消息进行重新传递的次数超过预设次数,则停止对所述消息进行重新传递,并按照预设通信方式向管理员发送对所述消息的告警信息。
进一步的,所述队列服务器还包括进程管理器;
所述消息管理后台,还用于如果接收到修改命令,则将基于所述修改命令更新的预设配置文件推送至各个队列服务器;
所述进程管理器,用于基于更新后的预设配置文件进行进程配置。
本发明实施例提供的技术方案带来的有益效果是:
在本实施例中,消息管理后台接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器;所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;如果所述目标队列服务器检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。这样,通过消息管理后台,可以在消息传递失败后,将消息进行落地存储,解决了消息积压的问题,并且,消息管理后台可以可视化的对传递成功或传递失败的消息进行呈现,便于相关人员进行查看,同时还可以对消息的发送数量进行量化。另外,还提供了一种消息传递失败后重新传递的机制,实现了对消息的重新传递,并可以在重新传递次数超过预设次数后,向管理员发送对传递失败消息的告警信息。进一步的,消息管理后台可以分布式地将单个队列的多个进程部署到多台队列服务器,从而可以减轻每个队列服务器的负载,并且,当传递消息的进程崩溃时,队列服务器的进程管理器可以将该消息传递给其他正常运行的进程,以继续传递该消息,有效保证了系统的高可用性。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1是本发明实施例提供的一种消息的管理方法流程图;
图2是本发明实施例提供的一种消息的管理系统结构示意图;
图3是本发明实施例提供的一种服务器的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
本发明实施例提供了一种消息的管理方法,该方法的执行主体可以是由消息管理后台和消息队列集群组成的系统,该系统可以作为消息发送端和消息接收端之间的中间件,其中,消息管理后台可以是一台消息管理服务器,也可以是由多台消息管理服务器组成的管理集群,其可以从消息发送端处获取待传递的消息,并可以将该消息分配至消息队列集群中相应的队列服务器,以使该队列服务器将消息传递至消息接收端。上述服务器可以包括处理器、存储器、收发器,处理器可以用于进行下述流程中对于消息的管理处理,存储器可以用于存储处理过程中需要的数据以及产生的数据,收发器可以用于接收和发送处理过程中的相关数据。
下面将结合具体实施方式,对图1所示的一种消息的管理方法的处理流程进行详细的说明,内容可以如下:
步骤101,消息管理后台接收消息发送端发送的消息,将消息存储在消息对应的队列中,并在队列对应的至少一个队列服务器中确定传递消息的目标队列服务器。
在实施中,消息管理后台可以对外提供数据接口,该数据接口可以作为消息的流入通道。同时,消息管理后台可以对队列进行管理,如创建队列、删除队列、创建交换机并绑定队列等。以创建队列为例,消息管理后台可以基于不同的业务场景,创建各个业务场景所对应的队列,每个队列可以存储来自对应业务场景下的消息,如交易队列可以存储交易类消息,注册队列可以存储注册类消息。另外,每个队列可以对应有多个队列服务器,这些队列服务器用于将队列中的消息传递给消息接收端。这样,当消息发送端想要向消息接收端传递消息时,可以通过上述数据接口,将待传递的消息发送至消息管理后台。之后,消息管理后台可以接收到由消息发送端发送的消息,然后可以判断出该消息的业务场景,从而可以将该消息存储在所属业务场景所对应的队列中。接着,消息管理后台可以随机或者按照设定规则,在队列对应的至少一个队列服务器中,确定出具体传递消息的队列服务器(可称为目标队列服务器)。
可选的,消息管理后台可以基于负载情况确定目标队列服务器,相应的,步骤101的部分处理可以如下:消息管理后台计算队列对应的各个队列服务器的负载度,将负载度最低的队列服务器确定为传递消息的目标队列服务器。
在实施中,实际传递消息的是队列服务器的进程,且一个队列中的消息可以由多个进程负责传递,当进程数量较多时,队列中消息被传递的效率也较高。这样,消息管理后台可以分布式地将单个队列的多个进程部署到多台队列服务器,从而可以减轻每个队列服务器的负载。进一步的,消息管理后台可以计算某队列对应的各个队列服务器的负载度,负载度可以用于衡量队列服务器的负载情况,队列服务器的负载度越低,表明该队列服务器的负载越轻。负载度可以基于队列服务器的中央处理器的使用率、内存使用率、IO情况等进程计算。这样,消息管理后台在将上述消息存储在消息对应的队列中后,可以将负载度最低的队列服务器确定为传递消息的目标队列服务器。
步骤102,目标队列服务器从队列中获取消息,将消息传递至消息接收端,并指示消息管理后台将消息从队列中删除。
在实施中,在消息管理后台确定出目标队列服务器后,目标队列服务器可以从存储上述消息的队列中获取该消息,然后可以指示消息管理后台将消息从队列中删除,以减少消息的堆积。之后,目标队列服务器可以基于消息中携带的相关信息,将消息传递至消息接收端。同时,目标队列服务器可以对消息的传递状态进行检测。具体的,如果消息传递成功,目标队列服务器可以接收到由消息接收端反馈的传递成功标志,如成功状态码;如果消息传递失败,如消息不完整或由于网络抖动导致消息未传递至消息接收端,则目标队列服务器可以接收到由消息接收端或相应网络设备反馈的传递失败标志,如失败状态码。
可选的,上述步骤102的处理可以如下:目标队列服务器从队列中获取消息,并基于由消息管理后台推送的预设配置文件,在目标队列服务器的多个进程中确定传递消息的目标进程,其中,预设配置文件至少包括进程数量及回调地址;目标进程基于回调地址将消息传递至消息接收端。
在实施中,消息管理平台可以预先生成预设配置文件,预设配置文件可以记录有各个队列所对应的进程数量、相应的回调地址或者消息传递异常时接收告警信息的管理员邮箱地址。之后,消息管理平台可以将预设配置文件发送至各个队列服务器。具体的,每个队列服务器可以部署服务注册通知节点,如Consul,以感知配置文件的变更,当服务注册通知节点感知到配置文件发送变更时,服务注册通知节点可以通知队列服务器去消息管理平台处获取预设配置文件。这样,目标队列服务器从队列中获取消息,并基于由消息管理后台生成的预设配置文件,在目标队列服务器的多个进程中确定传递消息的目标进程,之后,目标进程可以基于回调地址,向该回调地址进行POST请求,从而可以将消息传递至消息接收端。
需要说明的是,如果传递上述消息的目标进程崩溃,目标队列服务器的进程管理器可以将该消息传递给其他正常运行的进程,以继续传递该消息,有效保证了系统的高可用性。
步骤103,如果目标队列服务器检测到消息传递失败,则将消息进行落地存储,并按照预设重发机制对消息进行重新传递。
在实施中,可以为目标队列服务器配置相应的存储模块,如数据库。这样,如果目标队列服务器检测到消息传递失败,则可以将该消息进行落地存储,如存储在本地的数据库。具体的,当消息量巨大时,可以对落地归档的介质,如MySQL,进行按时段分表操作,如按周或月进行分表,用于后续的消息查询。进一步的,对于落地归档的历史消息,如果不再具备任何数据价值,可以考虑将这些历史消息转移到备份库中,不再提供查询功能。在将上述消息进程落地存储后,目标队列服务器可以按照预设重发机制,对消息重新进行传递。
需要说明的是,对于某些情形,如不需要冗余机制或者消息重要性较低时,也可以设置不对传递失败的消息进行重新传递,这时只需要在该消息落地归档后不再进行任何操作即可。
可选的,上述按照预设重发机制对消息进行重新传递的处理可以如下:目标队列服务器每隔预设周期,对消息进行重新传递;如果目标队列服务器对消息进行重新传递的次数超过预设次数,则停止对消息进行重新传递,并按照预设通信方式向管理员发送对消息的告警信息。
在实施中,可以预先对消息重新传递的频率进行配置,如每隔30秒或1分钟进行重新传递。这样,目标队列服务器可以每隔预设周期,对消息进行重新传递,从而可以提高消息传递的成功率。进一步的,对于多次重新传递仍传递失败的消息,可以对重新传递次数的上限进行设置,如10次或15次,当对消息进行重新传递的次数超过预设次数时,可以停止对消息进行重新传递,以节省系统资源,同时可以按照预设通信方式,如上述配置文件中的管理员邮箱地址,向管理员发送对该传递失败消息的告警信息。
可选的,还可以对消息的传递状态进行记录,相应的处理可以如下:如果目标队列服务器检测到消息传递失败,则将记录有消息传递失败的信息反馈至消息管理后台,以使消息管理后台标记消息的传递状态为失败;如果目标队列服务器检测到消息传递成功,则将记录有消息传递成功的信息反馈至消息管理后台,以使消息管理后台标记消息的传递状态为成功。
在实施中,消息管理后台可以基于队列服务器的反馈信息,记录每条消息的传递状态,即传递成功或传递失败。同时,消息管理后台可以对消息的总传递量进行实时统计,以量化消息的发送量。具体的,如果目标队列服务器检测到消息传递失败,则可以生成消息传递失败的信息,并可以将该信息反馈至消息管理后台,以使消息管理后台在接收到该消息传递失败的信息后,可以标记该消息的传递状态为失败。如果目标队列服务器检测到消息传递成功,则可以生成消息传递成功的信息,并可以将该信息反馈至消息管理后台,以使消息管理后台在接收到该消息传递成功的信息后,可以标记该消息的传递状态为成功。从而,消息管理后台可以可视化的对传递成功或传递失败的消息进行呈现,便于相关人员进行查看。
可选的,管理员还可以登录消息管理后台进行各项编辑操作,相应的处理可以如下:如果消息管理后台接收到修改命令,则将基于修改命令更新的预设配置文件推送至各个队列服务器;各个队列服务器的进程管理器基于更新后的预设配置文件进行进程配置。
在实施中,管理员可以登录消息管理后台,打开各个队列,查看各个队列对应的业务场景以及各个队列的相关信息,如队列的进程数、回调地址等信息,同时,可以对各个队列进行编辑,如增加队列所对应的进程数,修改回调地址等。这时,消息管理后台可以接收到管理员输入的修改命令,基于修改命令对预设配置文件进行更新,之后,消息管理后台可以将更新的预设配置文件推送至各个队列服务器。接着,各个队列服务器的进程管理器可以基于更新后的预设配置文件进行进程配置,重启队列下的所有进程,以将最新的配置加载到内存中常驻运行。
在本实施例中,消息管理后台接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器;所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;如果所述目标队列服务器检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。这样,通过消息管理后台,可以在消息传递失败后,将消息进行落地存储,解决了消息积压的问题,并且,消息管理后台可以可视化的对传递成功或传递失败的消息进行呈现,便于相关人员进行查看,同时还可以对消息的发送数量进行量化。另外,还提供了一种消息传递失败后重新传递的机制,实现了对消息的重新传递,并可以在重新传递次数超过预设次数后,向管理员发送对传递失败消息的告警信息。进一步的,消息管理后台可以分布式地将单个队列的多个进程部署到多台队列服务器,从而可以减轻每个队列服务器的负载,并且,当传递消息的进程崩溃时,队列服务器的进程管理器可以将该消息传递给其他正常运行的进程,以继续传递该消息,有效保证了系统的高可用性。
基于相同的技术构思,本发明实施例还提供了一种消息的管理系统,如图2所示,所述系统包括消息管理后台21和消息队列集群22,所述消息队列集群包括至少一个队列服务器221,其中:
所述消息管理后台21,用于接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个所述队列服务器221中确定传递所述消息的目标队列服务器221;
所述目标队列服务器221,用于从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台21将所述消息从所述队列中删除;
所述目标队列服务器221,还用于如果检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。
可选的,所述消息管理后台21,还用于:
计算所述队列对应的各个队列服务器221的负载度,将所述负载度最低的队列服务器221确定为传递所述消息的目标队列服务器221。
可选的,所述目标队列服务器221包括多个进程;
所述目标队列服务器221,还用于从所述队列中获取所述消息,并基于由所述消息管理后台21推送的预设配置文件,在所述目标队列服务器221的多个进程中确定传递所述消息的目标进程,其中,所述预设配置文件至少包括进程数量及回调地址;
所述目标进程,用于基于所述回调地址将所述消息传递至消息接收端。
可选的,所述目标队列服务器221,还用于:
每隔预设周期,对所述消息进行重新传递;
如果对所述消息进行重新传递的次数超过预设次数,则停止对所述消息进行重新传递,并按照预设通信方式向管理员发送对所述消息的告警信息。
可选的,所述队列服务器221还包括进程管理器;
所述消息管理后台21,还用于如果接收到修改命令,则将基于所述修改命令更新的预设配置文件推送至各个队列服务器221;
所述进程管理器,用于基于更新后的预设配置文件进行进程配置。
在本实施例中,消息管理后台接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器;所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;如果所述目标队列服务器检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。这样,通过消息管理后台,可以在消息传递失败后,将消息进行落地存储,解决了消息积压的问题,并且,消息管理后台可以可视化的对传递成功或传递失败的消息进行呈现,便于相关人员进行查看,同时还可以对消息的发送数量进行量化。另外,还提供了一种消息传递失败后重新传递的机制,实现了对消息的重新传递,并可以在重新传递次数超过预设次数后,向管理员发送对传递失败消息的告警信息。进一步的,消息管理后台可以分布式地将单个队列的多个进程部署到多台队列服务器,从而可以减轻每个队列服务器的负载,并且,当传递消息的进程崩溃时,队列服务器的进程管理器可以将该消息传递给其他正常运行的进程,以继续传递该消息,有效保证了系统的高可用性。
图3是本发明实施例提供的消息管理服务器或队列服务器的服务器结构示意图。该服务器300可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上中央处理器322(例如,一个或一个以上处理器)和存储器332,一个或一个以上存储应用程序342或数据344的存储介质330(例如一个或一个以上海量存储设备)。其中,存储器332和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上模块(图示没标出),每个模块可以包括对服务器中的一系列指令操作。更进一步地,中央处理器322可以设置为与存储介质330通信,在服务器300上执行存储介质330中的一系列指令操作。
服务器300还可以包括一个或一个以上电源326,一个或一个以上有线或无线网络接口350,一个或一个以上输入输出接口358,一个或一个以上键盘356,和/或,一个或一个以上操作系统341,例如Windows Server TM,Mac OS XTM,Unix TM,Linux TM,FreeBSD TM等等。
服务器300可以包括有存储器,以及一个或者一个以上的程序,其中一个或者一个以上程序存储于存储器中,且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行上述消息的管理的指令。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (10)

1.一种消息的管理方法,其特征在于,所述方法包括:
消息管理后台接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器;
所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;
如果所述目标队列服务器检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。
2.根据权利要求1所述的方法,其特征在于,所述在所述队列对应的至少一个队列服务器中确定传递所述消息的目标队列服务器,包括:
所述消息管理后台计算所述队列对应的各个队列服务器的负载度,将所述负载度最低的队列服务器确定为传递所述消息的目标队列服务器。
3.根据权利要求1所述的方法,其特征在于,所述目标队列服务器从所述队列中获取所述消息,将所述消息传递至消息接收端,包括:
所述目标队列服务器从所述队列中获取所述消息,并基于由所述消息管理后台推送的预设配置文件,在所述目标队列服务器的多个进程中确定传递所述消息的目标进程,其中,所述预设配置文件至少包括进程数量及回调地址;
所述目标进程基于所述回调地址将所述消息传递至消息接收端。
4.根据权利要求1所述的方法,其特征在于,所述按照预设重发机制对所述消息进行重新传递,包括:
所述目标队列服务器每隔预设周期,对所述消息进行重新传递;
如果所述目标队列服务器对所述消息进行重新传递的次数超过预设次数,则停止对所述消息进行重新传递,并按照预设通信方式向管理员发送对所述消息的告警信息。
5.根据权利要求1-4任一项所述的方法,其特征在于,所述方法还包括:
如果所述消息管理后台接收到修改命令,则将基于所述修改命令更新的预设配置文件推送至各个队列服务器;
各个所述队列服务器的进程管理器基于更新后的预设配置文件进行进程配置。
6.一种消息的管理系统,其特征在于,所述系统包括消息管理后台和消息队列集群,所述消息队列集群包括至少一个队列服务器,其中:
所述消息管理后台,用于接收消息发送端发送的消息,将所述消息存储在所述消息对应的队列中,并在所述队列对应的至少一个所述队列服务器中确定传递所述消息的目标队列服务器;
所述目标队列服务器,用于从所述队列中获取所述消息,将所述消息传递至消息接收端,并指示所述消息管理后台将所述消息从所述队列中删除;
所述目标队列服务器,还用于如果检测到所述消息传递失败,则将所述消息进行落地存储,并按照预设重发机制对所述消息进行重新传递。
7.根据权利要求6所述的系统,其特征在于,所述消息管理后台,还用于:
计算所述队列对应的各个队列服务器的负载度,将所述负载度最低的队列服务器确定为传递所述消息的目标队列服务器。
8.根据权利要求6所述的系统,其特征在于,所述目标队列服务器包括多个进程;
所述目标队列服务器,还用于从所述队列中获取所述消息,并基于由所述消息管理后台推送的预设配置文件,在所述目标队列服务器的多个进程中确定传递所述消息的目标进程,其中,所述预设配置文件至少包括进程数量及回调地址;
所述目标进程,用于基于所述回调地址将所述消息传递至消息接收端。
9.根据权利要求6所述的系统,其特征在于,所述目标队列服务器,还用于:
每隔预设周期,对所述消息进行重新传递;
如果对所述消息进行重新传递的次数超过预设次数,则停止对所述消息进行重新传递,并按照预设通信方式向管理员发送对所述消息的告警信息。
10.根据权利要求6-9任一项所述的系统,其特征在于,所述队列服务器还包括进程管理器;
所述消息管理后台,还用于如果接收到修改命令,则将基于所述修改命令更新的预设配置文件推送至各个队列服务器;
所述进程管理器,用于基于更新后的预设配置文件进行进程配置。
CN201811573289.0A 2018-12-21 2018-12-21 一种消息的管理方法和系统 Active CN109714409B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811573289.0A CN109714409B (zh) 2018-12-21 2018-12-21 一种消息的管理方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811573289.0A CN109714409B (zh) 2018-12-21 2018-12-21 一种消息的管理方法和系统

Publications (2)

Publication Number Publication Date
CN109714409A true CN109714409A (zh) 2019-05-03
CN109714409B CN109714409B (zh) 2021-09-14

Family

ID=66257153

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811573289.0A Active CN109714409B (zh) 2018-12-21 2018-12-21 一种消息的管理方法和系统

Country Status (1)

Country Link
CN (1) CN109714409B (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110213371A (zh) * 2019-05-31 2019-09-06 深圳前海微众银行股份有限公司 消息消费方法、装置、设备及计算机存储介质
CN110365772A (zh) * 2019-07-16 2019-10-22 中国农业银行股份有限公司 消息推送方法及装置
CN110719318A (zh) * 2019-09-06 2020-01-21 上海陆家嘴国际金融资产交易市场股份有限公司 消息处理方法和系统
CN111262706A (zh) * 2020-01-15 2020-06-09 杭州涂鸦信息技术有限公司 一种数据的传输方法、服务器以及存储装置
CN111282263A (zh) * 2020-03-03 2020-06-16 北京奇艺世纪科技有限公司 事件消息的处理方法、装置、电子设备及可读存储介质
CN111614577A (zh) * 2020-05-11 2020-09-01 湖南智领通信科技有限公司 一种多通信任务管理方法、装置和计算机设备
CN112015569A (zh) * 2020-08-11 2020-12-01 支付宝(杭州)信息技术有限公司 消息提醒处理方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104348874A (zh) * 2013-08-06 2015-02-11 中国电信股份有限公司 云平台组件之间消息传输的方法与装置
US8959530B1 (en) * 2013-05-07 2015-02-17 Sprint Communications Company L.P. Messaging middleware processing thread count based events
CN104731912A (zh) * 2015-03-24 2015-06-24 浪潮集团有限公司 一种消息中间件mq的消息传输方法和装置
CN105338061A (zh) * 2015-09-29 2016-02-17 华中科技大学 一种轻量级消息中间件的实现方法与系统
CN108874562A (zh) * 2018-06-21 2018-11-23 北京顺丰同城科技有限公司 分布式高并发消息队列推送系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8959530B1 (en) * 2013-05-07 2015-02-17 Sprint Communications Company L.P. Messaging middleware processing thread count based events
CN104348874A (zh) * 2013-08-06 2015-02-11 中国电信股份有限公司 云平台组件之间消息传输的方法与装置
CN104731912A (zh) * 2015-03-24 2015-06-24 浪潮集团有限公司 一种消息中间件mq的消息传输方法和装置
CN105338061A (zh) * 2015-09-29 2016-02-17 华中科技大学 一种轻量级消息中间件的实现方法与系统
CN108874562A (zh) * 2018-06-21 2018-11-23 北京顺丰同城科技有限公司 分布式高并发消息队列推送系统

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110213371A (zh) * 2019-05-31 2019-09-06 深圳前海微众银行股份有限公司 消息消费方法、装置、设备及计算机存储介质
CN110213371B (zh) * 2019-05-31 2023-05-12 深圳前海微众银行股份有限公司 消息消费方法、装置、设备及计算机存储介质
CN110365772A (zh) * 2019-07-16 2019-10-22 中国农业银行股份有限公司 消息推送方法及装置
CN110719318A (zh) * 2019-09-06 2020-01-21 上海陆家嘴国际金融资产交易市场股份有限公司 消息处理方法和系统
CN110719318B (zh) * 2019-09-06 2022-06-21 未鲲(上海)科技服务有限公司 消息处理方法和系统
CN111262706A (zh) * 2020-01-15 2020-06-09 杭州涂鸦信息技术有限公司 一种数据的传输方法、服务器以及存储装置
CN111262706B (zh) * 2020-01-15 2023-05-16 杭州涂鸦信息技术有限公司 一种数据的传输方法、服务器以及存储装置
CN111282263A (zh) * 2020-03-03 2020-06-16 北京奇艺世纪科技有限公司 事件消息的处理方法、装置、电子设备及可读存储介质
CN111614577A (zh) * 2020-05-11 2020-09-01 湖南智领通信科技有限公司 一种多通信任务管理方法、装置和计算机设备
CN111614577B (zh) * 2020-05-11 2023-04-18 湖南智领通信科技有限公司 一种多通信任务管理方法、装置和计算机设备
CN112015569A (zh) * 2020-08-11 2020-12-01 支付宝(杭州)信息技术有限公司 消息提醒处理方法及装置
CN112015569B (zh) * 2020-08-11 2024-01-30 支付宝(杭州)信息技术有限公司 消息提醒处理方法及装置

Also Published As

Publication number Publication date
CN109714409B (zh) 2021-09-14

Similar Documents

Publication Publication Date Title
CN109714409A (zh) 一种消息的管理方法和系统
US11934868B2 (en) Systems and methods for scheduling tasks
US8010840B2 (en) Generation of problem tickets for a computer system
US11036598B2 (en) Notification mechanism for disaster recovery events
US11157324B2 (en) Partitioning for delayed queues in a distributed network
US10346779B2 (en) Systems and methods for incident queue assignment and prioritization
US7886295B2 (en) Connection manager, method, system and program product for centrally managing computer applications
EP3873066A1 (en) Method for managing resource state information, and resource downloading system
US9614646B2 (en) Method and system for robust message retransmission
US11741075B2 (en) Methods and system of tracking transactions for distributed ledger
US9590885B1 (en) System and method of calculating and reporting of messages expiring from a queue
WO2013078689A1 (zh) 一种云消息服务中实现消息传递的方法和装置
US20160036665A1 (en) Data verification based upgrades in time series system
US11416294B1 (en) Task processing for management of data center resources
CN114253748A (zh) 一种消息处理系统和消息处理方法
CN108733515A (zh) 文件备份的调度方法、文件备份方法、装置及存储介质
US20160099999A1 (en) Lightweight framework with dynamic self-organizing coordination capability for clustered applications
CN110620798B (zh) Ftp连接的控制方法、系统、设备和存储介质
US8077699B2 (en) Independent message stores and message transport agents
CN116346834A (zh) 一种会话同步方法、装置、计算设备及计算机存储介质
CN114880137A (zh) 消息处理方法及装置、电子设备及存储介质
CN115373886A (zh) 服务群组容器停机方法、装置、计算机设备和存储介质
CN110677497B (zh) 一种网络介质分发方法及装置
US20080034053A1 (en) Mail Server Clustering
CN112866359B (zh) 数据上链方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant