一种消息处理方法及装置与流程

1.本技术涉及资源调度技术领域，具体涉及一种消息处理方法及装置。


背景技术：

2.流式架构是应用于信息系统中的一种典型架构。流式架构的主要特点是以消息流作为中心数据源，无需集中式的数据库。流式架构可应用于多个行业，例如金融行业。应用于金融行业的流式架构包括消息生产系统、消息中间件和消息消费系统，具体来说，例如消息生产系统例如央行的系统，消息生产系统发布消息，消息中间件接收并缓存消息，消息消费系统通过消息中间件集群从接收并处理相应的消息，消息消费系统例如各大银行的系统。一般来说，流式架构对消息消费系统处理消息的速度要求较高，但目前确尚无相应的机制以检测消息消费系统是否存在消息积压。


技术实现要素：

3.本技术实施例提供一种消息处理方法及装置，用于提供检测消费系统是否消息积压的机制。
4.第一方面，提供了一种消息处理方法，应用于与消息中间件通信的多个消息消费系统中的目标消息消费系统中，所述方法包括：从所述消息中间件接收至少一个消息，并将所述至少一个消息记录所述目标消息消费系统的缓存表中，所述至少一个消息是所述消息中间件从消息生产系统接收的；若所述目标消息消费系统已处理所述缓存表中的第一消息，则删除所述缓存表中记录的所述第一消息，所述第一消息为所述至少一个消息中的一个；确定所述缓存表中的记录的消息的总数量；基于所述总数量，确定所述目标消息消费系统是否存在消息积压。
5.在一种可能实施方式中，基于所述总数量，确定所述目标消息消费系统是否存在消息积压，包括：若所述总数量大于第一数量，则确定所述目标消息消费系统存在消息积压，或者，若所述总数量大于第一数量，且所述目标消息消费系统处理所述缓存表中的消息的速率小于从所述消息中间件接收消息的速率，则确定所述目标消息消费系统存在消息积压；若所述总数量小于或等于所述第一数量，则确定所述目标消息消费系统不存在消息积压。
6.在一种可能的实施方式中，在确定所述目标消息消费系统存在消息积压之后，所述方法还包括：输出提示信息，所述提示信息用于提示处理所述目标消息消费系统存在消息积压。
7.在一种可能的实施方式中，所述缓存表包括多个分表，其中每个分表用于记录多个业务类型中的一个业务类型对应的消息；将所述至少一个消息记录所述目标消息消费系统的缓存表中，包括：分别对所述至少一个消息执行以下操作：确定所述至少一个消息中的一个消息对应的业务类型；从所述多个分表中，确定与所述一个消息对应的业务类型对应的第一分表；将所述一个消息记录在所述第一分表中。
8.在一种可能的实施方式中，所述方法还包括：若所述总数量大于第二数量，则执行消息控制策略，所述消息控制策略是用于处理所述缓存表中的消息的策略，所述第二数量大于或等于所述第一数量。
9.在一种可能的实施方式中，执行消息控制策略，包括执行以下的一种或多种：从所述多个业务类型中，确定重要程度小于预设重要程度的至少一个业务类型，并丢弃确定出的至少一个业务类型各自对应的分表中的消息；或，从所述多个业务类型中，确定优先级小于第一优先级的至少一个业务类型，并确定在预设时长之后，对确定出的至少一个业务类型对应的分表中的消息进行处理；或，从所述多个业务类型中，确定优先级小于第二优先级的至少一个业务类型，并将确定出的至少一个业务类型对应的分表中的消息发送给所述目标消息消费系统关联的辅助消息处理系统，以使所述辅助消息处理系统对所述确定出的至少一个业务类型对应的分表中的消息进行处理。
10.在一种可能的实施方式中，所述目标消息消费系统包括相互通信的消息处理子系统和消息存储子系统，所述缓存表设置在消息存储子系统中；若所述目标消息消费系统已处理所述缓存表中的第一消息，则删除所述缓存表中记录的所述第一消息，包括：通过所述消息处理子系统从所述缓存表中获取所述第一消息，并对所述第一消息进行处理；在通过所述消息处理子系统对所述第一消息处理之后，通过所述消息处理子系统向所述消息存储子系统发送删除指令，所述删除指令用于指示删除所述缓存表中的所述第一消息；通过所述消息存储子系统删除所述缓存表中的第一消息。
11.第二方面，提供一种消息处理装置，应用于与消息中间件通信的多个消息消费系统中的目标消息消费系统中，所述装置包括：收发模块，用于从所述消息中间件接收至少一个消息，所述至少一个消息是所述消息中间件从消息生产系统接收的；记录模块，用于将所述至少一个消息记录所述目标消息消费系统的缓存表中；删除模块，用于若所述目标消息消费系统已处理所述缓存表中的第一消息，则删除所述缓存表中记录的所述第一消息，所述第一消息为所述至少一个消息中的一个；确定模块，用于确定所述缓存表中的记录的消息的总数量，以及基于所述总数量，确定所述目标消息消费系统是否存在消息积压。
12.在一种可能的实现方式中，所述确定模块具体用于：若所述总数量大于第一数量，则确定所述目标消息消费系统存在消息积压，或者，若所述总数量大于第一数量，且所述目标消息消费系统处理所述缓存表中的消息的速率小于从所述消息中间件接收消息的速率，则确定所述目标消息消费系统存在消息积压；若所述总数量小于或等于所述第一数量，则确定所述目标消息消费系统不存在消息积压。
13.在一种可能的实施方式中，所述装置还包括输出模块，所述输出模块还用于：在确定所述目标消息消费系统存在消息积压之后，输出提示信息，所述提示信息用于提示处理所述目标消息消费系统存在消息积压。
14.在一种可能的实现方式中，所述缓存表包括多个分表，其中每个分表用于记录多个业务类型中的一个业务类型对应的消息；所述记录模块具体用于：分别对所述至少一个消息执行以下操作：确定所述至少一个消息中的一个消息对应的业务类型；从所述多个分表中，确定与所述一个消息对应的业务类型对应的第一分表；将所述一个消息记录在所述第一分表中。
15.在一种可能的实施方式中，所述装置还包括执行模块，所述执行模块具体用于：若
所述总数量大于第二数量，则执行消息控制策略，所述消息控制策略是用于处理所述缓存表中的消息的策略，所述第二数量大于或等于所述第一数量。
16.在一种可能的实施方式中，所述执行模块具体用于执行以下的一种或多种：从所述多个业务类型中，确定重要程度小于预设重要程度的至少一个业务类型，并丢弃确定出的至少一个业务类型各自对应的分表中的消息；或，从所述多个业务类型中，确定优先级小于第一优先级的至少一个业务类型，并确定在预设时长之后，对确定出的至少一个业务类型对应的分表中的消息进行处理；或，从所述多个业务类型中，确定优先级小于第二优先级的至少一个业务类型，并将确定出的至少一个业务类型对应的分表中的消息发送给所述目标消息消费系统关联的辅助消息处理系统，以使所述辅助消息处理系统对所述确定出的至少一个业务类型对应的分表中的消息进行处理。
17.在一种可能的实施方式中，所述目标消息消费系统包括相互通信的消息处理子系统和消息存储子系统，所述缓存表设置在消息存储子系统中；所述删除模块具体用于：通过所述消息处理子系统从所述缓存表中获取所述第一消息，并对所述第一消息进行处理；在通过所述消息处理子系统对所述第一消息处理之后，通过所述消息处理子系统向所述消息存储子系统发送删除指令，所述删除指令用于指示删除所述缓存表中的所述第一消息；通过所述消息存储子系统删除所述缓存表中的第一消息。
18.第三方面，提供一种消息处理设备，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令实现如第一方面及任一可能的实施方式中任一的方法。
19.第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第一方面及任一可能的实施方式中任一的方法。
20.第五方面，提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如第一方面及任一可能的实施方式中任一的方法。
21.由于本技术实施例采用上述技术方案，至少具有如下技术效果：
22.在本技术实施例中，在消息消费系统中设置缓存表，该缓存表可记录从消息中间件接收的消息，一旦消息消费系统处理完某个消息，那么可以删除缓存表中的消息，也就是说，缓存表中存储的是消息消费系统没有处理的消息，如此，只需根据缓存表中的消息数量，便可以判断消息消费系统是否存在消息积压，提供了一种判断消息消费系统是否存在消息积压的机制。并且，在本技术实施例中，可以直接根据缓存表中的消息数量判断消息消费系统是否存在消息积压，判断方式简单。
附图说明
23.图1为本技术实施例适用的一种应用场景图；
24.图2为本技术实施例提供的一种消息消费系统的架构示意图；
25.图3为本技术实施例提供的一种消息处理方法的流程示意图；
26.图4为本技术实施例提供的一种消息处理装置的结构示意图；
27.图5为本技术实施例提供的一种消息处理设备的结构示意图。
具体实施方式
28.为了更好的理解本技术实施例提供的技术方案，下面将结合说明书附图以及具体的实施方式进行详细的说明。
29.需要说明的是，本技术涉及的数据采集和处理符合国家法律法规。另外，本技术实施例涉及的“a和/或b”包括a、b以及a和b三种情况，“多个”是指两个或两个以上，“至少一个”是指一个或一个以上。
30.本技术实施例提供了一种消息处理方案，在该消息处理方案中，在消息消费系统中设置缓存表(cache)，缓存表用于记录消息消费系统没有处理的消息，消息消费系统可根据缓存表中记录的消息的数量，进而判断消息消费系统是否存在消息积压，提供了一种判断消息消费系统是否存在消息积压的机制。
31.请参照图1，为本技术实施例提供的一种消息处理方案适用的一种应用场景示意图，或者也可以理解为一种流式架构的示意图。
32.如图1所示，该应用场景包括消息生产系统110、消息中间件120和消息消费系统130。需要说明的是，消息中间件120的数量可以是多个，图1中是以一个消息中间件120为例。消息消费系统130的数量可以是多个，图1中是以消息消费系统130包括第一消息消费系统131和第二消息消费系统132进行示例。
33.消息生产系统110又可称为消息生产者，可用于发布消息。以金融行业为例，消息生产系统110例如为央行的系统或中国银联的系统。
34.消息中间件120可用于缓存消息生产系统110发布的消息。消息中间件120可以由多种技术实现方式，例如可采用卡夫卡(kafka)技术实现。
35.消息消费系统130又可以称为消息消费者，用于订阅至少一种业务类型对应的消息，并从消息中间件120获取相应业务类型对应的消息。本技术实施例中的一种业务类型可对应一种业务，或者可对应一种消息主题(topic)。消息消费系统130还可以对获取的消息进行处理。
36.示例性的，消息生产系统110、消息中间件120和消息消费系统130均可通过计算设备实现，计算设备例如均通过服务器或服务器集群实现，服务器如虚拟服务器或实体服务器。
37.以图1所示的应用场景具体应用在金融行业为例，消息生产系统110例如可以为央行的系统或者中国银联的系统，消息消费系统130例如为各大银行的系统等。央行的系统可以将发布的金融消息缓存在消息中间件120中，消息消费系统130通过消息中间件120，从而获得央行的系统发布的金融消息，并对金融消息进行处理。
38.在一种可能的实施例中，请参照图2，为本技术实施例中的消息消费系统的一种架构示意图，该消息消费系统130包括消息存储子系统210和消息处理子系统220。消息存储子系统210可以用于将从消息中间件120获取的消息记录在缓存表中，消息处理子系统220用于从缓存表中获取消息，并对消息进行进一步处理。
39.可选的，消息存储子系统210包括监视模块211和缓存表212。监视模块211用于监视缓存表212是否存在消息积压。缓存表212的作用可参照前文。消息处理子系统220包括处理模块221和外呼模块222。处理模块221用于对缓存表中的消息进行处理。外呼模块222可与辅助消息处理系统230相互通信，外部模块222可以将处理模块221无法及时处理的消息
发送给辅助消息处理系统230处理。需要说明的是，辅助消息处理系统230和消息消费系统130是相对独立设置的两个系统，例如，辅助消息处理系统230和消息消费系统130分别搭建在不同的服务器集群上。
40.作为一个示例，辅助消息处理系统230也可以通过计算设备实现，计算设备例如服务器或服务器集群等。
41.下面基于图1所示的应用场景示意图为例，对本技术实施例中的消息处理方法进行介绍。请参照图3，为本技术实施例中的消息处理方法的流程示意图。
42.步骤31，从消息中间件接收至少一个消息，并将至少一个消息记录目标消息消费系统的缓存表中。
43.需要说明的是，在图3中是以目标消息消费系统执行消息处理方法为例进行介绍。本技术实施例中的目标消息消费系统实际可以为接入消息中间件中的任意一个消息消费系统，例如，图1中的第一消息消费系统或第二消息消费系统等。
44.消息生产系统可以定时或不定时地发布至少一个消息，在本技术实施例是以至少一个消息为例进行说明，实际不限制消息生产系统发布的消息的数量。消息生产系统可主动向消息中间件发送至少一个消息。或者，消息中间件可周期性地问询消息生产系统，从消息生产系统获取至少一个消息。消息的形式可以是多种，例如图片、文字、表格、视频、音频等一种或多种，本技术实施例对此不做限定。
45.目标消息消费系统可提前订阅至少一种业务类型的消息，消息中间件根据其缓存的至少一个消息对应的业务类型，确定该至少一个消息对应的业务类型属于目标消息消费系统对应的业务类型，那么可以将其缓存的消息发送给目标消息消费系统。或者，目标消息消费系统也可以周期性地问询消息中间件，以获得至少一个消息。示例性的，目标消息消费系统可通过消息存储子系统获取该至少一个消息。
46.在目标消息消费系统获取至少一个消息之后，可以将至少一个消息记录在缓存表中，缓存表的实现方式可以有多种。其中将消息记录在缓存中的方式有多种，下面进行示例说明。
47.示例一，目标消息消费系统将至少一个消息直接记录在缓存表中。这种方式中目标消息消费系统无需对消息进行解析处理等，记录方式简单。
48.示例二，目标消息消费系统可以按照至少一个消息对应的业务类型，记录至少一个消息。
49.具体的，该缓存表可以包括多个分表，每个分表对应一种业务类型，业务类型例如金融通知类型或账务报销类型等。目标消息消费系统可以根据至少一个消息中每个消息对应的业务类型，将至少一个消息存储至相应的分表。下面以记录一个消息的过程为例进行介绍。
50.示例性的，目标消息消费系统可以对一个消息进行解析，以获得该消息中的字段或字段中具体的内容，并根据该消息中的字段或字段中具体的内容，从而确定该消息对应的业务类型。目标消息消费系统进而从多个分表中，确定与该业务类型对应的分表，从而将该消息记录在确定出的分表。如果至少一个消息包括多个消息，那么以此类推，目标消息消费系统实现将至少一个消息记录在分表中的过程。
51.在上述示例二的方式中，相当于对至少一个消息进行了分类存储，因此可以便于
后续获取相应业务类型的消息，有利于提高目标消息消费系统后续处理消息的效率。
52.需要说明的是，图3中是以在缓存表中记录至少一个消息为例，对记录消息的过程进行示例说明。另外，如果至少一个消息的数量大于1的情况下，目标消息消费系统从消息中间件接收至少一个消息的顺序可以是任意的，当然，目标消息消费系统在缓存表中记录至少一个消息的顺序也可以是任意的，本技术实施例对此不做限定。
53.步骤32，若目标消息消费系统已处理缓存表中的第一消息，则删除缓存表中记录的所述第一消息。
54.示例性的，目标消息消费系统会对缓存表中的第一消息进行处理，处理可以理解为目标消息消费系统已根据第一消息的内容进行相应的处理，例如，目标消息消费系统可以通过消息处理子系统或消息处理子模块中的处理模块对第一消息进行处理。进一步地，为了避免目标消息消费系统对第一消息进行重复处理，目标消息消费系统在对第一消息进行处理时，可以对缓存表中的第一消息进行加锁处理。
55.例如，目标消息消费系统为银行a，第一消息为通知类型，其内容为“通知银行a提高存款利率”，那么目标消息消费系统如果将该第一消息的内容通知至银行a下的各个分支银行，那么目标消息消费系统确定已完成第一消息的处理。
56.在目标消息消费系统对第一消息处理完毕之后，目标消息消费系统可以删除缓存表中记录的第一消息，这样可避免已经处理的消息占用目标消息消费系统的存储空间。例如，目标消息消费系统可以通过消息处理子系统对第一消息进行处理，通过消息处理子系统通知消息存储子系统删除第一消息。如果目标消息消费系统对缓存表中的第一消息进行了加锁处理，那么目标消息消费系统可以先解锁第一消息，然后删除该第一消息。
57.在本技术实施例中第一消息是前文中的至少一个消息中的一个，本技术实施例中是以目标消息消费系统处理第一消息为例，实际不限制目标消息消费系统处理的消息具体是哪一个或者已处理的消息的数量。
58.步骤33，确定缓存表中的记录的消息的总数量。
59.目标消息消费系统可周期性或实时确定缓存表中记录的消息的总数量。或者，目标消息消费系统可以在缓存表中记录的消息的数量发生变化时，触发执行步骤33。
60.如果缓存表仅包括一个表，那么目标消息消费系统可统计该表中的记录的消息的数量，获得该总数量。如果缓存表包括多个分表，那么目标消息消费系统可以将多个分表各自记录的消息的数量之和确定为该总数量。
61.步骤34，基于总数量，确定目标消息消费系统是否存在消息积压。
62.具体的，目标消息消费系统如果确定总数量大于或等于第一数量，那么表示缓存表中的消息的总数量相对较多，因此确定该目标消息消费系统存在消息积压。其中，第一数量的取值可以是预配置的，例如可以根据该目标消息消费系统具有的资源的数量确定的，例如目标消息消费系统的计算资源越多，该第一数量的取值越大，例如，第一数量为3万。目标消息消费系统如果确定总数量小于第一数量，那么表示缓存表中的消息的总数量相对较少，因此确定该目标消息消费系统不存在消息积压。例如，目标消息消费系统可以通过消息存储子系统或消息存储子系统中的监视模块确定目标消息消费系统是否存在消息积压。
63.在某些情况下，目标消息消费系统有及时处理消息，但可能由于消息生产系统集中发布的消息过多，导致了目标消息消费系统短暂存在消息过多，那么这种情况下，目标消
息消费系统的消息积压情况实际可以理解为外部原因造成的，因此，在本技术实施例中，目标消息消费系统在确定总数量大于第一数量时，可以进一步判断目标消息消费系统处理缓存表中的消息的速率与从消息中间件接收消息的速率之间的关系，进而确定目标消息消费系统是否存在消息积压。
64.例如，目标消息消费系统可以统计在当前时间段，确定从消息中间件接收消息的数量，从而获得从消息中间件接收消息的速率。同理，目标消息消费系统可以统计在当前时间段，目标消息消费系统处理缓存表中的消息的数量，从而获得目标消息消费系统处理缓存表中的消息的速率。进而比较目标消息消费系统处理缓存表中的消息的速率与从消息中间件接收消息的速率之间的关系，如果目标消息消费系统处理缓存表中的消息的速率小于从消息中间件接收消息的速率，那么确定目标消息消费系统存在消息积压。这种情况下，由于考虑了目标消息消费系统的处理速率相对较小，该缓存表中的消息可能依旧会增加，进而可能会导致更为严重的积压。
65.在一种可能的实施例中，目标消息消费系统确定存在消息积压之后，可以输出提示信息，该提示信息用于提示该目标消息消费系统存在消息积压。例如，目标消息消费系统可以向目标消息消费系统关联的工作人员的终端设备发送该提示信息，和/或，目标消息消费系统以可视化形式展示该提示信息。提示信息的形式可以有多种，例如邮件、短信、弹窗消息或声音等一种或多种形式的组合。
66.在一种可能的实施例中，目标消息消费系统确定缓存表中的消息的总数量大于第二数量，可以执行消息控制策略。第二数量大于或等于第一数量，例如，第一数量为3万，第二数量为5万。消息控制策略为处理缓存表中的消息的策略。消息控制策略可以是预配置在目标消息消费系统中的，或者目标消息消费系统预存有多个消息控制策略，目标消息消费系统可根据用户的输入操作或者当前缓存表中的数量，从多个消息控制策略中，确定当前需用的消息控制策略。其中，执行消息控制策略可以包括以下的一种或多种。
67.第一种，丢弃重要程度小于预设重要程度的消息。
68.目标消息消费系统可预存有多种业务类型中每种业务类型的重要程度，重要程度可理解为业务类型对于目标消息消费系统的重要性。目标消息消费系统可从多个业务类型中，确定重要程度小于预设重要程度的至少一个业务类型，进而丢弃确定出的至少一个业务类型各自对应的分表中的消息。预设重要程度可以是预配置在目标消息消费系统中的，可以根据业务需求设置，对于不同的消息消费系统，其预设重要程度可以不同。
69.例如，在金融行业，通知类型的消息的重要程度相对比较低，因此可以做丢弃处理，比如账户报销类型的消息的重要程度会比较高，因此不能丢弃账户报销类型的消息。
70.第二种，对优先级小于第一优先级的至少一个业务类型的消息进行延后处理。
71.目标消息消费系统可以预存有多个业务类型各自的优先级，或者目标消息消费系统可以根据业务类型对应的消息的内容和/或格式，确定每个业务类型对应的优先级，例如，目标消息消费系统确定格式规范的业务类型对应的消息的优先级低，符合预设格式规范的业务类型对应的消息的优先级高。从多个业务类型中，确定优先级小于第一优先级的至少一个业务类型，并确定在预设时长之后，对确定出的至少一个业务类型对应的分表中的消息进行处理，相当于延后处理优先级比较低的业务类型对应的消息。如果优先级小于第一优先级的至少一个业务类型的数量为多个，那么其中任意两个业务类型对应的预设时
长的取值可以是相同或不同的，预设时长的取值可根据目标消息消费系统的处理速率确定。
72.第三种，将优先级小于第二优先级的至少一个业务类型对应的消息发送给辅助消息处理系统进行处理。
73.目标消息消费系统确定各个业务类型的优先级的方式可参照前文，此处不再赘述。目标消息消费系统可从多个业务类型中，确定优先级小于第二优先级的至少一个业务类型。目标消息消费系统将确定出的至少一个业务类型对应的分表中的消息发送给目标消息消费系统关联的辅助消息处理系统，例如，目标消息消费系统可通过消息处理子系统中的外呼模块将确定出的至少一个业务类型对应的分表中的消息发送给目标消息消费系统。辅助消息处理系统对确定出的至少一个业务类型对应的分表中的消息进行处理。其中，第一优先级和第二优先级的取值可以相同，也可以不同。
74.由于辅助消息处理系统是相对于目标消息消费系统独立设置的系统，因此通过辅助消息处理系统可以减少目标消息消费系统的处理负担。
75.需要说明的是，目标消息消费系统可以执行第一种至第三种中的任意一种或多种消息控制策略，本技术对此不做具体限定。例如，标消息消费系统可以执行上述第二种和第三种，具体的，目标消息消费系统可确定优先级小于第一优先级的至少一个业务类型对应的预设时长之后，将确定出的预设时长发送给辅助消息处理系统，使得辅助消息处理系统可以对优先级小于第一优先级的至少一个业务类型对应的消息进行延迟处理。
76.在本技术实施例中，目标消息消费系统可以基于自身的缓存表中的消息的数量，确定目标消息消费系统是否存在消息积压，在缓存表中的消息的数量达到一定数量之后，可及时地采取消息控制策略，对消息进行处理，这样可以避免目标消息消费系统堆积消息，从而保证目标消息消费系统处理消息的及时性。并且，由于目标消息消费系统堆积消息的可能性更小，因此更有利于目标消息消费系统的运行的稳定性。
77.基于同一发明构思，本技术实施例提供一种消息处理装置，应用于与消息中间件通信的多个消息消费系统中的目标消息消费系统中。该消息处理装置可以设置在目标消息消费系统中，或者实现目标消息消费系统的功能。请参照图4，该装置包括：收发模块401，用于从消息中间件接收至少一个消息，至少一个消息是消息中间件从消息生产系统接收的；记录模块402，用于将至少一个消息记录目标消息消费系统的缓存表中；删除模块403，用于若目标消息消费系统已处理缓存表中的第一消息，则删除缓存表中记录的第一消息，第一消息为至少一个消息中的一个；确定模块404，用于确定缓存表中的记录的消息的总数量，以及基于总数量，确定目标消息消费系统是否存在消息积压。
78.在一种可能的实现方式中，确定模块404具体用于：若总数量大于第一数量，则确定目标消息消费系统存在消息积压，或者，若总数量大于第一数量，且目标消息消费系统处理缓存表中的消息的速率小于从消息中间件接收消息的速率，则确定目标消息消费系统存在消息积压；若总数量小于或等于第一数量，则确定目标消息消费系统不存在消息积压。
79.在一种可能的实施方式中，装置还包括输出模块405，输出模块还用于：在确定目标消息消费系统存在消息积压之后，输出提示信息，提示信息用于提示处理目标消息消费系统存在消息积压。
80.在一种可能的实现方式中，缓存表包括多个分表，其中每个分表用于记录多个业
memory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)、或者存储器502是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器502可以是上述存储器的组合。
89.需要说明的是，图5中的消息处理设备还可以实现图4中的消息处理装置的功能。
90.基于同一发明构思，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如前文论述的任一的消息处理方法。
91.基于同一发明构思，本技术实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如前文论述的任一的消息处理方法。
92.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
93.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
94.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
95.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
96.尽管已描述了本技术的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本技术范围的所有变更和修改。
97.显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。