一种消息管理方法及装置
技术领域
本申请涉及通信技术领域,尤其涉及一种消息管理方法及装置。
背景技术
目前,对于具有时效性的消息(如短信验证码、邮件验证码等)的处理,能否及时发送是其中的关键环节。随着社会的发展,消息发送的次数/数量呈几何式增长,因此,很容易出现消息积压的现象,从影响消息处理的时效性。
目前,在现有技术中,消息积压量的监控方式大多数都是在出现消息积压现象后才会进行警示或提示,即当消息积压量达到一定数量时才进行报警,导致工作人员在收到积压报警时,消息的积压量往往已经很大,此时即使采取相关措施,也会对业务平台或者用户造成不可逆转的影响。因此,上述监控方式并没有从根源上解决积压现象的问题。
如何降低消息积压现象出现的概率,提升用户接收消息的体验是亟待解决的问题。
发明内容
鉴于上述问题,提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的一种消息管理方法及装置。
第一方面,本发明实施例提供了一种消息管理方法,可包括:
根据第一消息队列接收目标消息的第一时间,确定目标消息的滞留时长,滞留时长为第一时间到当前时间的时长,第一消息队列中所接收到的消息通过第一消息发送通道进行发送;
若滞留时长超过第一消息队列的消息滞留时间阈值,确定目标消息为失效消息;
将失效消息投递到第二消息队列中,第二消息队列中所接收到的消息通过第二消息发送通道进行发送。
通过第一方面发明实施例,消息管理装置可以根据第一消息队列接收目标消息的第一时间,确定目标消息从第一时间到当前时间的滞留时长,并判断该滞留时长是否超过第一消息队列的消息滞留时间阈值。若超过,则确定该目标消息为失效消息,并将该失效消息投递到第二消息队列中,通过第二消息发送通道进行发送,其中,由于第一消息发送通道与第二消息发送通道不同,因此当判断出第一消息队列对应的第一消息通道中出现消息积压时,则可以将第一消息队列中所积压的消息投递到第二消息队列中以通过第二消息发送通道进行发送,在减少了积压消息数量的同时,也大大的降低了出现消息积压的现象的概率,从而减少对消息发送业务造成的不良影响,还可以提升用户接收消息的体验。
在一种可能的实现方式中,所述根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长之前,还包括:接收第一指令,所述第一指令用于指示创建所述第一消息队列,所述第一指令包括所述消息滞留时间阈值;接收所述目标消息,并记录所述第一时间。
在一种可能的实现方式中,所述方法还包括:接收第二指令,所述第二指令用于指示创建所述第二消息队列,所述第二指令包括所述第一数量阈值。
在一种可能的实现方式中,所述将所述失效消息投入到第二消息队列中之后,还包括:若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告,所述积压警告用于指示出现失效消息积压。
在一种可能的实现方式中,所述若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告包括:若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告,所述积压警告包括所述第二消息队列中所述失效消息的数量和/或所述失效消息对应的失效滞留时长,所述失效滞留时长为所述第二消息队列接收所述失效消息的第二时间到当前时间的时长。
在一种可能的实现方式中,所述若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告之后,还包括:确定所述第一消息队列中的当前消息数量;若所述当前消息数量达到第二数量阈值,则控制所述第一消息队列拒绝接受消息。
在一种可能的实现方式中,所述根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长,包括:按预设时间间隔,根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长。
第二方面,本发明实施例提供了一种消息管理装置,包括:
第一确定单元,用于根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长,所述滞留时长为所述第一时间到当前时间的时长,所述第一消息队列中所接收到的消息通过第一消息发送通道进行发送;
第二确定单元,用于若所述滞留时长超过所述第一消息队列的消息滞留时间阈值,确定所述目标消息为失效消息;
投递单元,用于将所述失效消息投递到第二消息队列中,所述第二消息队列中所接收到的消息通过第二消息发送通道进行发送。
在一种可能的实现方式中,所述装置还包括:第一接收单元,用于根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长之前,接收第一指令,所述第一指令用于指示创建所述第一消息队列,所述第一指令包括所述消息滞留时间阈值;接收记录单元,用于接收所述目标消息,并记录所述第一时间。
在一种可能的实现方式中,所述方法还包括:第二接收单元,用于接收第二指令,所述第二指令用于指示创建所述第二消息队列,所述第二指令包括所述第一数量阈值。
在一种可能的实现方式中,所述还包括:警告单元,用于将所述失效消息投入到第二消息队列中之后,若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告,所述积压警告用于指示出现失效消息积压。
在一种可能的实现方式中,所述警告单元,具体用于若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告,所述积压警告包括所述第二消息队列中所述失效消息的数量和/或所述失效消息对应的失效滞留时长,所述失效滞留时长为所述第二消息队列接收所述失效消息的第二时间到当前时间的时长。
在一种可能的实现方式中,所述还包括:第三确定单元,用于若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告之后,确定所述第一消息队列中的当前消息数量;控制单元,用于若所述当前消息数量达到第二数量阈值,则控制所述第一消息队列拒绝接受消息。
在一种可能的实现方式中,所述第一确定单元,具体用于按预设时间间隔,根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长。
第三方面,本发明实施例提供了一种消息管理装置,包括存储组件,处理组件和通信组件,存储组件,处理组件和通信组件相互连接,其中,存储组件用于存储数据处理代码,通信组件用于与外部设备进行信息交互;处理组件被配置用于调用程序代码,执行第一方面所述的方法,此处不再赘述。
第四方面,本发明实施例提供了一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行以实现上述第一方面的方法。
附图说明
为了更清楚地说明本发明实施例或背景技术中的技术方案,下面将对本发明实施例或背景技术中所需要使用的附图进行说明。
图1是本发明实施例提供的一种消息管理系统架构的示意图;
图2是本发明实施例提供的一种消息管理方法流程的示意图;
图3是本发明实施例提供的另一种消息管理方法流程的示意图;
图4是本发明实施例提供的一种在应用场景中消息管理系统示意图;
图5是本发明实施例提供的一种消息管理装置的结构示意图;
图6是本发明实施例提供的一种消息管理装置简化的实体装置结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例进行描述。
本申请的说明书和权利要求书及所述附图中的术语“第一”、“第二”和“第三”等是用于区别不同对象,而不是用于描述特定顺序。此外,“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本文中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本文所描述的实施例可以与其它实施例相结合。
在本申请中使用的术语“服务器”、“单元”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如,服务器可以是但不限于,处理器,数据处理平台,计算设备,计算机,两个或更多个计算机等。
首先,对本申请中的部分用语进行解释说明,以便于本领域技术人员理解。
(1)消息队列,消息队列是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递,如果发送消息时接收者不可用,消息队列会保留消息,直到可以成功地传递它。
(2)开源消息队列系统(RabbitMQ),用erlang语言开发,也可以是一个在高级消息队列协议(Advanced Message Queuing Protocol,AMQP)基础上完成的,可复用的企业消息系统,还可以是AMQP的标准实现。
(3)短信,一般情况下,按照时限性要求短信可以分为两种类型:一种是即时短信,即有较高时限性要求、需要及时转发给运营商以便运营商发送给指定客户的短信;另一种是非即时短信,即相对即时短信而言没有很高的时限性要求的短信。
其次,对本发明实施例所基于的其中一种消息管理系统架构进行描述。请参考附图1,图1是本发明实施例提供的一种消息管理系统架构的示意图,包括:消息管理装置101和用户终端102。
消息管理装置101,可以是提供消息服务的设备、短信服务平台、短信服务器或消息服务平台等。当消息管理装置101为服务器时,服务器上可以创建或存储有第一消息队列和第二消息队列,进一步地,服务器可以根据第一消息队列接收目标消息的第一时间,确定目标消息的滞留时长,滞留时长为第一时间到当前时间的时长,第一消息队列中所接收到的消息通过第一消息发送通道进行发送;若滞留时长超过第一消息队列的消息滞留时间阈值,确定目标消息为失效消息;将失效消息投递到第二消息队列中,第二消息队列中所接收到的消息通过第二消息发送通道进行发送。
用户终端102可以是通信终端、移动设备、用户终端、移动终端、无线通信设备、便携式终端、用户代理、用户装置、服务设备或用户设备(User Equipment,UE)等计算机网络中处于网络最外围的设备,主要用于数据的输入以及处理结果的输出或显示等,也可以是安装于或运行于上述任一一设备上的软件客户端、应用程序等。例如,用户终端102可以是电脑、平板设备、智能手机,或安装于或运行于电脑、平板设备、智能手机上的软件客户端、应用程度等。用户终端102可以接收通过第一消息发送通道或第二消息发送通道进行发送的消息。
还可以理解的是,图1的消息管理系统架构只是本申请实施例中的部分示例性的实施方式,本申请实施例中的消息管理系统架构包括但不仅限于以上消息管理系统架构。
参考附图2,图2是本发明实施例提供的一种消息管理方法流程的示意图。可应用于上述图1中的系统,下面将结合图2以执行主体是消息管理装置101,从消息管理装置101的单侧进行描述。该方法可以包括以下步骤S201-步骤S203。
步骤S201:根据第一消息队列接收目标消息的第一时间,确定目标消息的滞留时长。
具体地,消息管理装置根据第一消息队列接收目标消息的第一时间,确定目标消息的滞留时长,其中,滞留时长为第一时间到当前时间的时长,第一消息队列中所接收到的消息通过第一消息发送通道进行发送,目标消息可以是带有时效性的消息。例如:若当前时间为上午9:26:32,此时第一消息队列中存储有上午9:25:32接收到的,需要给用户发送的A消息,则该A消息的第一时间为上午9:25:32,滞留时长为60s。
可选的,消息管理装置可以按预设时间间隔,根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长,即,消息管理装置可以周期性确定第一消息队列中存留的消息的滞留时长。例如:预设时间间隔可以设置为90s,则消息管理装置可以每隔90s确定一次目标消息的滞留时长。
可选的,消息管理装置可以根据第一消息队列接收目标消息的第一时间,实时确定目标消息的滞留时长,滞留时长为根据第一消息队列接收目标消息的第一时间到当前时间的时长。例如:从第一消息队列接收到目标消息时开始计时,并实时确定接收到该目标消息的第一时间到当前时间的时长,直至该目标消息不在第一消息队列为止。
步骤S202:若滞留时长超过第一消息队列的消息滞留时间阈值,确定目标消息为失效消息。
具体地,若消息管理装置确定目标消息的滞留时长超过第一消息队列的消息滞留时间阈值,确定该目标消息为失效消息,其中,第一消息队列的消息滞留时间阈值可以是预先设置的时间阈值,例如,可以将消息滞留时间阈值设置为90s,若消息管理装置确定目标消息的滞留时长为91s,则该目标消息为失效消息
可选的,若滞留时长超过第一消息队列的消息滞留时间阈值,且第一消息队列中的消息数量达到发送阈值,确定该目标消息为失效消息,其中发送阈值可以为预先确定的消息数量阈值。例如:若消息滞留时间阈值设置为90s,发送阈值设置为300条,且此时第一消息队列内的消息为296条,因此,消息管理装置确定目标消息的滞留时长为91s时,该目标消息不是失效消息。
步骤S203:将失效消息投递到第二消息队列中。
具体地,消息管理装置确定目标消息为失效消息后,将该失效消息投递到第二消息队列中,第二消息队列中所接收到的消息通过第二消息发送通道进行发送。即,消息管理装置需要将第一消息队列中确定为失效消息的消息投递到第二消息队列中。
可选的,第二消息队列用于接收从第一消息队列中投递出的失效消息,可以理解的是,第二消息队列与第一消息队列不同,第二消息发送失效消息的第二消息发送通道与第一消息发送目标消息的第一消息发送通道也不同。
实施本发明实施例,消息管理装置可以根据第一消息队列接收目标消息的第一时间,确定目标消息从第一时间到当前时间的滞留时长,并判断该滞留时长是否超过第一消息队列的消息滞留时间阈值。若超过,则确定该目标消息为失效消息,并将该失效消息投递到第二消息队列中,通过第二消息发送通道进行发送,其中,由于第一消息发送通道与第二消息发送通道不同,因此当判断出第一消息队列对应的第一消息通道中出现消息积压时,则可以将第一消息队列中所积压的消息投递到第二消息队列中以通过第二消息发送通道进行发送,在减少了积压消息数量的同时,也大大的降低了出现消息积压的现象的概率,从而减少对消息发送业务造成的不良影响,还可以提升用户接收消息的体验。
参考附图3,图3是本发明实施例提供的另一种消息管理方法流程的示意图。可应用于上述图1中的系统,下面将结合图3以执行主体是消息管理装置101,从消息管理装置101的单侧进行描述。该方法可以包括以下步骤S301-步骤S309。
步骤S301:接收第一指令。
具体地,消息管理装置接收第一指令,第一指令用于指示创建第一消息队列,第一指令包括消息滞留时间阈值。即,消息管理装置可以根据第一指令创建第一消息队列并确定第一消息队列中消息的消息滞留时间阈值,其中,消息滞留时间阈值用于消息管理装置确定目标消息是否为失效消息。
可选的,消息管理装置可以接收用于指示创建第一消息队列的指令,创建完成该第一消息队列后,再根据消息滞留时间阈值设置指令,设置该第一消息队列的消息滞留时间阈值。
步骤S302:接收目标消息,并记录第一时间。
具体地,消息管理装置接收目标消息,并记录该目标消息第一时间。第一时间是消息管理装置接收到目标消息的时间。例如:若第一消息队列中存储有上午9:32:25接收到的,需要给用户A发送的B消息,则该B消息的第一时间为上午9:32:25,其中,第一时间可以用于消息管理装置判断该目标消息是否为失效消息。
步骤S303:接收第二指令。
具体地,消息管理装置接收第二指令,其中,第二指令包括第一数量阈值,用于指示消息管理装置创建第二消息队列。第一数量阈值为预设的第二消息队列中失效消息的数值,可以用于判断第二消息队列中的消息是否出现失效消息积压现象,例如,第一数量阈值可以是500条,若第二消息队列中的消息数量超过500,即可判断出第二消息队列出现失效消息积压现象。
可选的,消息管理装置可以接收用于指示创建第二消息队列的指令,创建完成该第二消息队列后,再根据消息滞留时间阈值设置指令,设置该第二消息队列的第一数量阈值。
步骤S304:根据第一消息队列接收目标消息的第一时间,确定目标消息的滞留时长。
步骤S305:若滞留时长超过第一消息队列的消息滞留时间阈值,确定目标消息为失效消息。
步骤S306:将失效消息投递到第二消息队列中。
具体地,上述对步骤S304到步骤S306的各个步骤的描述可以对应参照图2的步骤S201到步骤S203,此处不再赘述。
步骤S307:若第二消息队列中失效消息的数量达到第一数量阈值,向指定客户端发送失效消息的积压警告。
具体地,若第二消息队列中失效消息的数量达到第一数量阈值,消息管理装置可以向指定客户端发送失效消息的积压警告,积压警告用于指示出现失效消息积压。发送积压警告的形式可以包括即时通讯形式(例如:电话等),非即时通讯形式(例如:邮件、短信等)等。
可选的,若第二消息队列中失效消息的数量达到第一数量阈值,消息管理装置可以向指定客户端发送失效消息的积压警告,其中,积压警告包括第二消息队列中失效消息的数量和/或失效消息对应的失效滞留时长,失效滞留时长为第二消息队列接收失效消息的第二时间到当前时间的时长。例如:消息管理装置可以向指定的客户端发送积压警告,其中,积压警告包括第二消息队列中失效消息的数量和/或失效消息对应的失效滞留时长,有利于指定客户端或其他相关人员根据失效消息的数量和/或失效滞留时长判断出积压规模的大小,以便及时对该现象做出相关操作的处理。
可选的,第二消息队列和第二消息队列对应的第二消息发送通道的数量并不做限定。即,消息管理装置可能拥有与第二消息队列和第二消息发送通道具有相同作用的其他消息队列和对应的消息发送通道。上述消息队列和对应的消息发送通道可按消息发送通道的大小进行失效消息接收优先级排序,也可无差别接收失效消息。若有多个消息队列和对应的消息发送通道,当所有消息队列(与第二消息队列作用一致的)中失效消息的数量达到第一数量阈值,消息管理装置可以向指定客户端发送失效消息的积压警告,需要说明的是,此时消息队列和消息发送通道之间的关系可以但不限于一一对应。
可选的,按预设时间,以关键字或其他识别方式识别第二消息队列中的失效消息是否为即时性消息;若确定该失效消息为即时性消息,且从该即时性消息对应的第一时间到当前时间已经超过该即时性消息的有效时间时,删除该即时性消息。例如:若一条验证码短信两分钟有效,上午十点整收到该验证码短信,现在为上午10:03:00,消息管理装置确定第二消息队列中存储有该验证码短信,则消息管理装置从第二消息队列中删除该验证码短信。
步骤S308:确定第一消息队列中的当前消息数量。
具体地,消息管理装置确定出现失效消息积压后,可以确认第一消息队列中的当前消息数量。消息管理装置可以根据当前消息数量判断出是否需要控制第一消息队列拒绝接受消息。
步骤S309:若当前消息数量达到第二数量阈值,则控制第一消息队列拒绝接受消息。
具体地,消息管理装置确定第一消息队列中的当前消息数量后,进一步判断当前消息数量是否达到第二数量阈值。若当前消息数量达到第二数量阈值,则控制第一消息队列拒绝接受消息。可以理解的是,第一消息队列拒绝接受消息,有利于消息管理装置中的消息数量不再增加,进一步的,可以缓解消息管理装置中失效消息积压现象。
实施本发明实施例,可以根据第一消息队列接收目标消息的第一时间,确定目标消息从第一时间到当前时间的滞留时长,并判断该滞留时长是否超过第一消息队列的消息滞留时间阈值。若超过,则确定该目标消息为失效消息,并将该失效消息投递到第二消息队列中。进一步的,若第二消息队列中失效消息的数量达到第一数量阈值,消息管理装置可以向指定客户端发送失效消息的积压警告。其中,积压警告用于指示第二消息队列中出现失效消息积压现象,积压警告还包括了第二消息队列中失效消息的数量和/或失效消息对应的失效滞留时长,以便指定客户端或指定客户端使用者通过该积压警告提供的相关数据,对出现失效消息积压现象后进行相关维护。第一消息队列中所接收到的消息通过第一消息发送通道进行发送,第二消息队列中所接收到的消息可以通过第二消息发送通道进行发送,而第一消息发送通道与第二消息发送通道不同,因此,消息管理装置可以将第一消息队列中所积压的消息投递到第二消息队列中以通过第二消息发送通道进行发送,在减少了积压消息数量的同时,也大大的降低了出现消息积压的现象的概率,从而减少了对消息发送业务造成的不良影响,进一步的提升了消息发送效率和用户接收消息的体验。
请参考附图4,图4是本发明实施例提供的一种在应用场景中消息管理系统示意图。包括了短信接口、RabbitMQ和短信通道服务。其中,短信接口用于接收短信;RabbitMQ包括:消息队列A和消息队列B,消息队列A相当于本申请中的第一消息队列,消息队列B相当于本申请中的第二消息队列;短信通道服务包括:短信通道A和短信通道B,短信通道A相当于本申请中的第一消息发送通道,短信通道B相当于本申请中的第二消息发送通道。下面将结合图4以执行主体是消息管理装置101为例,从消息管理装置101的单侧对某一应用场景中的方法流程进行描述。
对应场景:在需要发送时效性短信(验证码短信)的短信服务平台中,为了防止因突发原因,造成短信发送积压现象的出现,短信服务平台创建消息队列RabbitMQ,并针对该消息队列设置过期时间(TTL),消息在该消息队列的存活时间一旦超过设置的TTL值,该条消息会过期失效变成dead message。其中,RabbitMQ为消息队列,TTL相当于本申请中的消息滞留时间阈值,存活时间相当于本申请中的滞留时长,dead message相当于本申请中的失效消息。
1、创建消息队列A,并且设置短信消息队列A的过期时间(TTL):x-message-ttl=90000(单位:毫秒)。消息滞留时间阈值=90000(单位:毫秒)。
2、创建消息队列B,并且将消息队列B设置为消息队列A的过期失效dead message的重新转发投递队列,通过设置参数x-dead-letter-exchange:消息队列A.exchange,其中,该参数用于绑定消息队列A和消息队列B。
3、发送的短信,正常是进入到消息队列A进行发送,如果短信在消息队列A中停留时间超过设置TTL(过期时间),该条短信过期失效变成dead message,自动投递到消息队列B选择备用通道进行发送处理。
4、一旦消息队列B接收到来自消息队列A投递的短信消息,系统会触发自动发邮件和短信告警,提醒相关人员消息队列A出现了积压现象,人工排查阻塞的原因并处理。其中,本发明实施例中第一数量阈值为1,因此,若消息队列B存在短信消息,则消息队列A发生了阻塞。
总的来说,本申请可以通过对消息积压情况进行监控,在第一消息队列中消息的滞留时长超过消息滞留时间阈值时,将该消息投递到第二消息队列中,进一步的,通过第二消息发送通道,减缓信息发送压力,降低消息积压现象出现的概率,提升了短信发送效率和用户接收消息体验。
上述详细阐述了本发明实施例的方法,下面提供了与本发明实施例的相关消息管理装置,消息管理装置可以是一种通过快速获取、处理、分析和提取有价值的数据,以交互数据为基础,为第三方使用带来各种便利的服务设备。请参考附图5,图5是本发明实施例提供的一种消息管理装置的结构示意图。可以包括第一确定单元501,第二确定单元502和投递单元503,还可以包括第一接收单元504,接收记录单元505,第二接收单元506,警告单元507,第三确定单元508和控制单元509。
第一确定单元501,用于根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长,所述滞留时长为所述第一时间到当前时间的时长,所述第一消息队列中所接收到的消息通过第一消息发送通道进行发送;
第二确定单元502,用于若所述滞留时长超过所述第一消息队列的消息滞留时间阈值,确定所述目标消息为失效消息;
投递单元503,用于将所述失效消息投递到第二消息队列中,所述第二消息队列中所接收到的消息通过第二消息发送通道进行发送。
在一种可能的实现方式中,所述装置还包括:第一接收单元504,用于根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长之前,接收第一指令,所述第一指令用于指示创建所述第一消息队列,所述第一指令包括所述消息滞留时间阈值;接收记录单元505,用于接收所述目标消息,并记录所述第一时间。
在一种可能的实现方式中,所述方法还包括:第二接收单元506,用于接收第二指令,所述第二指令用于指示创建所述第二消息队列,所述第二指令包括所述第一数量阈值。
在一种可能的实现方式中,所述还包括:警告单元507,用于将所述失效消息投入到第二消息队列中之后,若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告,所述积压警告用于指示出现失效消息积压。
在一种可能的实现方式中,所述警告单元507,具体用于若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告,所述积压警告包括所述第二消息队列中所述失效消息的数量和/或所述失效消息对应的失效滞留时长,所述失效滞留时长为所述第二消息队列接收所述失效消息的第二时间到当前时间的时长。
在一种可能的实现方式中,所述还包括:第三确定单元508,用于若所述第二消息队列中所述失效消息的数量达到第一数量阈值,向指定客户端发送所述失效消息的积压警告之后,确定所述第一消息队列中的当前消息数量;控制单元509,用于若所述当前消息数量达到第二数量阈值,则控制所述第一消息队列拒绝接受消息。
在一种可能的实现方式中,所述第一确定单元501,具体用于按预设时间间隔,根据第一消息队列接收目标消息的第一时间,确定所述目标消息的滞留时长。
需要说明的是,各个操作的实现还可以对应参照图2、图3和图4所示的方法实施例的相应描述,此处不再赘述。
请参考附图6,图6是本发明实施例提供的一种消息管理装置简化的实体装置结构示意图,便于理解和图示方便,图6装置60中,可以包括以下一个或多个组件:存储组件601,处理组件602,通信组件603。
存储组件601可以包括一个或多个存储单元,每个单元可以包括一个或多个存储器,存储组件可用于存储程序和各种数据,并能在装置60运行过程中高速、自动地完成程序或数据的存取。可以采用具有两种稳定状态的物理器件来存储信息,所述两种稳定状态分别表示为“0”和“1”。当图6所示的装置60,为图1所述消息管理装置101时,存储组件可以用来存储第一信息,第二信息以及其他相关数据等。
处理组件602,处理组件也可以称为处理器,处理单元,处理单板,处理模块、处理装置等。处理组件可以是中央处理器(central processing unit,CPU),网络处理器(network processor,NP)或者CPU和NP的组合。当图6所示的装置60,为图1所述消息管理装置101时,所述处理组件603用于调用所述存储组件601的数据执行上述图2至图3所述方法的相关描述,此处不再赘述。
通信组件603,也可以称为收发机,或收发器等,其中可以包括用来进行无线、有线或其他通信方式的单元。可选的,可以将603部分中用于实现接收功能的器件视为接收单元,将用于实现发送功能的器件视为发送单元,即603部分包括第一接收单元,接收记录单元,第二接收单元和警告单元等。
需要说明的是,各个操作的具体实现还可以对应参照图2、图3和图4所示的方法实施例的相应描述,此处不再赘述。
在本申请中,所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
另外,在本申请各个实施例中的各功能组件可以集成在一个组件也可以是各个组件单独物理存在,也可以是两个或两个以上组件集成在一个组件中。上述集成的组件既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的组件如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分,或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个本发明实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本发明的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。尽管在此结合各实施例对本申请进行了描述,然而,在实施例所要求保护的本申请过程中,本领域技术人员可理解并实现公开实施例的其他变化。