CN110968430A - 基于消息队列的处理方法和消息队列 - Google Patents

Abstract

本发明公开了一种基于消息队列的处理方法和消息队列，涉及计算机技术领域。其中，所述方法包括：对唯一消费者应用的状态进行监测；对消息存储区存储的同一主题下的消息总量进行监测；在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产；其中，所述唯一生产者应用与所述唯一消费者应用隶属于同一主题。通过以上方法，不仅能够满足实际生活中对一对一的发布‑订阅模式的场景需求，而且能够有效解决消息在生产侧或消费侧大量积压的问题，进而有助于提高唯一生产者应用、唯一消费者应用的性能。

Description

基于消息队列的处理方法和消息队列

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于消息队列的处理方法和消息队列。

背景技术

在互联网和软件领域，消息队列已经成为一种常用的技术手段。消息队列的底层设计原理是“生产者-消费者”模式。消息的来源是生产者应用，生产者应用(或称为生产者程序)源源不断的生产消息并将生产的消息放入消息队列，消费者应用(或称为消费者程序)则从消息队列中获取消息进行消费。目前，消费者应用获取消息的方式主要有“推送”和“拉取”两种方式。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

第一、现有的消息队列，都是一对多的发布-订阅模式(即一个生产者应用对应多个消费者应用的模式)。然而，在现实情况中，有很多应用场景需要消息队列满足一对一的发布-订阅模式(即一个生产者应用对应一个消费者应用的模式)。显然，现有的消息队列并不能满足这些场景需求。

第二、在现有的消息队列中，当由于消费者应用出现异常等原因导致消息不能正常消费时，生产者应用还在源源不断地生产消息，很可能导致大量消息的积压。如果采用拉取模式获取消息，一般大量消息会在生产侧积压，进而可能影响生产者应用的性能；如果采用推送模式获取消息，一般大量消息会在消费侧积压，进而可能影响消费者应用的性能。

发明内容

有鉴于此，本发明提供一种基于消息队列的处理方法和消息队列，不仅能够满足实际生活中对一对一的发布-订阅模式的场景需求，而且能够有效解决消息在生产侧或消费侧大量积压的问题，进而有助于提高唯一生产者应用、唯一消费者应用的性能。

为实现上述目的，根据本发明的一个方面，提供了一种基于消息队列的处理方法，所述消息队列包括消息存储区。

本发明的基于消息队列的处理方法包括：对唯一消费者应用的状态进行监测；对消息存储区存储的同一主题下的消息总量进行监测；在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产；其中，所述唯一生产者应用与所述唯一消费者应用隶属于同一主题。

可选地，所述方法还包括：在所述向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产的步骤之后，若监测到所述唯一消费者应用恢复正常状态且所述消息总量小于预设阈值，则向所述唯一生产者应用发送恢复生产的通知，以使所述唯一生产者应用恢复消息的生产。

可选地，所述方法还包括：对唯一生产者应用和唯一消费者应用进行注册，以对注册后的唯一消费者应用执行所述对唯一消费者应用的状态进行监测的步骤，以及对注册后的唯一生产者应用执行所述向唯一生产者应用发送暂停生产的通知的步骤。

可选地，对唯一生产者应用进行注册的步骤包括：在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；在数据库不存在隶属于所述主题的生产者注册信息的情况下，向所述数据库写入生产者注册信息，并向所述生产者应用返回注册成功的信息；对唯一消费者应用进行注册的步骤包括：在接收到消费者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；在数据库存在隶属于所述主题的生产者注册信息、且不存在隶属于所述主题的消费者注册信息的情况下，向所述数据库写入消费者注册信息，并向所述消费者应用返回注册成功的信息。

可选地，所述对唯一生产者应用进行注册的步骤还包括：在数据库存在隶属于所述主题的生产者注册信息的情况下，向所述生产者应用返回注册失败的信息；所述对唯一消费者应用进行注册的步骤还包括：在数据库不存在隶属于所述主题的生产者注册信息，或者存在隶属于所述主题的消费者注册信息的情况下，向所述消费者应用返回注册失败的信息。

可选地，所述数据库为Redis；所述在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的步骤包括：根据所述主题名称生成第一键Key，然后根据第一Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

可选地，所述数据库为关系型数据库；所述在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的步骤包括：根据所述主题名称生成第一结构性查询语言SQL语句，然后根据所述第一SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

为实现上述目的，根据本发明的另一方面，提供了一种消息队列。

本发明的消息队列包括：消息存储区，用于存储唯一生产者应用生产的消息；第一监测模块，用于对唯一消费者应用的状态进行监测；第二监测模块，用于对消息存储区存储的同一主题下的消息总量进行监测；通知模块，用于在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产；其中，所述唯一生产者应用与所述唯一消费者应用隶属于同一主题。

可选地，所述通知模块，还用于：在执行所述向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产的操作之后，若所述唯一消费者应用恢复正常状态且所述消息总量小于预设阈值，则向所述唯一生产者应用发送恢复生产的通知，以使所述唯一生产者应用恢复消息的生产。

可选地，所述消息队列还包括：注册模块，用于对唯一生产者应用和唯一消费者应用进行注册，以对注册后的唯一消费者应用执行所述对唯一消费者应用的状态进行监测的操作，以及对注册后的唯一生产者应用执行所述向唯一生产者应用发送暂停生产的通知的操作。

可选地，所述注册模块对唯一生产者应用进行注册包括：所述注册模块在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；所述注册模块在数据库不存在隶属于所述主题的生产者注册信息的情况下，向所述数据库写入生产者注册信息，并向所述生产者应用返回注册成功的信息；所述注册模块对唯一消费者应用进行注册包括：所述注册模块在接收到消费者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；所述注册模块在数据库存在隶属于所述主题的生产者注册信息、且不存在隶属于所述主题的消费者注册信息的情况下，向所述数据库写入消费者注册信息，并向所述消费者应用返回注册成功的信息。

可选地，所述注册模块对唯一生产者应用进行注册还包括：所述注册模块在数据库存在隶属于所述主题的生产者注册信息的情况下，向所述生产者应用返回注册失败的信息；所述注册模块对唯一消费者应用进行注册还包括：所述注册模块在数据库不存在隶属于所述主题的生产者注册信息，或者存在隶属于所述主题的消费者注册信息的情况下，向所述消费者应用返回注册失败的信息。

可选地，所述数据库为Redis；所述注册模块在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的操作包括：所述注册模块根据所述主题名称生成第一键Key，然后根据第一Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

可选地，所述数据库为关系型数据库；所述注册模块在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的操作包括：所述注册模块根据所述主题名称生成第一结构性查询语言SQL语句，然后根据所述第一SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

为实现上述目的，根据本发明的再一个方面，提供了一种电子设备。

本发明的电子设备，包括：一个或多个处理器；以及，存储装置，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明的基于消息队列的处理方法。

为实现上述目的，根据本发明的又一个方面，提供了一种计算机可读介质。

本发明的计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明的基于消息队列的处理方法。

上述发明中的一个实施例具有如下优点或有益效果：通过对唯一消费者应用的状态以及消息存储区存储的同一主题下的消息总量进行监测，并在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知等步骤，不仅能够满足实际生活中对一对一的发布-订阅模式的场景需求，而且能够有效解决消息在生产侧或消费侧大量积压的问题，进而有助于提高唯一生产者应用、唯一消费者应用的性能。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明一个实施例的基于消息队列的处理方法的主要步骤示意图；

图2是根据本发明另一实施例的基于消息队列的处理方法的主要步骤示意图；

图3是根据本发明实施例的对唯一生产者应用进行注册的流程示意图；

图4是根据本发明实施例的对唯一消费者应用进行注册的流程示意图；

图5是根据本发明一个实施例的消息队列的主要模块示意图；

图6是根据本发明另一实施例的消息队列的主要模块示意图；

图7是本发明实施例可以应用于其中的示例性系统架构图；

图8是适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

需要指出的是，在不冲突的情况下，本发明中的实施例以及实施例中的特征可以相互组合。

在详细介绍本发明的实施例之前，首先对本发明的实施例涉及的部分技术术语进行说明。

Redis：一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

消息队列：一种处理消息的中间件。

图1是根据本发明一个实施例的基于消息队列的处理方法的主要步骤示意图。所述消息队列包括：消息存储区。如图1所示，本发明实施例的基于消息队列的处理方法包括：

步骤S101、对唯一消费者应用的状态进行监测。

其中，所述唯一消费者应用可理解为一个作为“消费者”的应用系统(或称为应用程序)，其可以是任意消费消息的应用系统。在该步骤中，消息队列可实时向唯一消费者应用发送获取状态的请求，并接收所述唯一消费者应用返回的状态信息。其中，所述状态信息可以为正常状态信息或异常状态信息。

步骤S102、对消息存储区存储的同一主题下的消息总量进行监测。

其中，所述消息存储区用于存储唯一生产者应用生产的消息。所述唯一生产者应用与所述唯一消费者应用隶属于同一主题(Topic)，可理解为一个作为“生产者”的应用系统，其可以是任意生产消息的应用系统。示例性地，所述消息存储区可采用队列形式，以保证消息的先进先出。具体实施时，消息存储区可采用多种队列实现方式，比如可采用Redis中的列表(list)，或者采用非关系型数据库(Nosql)中的表。

步骤S103、在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产。

其中，所述预设阈值可设置为“消息存储区的固定容量+容忍阈值”。比如，假设消息存储区的固定容量为1000条消息，容忍阈值为100条消息，则预设阈值可设置为1100条消息。

在本发明实施例中，通过对唯一消费者应用的状态以及消息存储区存储的同一主题下的消息总量进行监测，并在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知等步骤，不仅能够满足实际生活中对一对一的发布-订阅模式的场景需求，而且能够在异常情况下及时令唯一生产者应用暂停消息的生产，从而能够有效解决消息在生产侧或消费侧大量积压的问题，进而有助于提高唯一生产者应用、唯一消费者应用的性能。

图2是根据本发明另一实施例的基于消息队列的处理方法的主要步骤示意图。所述消息队列包括消息存储区。如图2所示，本发明实施例的基于消息队列的处理方法包括：

步骤S201、对唯一生产者应用和唯一消费者应用进行注册。

其中，所述唯一生产者应用和所述唯一消费者应用隶属于同一主题(Topic)，并且为一对一的关系。通过对同一主题下的唯一生产者应用、唯一消费者应用进行注册，能够保证后续流程中只针对注册后的唯一生产者应用、唯一消费者应用进行监测、控制，有助于实现一对一的发布-订阅模式，满足实际生活中对一对一的发布-订阅模式的场景需求。

步骤S202、向注册后的唯一生产者应用发送开始生产的通知，以使注册后的唯一生产者应用开始生产消息。

其中，步骤S202为可选步骤。在本发明的再一实施例中，也可以在步骤S201之后，直接执行步骤S203。

步骤S203、对注册后的唯一消费者应用的状态进行实时监测。

在该步骤中，消息队列可实时向唯一消费者应用发送获取状态的请求，并接收所述唯一消费者应用返回的状态信息。其中，所述状态信息可以为正常状态信息或异常状态信息。

步骤S204、对消息存储区存储的同一主题下的消息总量进行实时监测。

其中，所述消息存储区用于存储唯一生产者应用生产的消息。所述唯一生产者应用与所述唯一消费者应用隶属于同一主题(Topic)，可理解为作为“生产者”的应用系统，其可以是任意生产消息的应用系统。示例性地，所述消息存储区可采用队列形式，以保证消息的先进先出。具体实施时，消息存储区可采用多种队列实现方式，比如可采用Redis中的列表(list)，或者采用非关系型数据库(Nosql)中的表。

接下来，可根据步骤S203、步骤S204中的监测结果判断注册后的唯一消费者应用是否为异常状态、判断消息总量是否大于等于预设阈值。其中，所述预设阈值可设置为“消息存储区的固定容量+容忍阈值”。比如，假设消息存储区的固定容量为1000条消息，容忍阈值为100条消息，则预设阈值可设置为1100条消息。若注册后的唯一消费者应用为异常状态或者消息总量大于等于预设阈值，执行步骤S205；否则，执行步骤S206。

步骤S205、向注册后的唯一生产者应用发送暂停生产的通知，以使注册后的唯一生产者应用暂停消息的生产。

步骤S206、不向注册后的唯一生产者应用发送暂停生产的通知。

接下来，可继续根据步骤S203、步骤S204进行实时监测，并根据监测结果判断注册后的唯一消费者应用是否恢复正常状态、判断消息总量是否小于预设阈值。若注册后的唯一消费者应用恢复正常状态且消息总量小于预设阈值，执行步骤S207；否则，执行步骤S208。

步骤S207、向注册后的唯一生产者应用发送恢复生产的通知，以使注册后的唯一生产者应用恢复消息的生产。

步骤S208、不向注册后的唯一生产者应用发送恢复生产的通知。

在本发明实施例中，通过以上步骤能够在异常情况下及时令唯一生产者应用暂停消息的生产，并在异常解除后及时令唯一生产者应用恢复消息的生产，不仅能够有效解决消息在生产侧或消费侧大量积压的问题，有助于提高唯一生产者应用、唯一消费者应用的性能，而且有助于提高消息发布-订阅的处理效率。另外，通过对唯一生产者应用、唯一消费者应用进行注册，还能严格保证一对一的发布-订阅模式，更好地满足实际生活中对一对一的发布-订阅模式的场景需求。

下面结合图3、图4对步骤S201中的注册流程进行详细说明。图3是根据本发明实施例的对唯一生产者应用进行注册的流程示意图。如图3所示，本发明实施例的对唯一生产者应用进行注册的流程包括：

步骤S301、接收生产者应用的注册请求。

其中，所述生产者应用的注册请求包括主题(Topic)名称。

步骤S302、根据所述注册请求携带的主题名称查询数据库。

接下来，可根据步骤S302的查询结果判断数据库是否已存在该主题下的生产者注册信息。若数据库不存在该主题下的生产者注册信息，执行步骤S303；否则，执行步骤S304。

在一可选实施方式中，所述数据库可以为Redis。在该可选实施方式中，步骤S302包括：根据所述主题名称生成第一Key(键)，然后根据第一Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

例如，可根据下式生成第一Key：第一Key＝第一固定前缀+主题名称。如主题名称为testTopic123、第一固定前缀为registerSingleProducer，则生成的第一Key可以为“registerSingleProducer testTopic123”。然后，根据第一Key“registerSingleProducertestTopic123”查询Redis。如果Redis中已存在第一Key，说明Redis中已存在隶属于所述主题的生产者注册信息。如果Redis中不存在第一Key，说明Redis中不存在隶属于所述主题的生产者注册信息。

在另一可选实施方式中，所述数据库也可以为关系型数据库，比如Mysql、Oracle或其他关系型数据库。在该可选实施方式中，需要在关系型数据库中创建注册元数据表，以便于后续存储唯一生产者应用、唯一消费者应用的注册信息。在该可选实施方式中，步骤S302可包括：根据所述主题名称生成第一SQL语句，然后根据所述第一SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

示例性地，所述注册元数据表可包括主题名称、唯一生产者应用注册状态、唯一消费者应用注册状态、唯一生产者应用注册时间、唯一消费者应用注册时间等字段。其中，唯一生产者应用注册状态、唯一消费者应用注册状态均可包括：已注册状态(可用1表示)、未注册状态(可用0表示)。在该示例中，假设注册元数据表为table1，主题名称为“testTopic123”，第一SQL语句可表示为：select count(1)from table1 where topicName＝testTopic123and singleProducerRegister＝1。如果第一SQL语句的查询结果为1，说明关系型数据库中已存在隶属于所述主题的生产者注册信息；否则，说明关系型数据库中不存在隶属于所述主题的生产者注册信息。

步骤S303、向数据库写入生产者注册信息，并向所述生产者应用返回注册成功的信息。

当数据库为Redis时，所述生产者注册信息可采取键值对的存储形式。比如，假设第一Key为“registerSingleProducer testTopic123”，生产者注册信息可表示成：Key＝registerSingleProducer testTopic123，Value＝456。

当数据库为关系型数据库时，生产者注册信息可采取注册元数据表的存储形式。假设注册元数据表为table1、主题名称为testTopic123，当前时间为2018.09.25，则可通过如下SQL语句将生产者注册信息写入注册元数据表中：insert into table1(topicName,singleProducerRegister,singleProducerRegisterTime)values(testTopic123,1,2018.09.25)。

步骤S304、向所述生产者应用返回注册失败的信息。

在本发明实施例中，通过以上步骤实现了对唯一生产者应用进行注册的流程，能严格保证同一主题下只注册唯一生产者应用，有助于实现一对一的发布-订阅模式。

图4是根据本发明实施例的对唯一消费者应用进行注册的流程示意图。如图4所示，本发明实施例的对唯一消费者应用进行注册的流程包括：

步骤S401、接收消费者应用的注册请求。

其中，所述消费者应用的注册请求包括主题(Topic)名称。

步骤S402、根据所述注册请求携带的主题名称查询数据库。

接下来，可根据步骤S402的查询结果判断数据库是否已存在该主题下的生产者注册信息。若数据库存在该主题下的生产者注册信息，执行步骤S403；否则，执行步骤S404。

在一可选实施方式中，所述数据库可以为Redis。在该可选实施方式中，步骤S402包括：根据所述主题名称生成第一Key，然后根据第一Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

在另一可选实施方式中，所述数据库也可以为关系型数据库，比如Mysql、Oracle或其他关系型数据库。在该可选实施方式中，需要在关系型数据库中创建注册元数据表，以便于后续存储唯一生产者应用和唯一消费者应用的注册信息。在该可选实施方式中，步骤S402可包括：根据所述主题名称生成第一SQL语句，然后根据所述第一SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

步骤S403、根据所述注册请求携带的主题名称查询数据库。

接下来，根据步骤S403的查询结果判断数据库是否已存在该主题下的消费者注册信息。若数据库不存在该主题下的消费者注册信息，执行步骤S405；否则，执行步骤S404。

在一可选实施方式中，所述数据库可以为Redis。在该可选实施方式中，步骤S403包括：根据所述主题名称生成第二Key，然后根据第二Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的消费者注册信息。

例如，可根据下式生成第二Key：第二Key＝第二固定前缀+主题名称。如果主题名称为testTopic123、第二固定前缀为registerSingleConsumer，那么生成的第二key可以表示为“registerSingleConsumer testTopic123”。接下来，可根据第二Key“registerSingleConsumer testTopic123”查询Redis。如果Redis中已存在第二Key，说明Redis中已存在隶属于所述主题的消费者注册信息。如果Redis中不存在第二Key，说明Redis中不存在隶属于所述主题的消费者注册信息。

在另一可选实施方式中，所述数据库也可以为关系型数据库。在该可选实施方式中，步骤S403可包括：根据所述主题名称生成第二SQL语句，然后根据所述第二SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的消费者注册信息。

示例性地，所述注册元数据表可包括主题名称、唯一生产者应用注册状态、唯一消费者应用注册状态、唯一生产者应用注册时间、唯一消费者应用注册时间等字段。其中，唯一生产者应用注册状态、唯一消费者应用注册状态均可包括：已注册状态(可用1表示)、未注册状态(可用0表示)。在该示例中，假设注册元数据表为table1，主题名称为“testTopic123”，第二SQL语句可表示为：select count(1)from table1 where topicName＝testTopic123and singleConsumerRegister＝1。如果第二SQL语句的查询结果为1，说明关系型数据库中已存在隶属于所述主题的消费者注册信息；否则，说明关系型数据库中不存在隶属于所述主题的消费者注册信息。

步骤S404、向所述消费者应用返回注册失败的信息。

步骤S405、向数据库写入消费者注册信息，并向所述消费者应用返回注册成功的信息。

当数据库为Redis时，所述消费者注册信息可采取键值对的存储形式。其中，该键值对中的Value值可以为任意值。假设第二Key为“registerSingleConsumertestTopic123”，消费者注册信息可表示成：Key＝registerSingleConsumertestTopic123，Value＝789。

当数据库为关系型数据库时，消费者注册信息可采取注册元数据表的存储形式。假设注册元数据表为table1、主题名称为testTopic123，当前时间为2018.09.25，则可通过如下SQL语句写入消费者注册信息：update table1 set singleConsumerRegister＝1,singleConsumerRegistertime＝2018.09.25where topicName＝testTopic123。

在本发明实施例中，通过以上步骤实现了对唯一消费者应用进行注册的流程，能严格保证同一主题下只注册唯一消费者应用，有助于实现一对一的发布-订阅模式。

图5是根据本发明一个实施例的消息队列的主要模块示意图。如图5所示，本发明实施例的消息队列500包括：消息存储区501、第一监测模块502、第二监测模块503、通知模块504。

消息存储区501，用于存储唯一生产者应用生产的消息。

其中，所述唯一生产者应用与唯一消费者应用隶属于同一主题(Topic)。唯一生产者应用可理解为作为“生产者”的应用系统，其可以是任意生产消息的应用系统。示例性地，所述消息存储区可采用队列形式，以保证消息的先进先出。具体实施时，消息存储区可采用多种队列实现方式，比如可采用Redis中的列表(list)，或者采用非关系型数据库(Nosql)中的表。

第一监测模块502，用于对唯一消费者应用的状态进行监测。

其中，所述唯一消费者应用可理解为一个作为“消费者”的应用系统(或称为应用程序)，其可以是任意消费消息的应用系统。示例性地，第一监测模块502可实时向唯一消费者应用发送获取状态的请求，并接收所述唯一消费者应用返回的状态信息。其中，所述状态信息可以为正常状态信息或异常状态信息。

第二监测模块503，用于对消息存储区存储的同一主题下的消息总量进行监测。

通知模块504，用于在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产。

其中，所述预设阈值可设置为“消息存储区的固定容量+容忍阈值”。比如，假设消息存储区的固定容量为1000条消息，容忍阈值为100条消息，则预设阈值可设置为1100条消息。

在本发明实施例的装置中，通过第一监测模块、第二监测模块对唯一消费者应用的状态以及消息存储区存储的同一主题下的消息总量进行监测，并在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，通过通知模块向唯一生产者应用发送暂停生产的通知等步骤，能够在异常情况下及时令唯一生产者应用暂停消息的生产，从而能够有效解决消息在生产侧或消费侧大量积压的问题，进而有助于提高唯一生产者应用、唯一消费者应用的性能。

图6是根据本发明另一实施例的消息队列的主要模块示意图。如图6所示，本发明实施例的消息队列600包括：注册模块601、消息存储区602、第一监测模块603、第二监测模块604、通知模块605。

注册模块601，用于对唯一生产者应用和唯一消费者应用进行注册。

其中，所述唯一生产者应用和所述唯一消费者应用隶属于同一主题(Topic)，并且为一对一的关系。通过对同一主题下的唯一生产者应用、唯一消费者应用进行注册，能够保证后续流程中只针对注册后的唯一生产者应用、唯一消费者应用进行监测、控制，有助于实现一对一的发布-订阅模式，满足实际生活中对一对一的发布-订阅模式的场景需求。

示例性地，注册模块601对唯一生产者应用进行注册可包括：注册模块601在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；注册模块601在数据库不存在隶属于所述主题的生产者注册信息的情况下，向所述数据库写入生产者注册信息，并向所述生产者应用返回注册成功的信息；注册模块601在数据库存在隶属于所述主题的生产者注册信息的情况下，向所述生产者应用返回注册失败的信息。

进一步，注册模块601对唯一消费者应用进行注册可包括：注册模块601在接收到消费者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；注册模块601在数据库存在隶属于所述主题的生产者注册信息、且不存在隶属于所述主题的消费者注册信息的情况下，向所述数据库写入消费者注册信息，并向所述消费者应用返回注册成功的信息；注册模块601在数据库不存在隶属于所述主题的生产者注册信息，或者存在隶属于所述主题的消费者注册信息的情况下，向所述消费者应用返回注册失败的信息。

在一可选实施方式中，所述数据库为Redis。在该可选实施方式中，注册模块601在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库包括：注册模块601根据所述主题名称生成第一Key(键)，然后根据第一Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

例如，注册模块601可根据下式生成第一Key：第一Key＝第一固定前缀+主题名称。如主题名称为testTopic123、第一固定前缀为registerSingleProducer，则生成的第一Key可以为“registerSingleProducer testTopic123”。然后，根据第一Key“registerSingleProducer testTopic123”查询Redis。如果Redis中已存在第一Key，说明Redis中已存在隶属于所述主题的生产者注册信息。如果Redis中不存在第一Key，说明Redis中不存在隶属于所述主题的生产者注册信息。

在另一可选实施方式中，所述数据库为关系型数据库，比如Mysql、Oracle或其他关系型数据库。在该可选实施方式中，需要在关系型数据库中创建注册元数据表，以便于后续存储唯一生产者应用、唯一消费者应用的注册信息。在该可选实施方式中，注册模块601在接收到唯一生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库可包括：注册模块601根据所述主题名称生成第一SQL语句，然后根据所述第一SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

示例性地，所述注册元数据表可包括主题名称、唯一生产者应用注册状态、唯一消费者应用注册状态、唯一生产者应用注册时间、唯一消费者应用注册时间等字段。其中，唯一生产者应用注册状态、唯一消费者应用注册状态均可包括：已注册状态(可用1表示)、未注册状态(可用0表示)。在该示例中，假设注册元数据表为table1，主题名称为“testTopic123”，注册模块601生成的第一SQL语句可表示为：select count(1)fromtable1where topicName＝testTopic123and singleProducerRegister＝1。如果第一SQL语句的查询结果为1，说明关系型数据库中已存在隶属于所述主题的生产者注册信息；否则，说明关系型数据库中不存在隶属于所述主题的生产者注册信息。

消息存储区602，用于存储注册后的唯一生产者应用生产出的消息。示例性地，消息存储区602可采用队列形式，以保证消息的先进先出。具体实施时，消息存储区602可采用多种队列实现方式，比如可采用Redis中的列表(list)，或者采用非关系型数据库(Nosql)中的表。

第一监测模块603，用于对注册后的唯一消费者应用的状态进行实时监测。具体来说，第一监测模块603可实时向唯一消费者应用发送获取状态的请求，并接收所述唯一消费者应用返回的状态信息。其中，所述状态信息可以为正常状态信息或异常状态信息。

第二监测模块604，用于对消息存储区602存储的同一主题下的消息总量进行实时监测。

其中，所述注册后的唯一生产者应用与所述注册后的唯一消费者应用隶属于所述同一主题(Topic)。在本发明实施例中，可根据第一监测模块、第二监测模块的监测结果判断注册后的唯一消费者应用是否为异常状态、判断消息总量是否大于等于预设阈值。在注册后的唯一消费者应用为异常状态或者消息总量大于等于预设阈值的情况下，可通过通知模块605向唯一生产者应用发送暂停生产的通知。其中，所述预设阈值可设置为“消息存储区的固定容量+容忍阈值”。比如，假设消息存储区的固定容量为1000条消息，容忍阈值为100条消息，则预设阈值可设置为1100条消息。

通知模块605，用于在监测到所述注册后的唯一消费者应用为异常状态，或者所述消息总量大于等于预设阈值的情况下，向注册后的唯一生产者应用发送暂停生产的通知，以使所述注册后的唯一生产者应用暂停消息的生产。

在唯一生产者应用暂停生产之后，可继续通过第一监测模块、第二监测模块进行实时监测，并根据监测结果判断注册后的唯一消费者应用是否恢复正常状态、判断消息总量是否小于预设阈值。在注册后的唯一消费者应用恢复正常状态且消息总量小于预设阈值的情况下，可通过通知模块605向唯一生产者应用发送恢复生产的通知。进一步，通知模块605，还用于向注册后的唯一生产者应用发送恢复生产的通知，以使注册后的唯一生产者应用恢复消息的生产。

在本发明实施例中，通过以上装置能够在异常情况下及时令唯一生产者应用暂停消息的生产，并在异常解除后及时令唯一生产者应用恢复消息的生产，不仅能够有效解决消息在生产侧或消费侧大量积压的问题，有助于提高唯一生产者应用、唯一消费者应用的性能，而且有助于提高消息发布-订阅的处理效率。另外，通过以上装置对唯一生产者应用、唯一消费者应用进行注册，还能严格保证一对一的发布-订阅模式，更好地满足实际生活中对一对一的发布-订阅模式的场景需求。

图7是本发明实施例可以应用于其中的示例性系统架构图之一。如图7所示，本发明实施例的示例性架构包括：唯一生产者应用701、消息队列702、唯一消费者应用703。

唯一生产者应用701，可理解为一个作为“生产者”的应用系统，用于生产消息。根据业务场景的不同，唯一生产者应用701的实现方式也不同。唯一生产者应用701与唯一消费者应用703属于同一主题(Topic)，两者为一对一的关系。唯一生产者应用701可将生产出的消息存入消息队列702中的消息存储区。

唯一消费者应用703，可理解为一个作为“消费者”的应用系统，用于消费消息。唯一消费者应用703可通过拉取模式或推送模式从消息队列702中的消息存储区获取消息并进行消费。

消息队列702，主要包括：消息存储区、第一监测模块、第二监测模块和通知模块。另外，消息队列还可包括注册模块(图7未示出)。消息队列702可用于对唯一生产者应用701和唯一消费者应用703进行注册；对唯一消费者应用703的状态进行监测；对消息存储区存储的同一主题下的消息总量进行监测；以及在监测到唯一消费者应用703为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用701发送暂停生产的通知，以使唯一生产者应用701暂停消息的生产。

在本发明实施例中，通过以上系统架构能够有效解决消息在生产侧或消费侧大量积压的问题，有助于提高唯一生产者应用、唯一消费者应用的性能，而且有助于提高消息发布-订阅的处理效率。另外，通过以上系统架构还能保证一对一的发布-订阅模式，满足实际生活中对一对一的发布-订阅模式的场景需求。

图8示出了适于用来实现本发明实施例的终端设备的计算机系统800的结构示意图。图8示出的系统仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，计算机系统800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM 803中，还存储有系统800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括消息存储区、第一监测模块、第二监测模块、通知模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，消息存储区还可以被描述为“存储唯一生产者应用生产出的消息的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备执行以下流程：对唯一消费者应用的状态进行监测；对消息存储区存储的同一主题下的消息总量进行监测；在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产；其中，所述唯一生产者应用与所述唯一消费者应用隶属于同一主题。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (16)

1.一种基于消息队列的处理方法，其特征在于，所述消息队列包括消息存储区，所述方法包括：

对唯一消费者应用的状态进行监测；

对消息存储区存储的同一主题下的消息总量进行监测；

在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产；其中，所述唯一生产者应用与所述唯一消费者应用隶属于同一主题。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产的步骤之后，若监测到所述唯一消费者应用恢复正常状态且所述消息总量小于预设阈值，则向所述唯一生产者应用发送恢复生产的通知，以使所述唯一生产者应用恢复消息的生产。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

对唯一生产者应用和唯一消费者应用进行注册，以对注册后的唯一消费者应用执行所述对唯一消费者应用的状态进行监测的步骤，以及对注册后的唯一生产者应用执行所述向唯一生产者应用发送暂停生产的通知的步骤。

4.根据权利要求3所述的方法，其特征在于，对唯一生产者应用进行注册的步骤包括：

在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；在数据库不存在隶属于所述主题的生产者注册信息的情况下，向所述数据库写入生产者注册信息，并向所述生产者应用返回注册成功的信息；

对唯一消费者应用进行注册的步骤包括：

在接收到消费者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；在数据库存在隶属于所述主题的生产者注册信息、且不存在隶属于所述主题的消费者注册信息的情况下，向所述数据库写入消费者注册信息，并向所述消费者应用返回注册成功的信息。

5.根据权利要求4所述的方法，其特征在于，所述对唯一生产者应用进行注册的步骤还包括：

在数据库存在隶属于所述主题的生产者注册信息的情况下，向所述生产者应用返回注册失败的信息；

所述对唯一消费者应用进行注册的步骤还包括：

在数据库不存在隶属于所述主题的生产者注册信息，或者存在隶属于所述主题的消费者注册信息的情况下，向所述消费者应用返回注册失败的信息。

6.根据权利要求4所述的方法，其特征在于，所述数据库为Redis；所述在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的步骤包括：

根据所述主题名称生成第一键Key，然后根据第一Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

7.根据权利要求4所述的方法，其特征在于，所述数据库为关系型数据库；所述在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的步骤包括：

根据所述主题名称生成第一结构性查询语言SQL语句，然后根据所述第一SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

8.一种消息队列，其特征在于，所述消息队列包括：

消息存储区，用于存储唯一生产者应用生产的消息；

第一监测模块，用于对唯一消费者应用的状态进行监测；

第二监测模块，用于对消息存储区存储的同一主题下的消息总量进行监测；

通知模块，用于在监测到所述唯一消费者应用为异常状态，和/或，所述消息总量大于等于预设阈值的情况下，向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产；其中，所述唯一生产者应用与所述唯一消费者应用隶属于同一主题。

9.根据权利要求8所述的消息队列，其特征在于，所述通知模块，还用于：

在执行所述向唯一生产者应用发送暂停生产的通知，以使所述唯一生产者应用暂停消息的生产的操作之后，若所述唯一消费者应用恢复正常状态且所述消息总量小于预设阈值，则向所述唯一生产者应用发送恢复生产的通知，以使所述唯一生产者应用恢复消息的生产。

10.根据权利要求8所述的消息队列，其特征在于，所述消息队列还包括：

注册模块，用于对唯一生产者应用和唯一消费者应用进行注册，以对注册后的唯一消费者应用执行所述对唯一消费者应用的状态进行监测的操作，以及对注册后的唯一生产者应用执行所述向唯一生产者应用发送暂停生产的通知的操作。

11.根据权利要求10所述的消息队列，其特征在于，所述注册模块对唯一生产者应用进行注册包括：

所述注册模块在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；所述注册模块在数据库不存在隶属于所述主题的生产者注册信息的情况下，向所述数据库写入生产者注册信息，并向所述生产者应用返回注册成功的信息；

所述注册模块对唯一消费者应用进行注册包括：

所述注册模块在接收到消费者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库；所述注册模块在数据库存在隶属于所述主题的生产者注册信息、且不存在隶属于所述主题的消费者注册信息的情况下，向所述数据库写入消费者注册信息，并向所述消费者应用返回注册成功的信息。

12.根据权利要求11所述的消息队列，其特征在于，所述注册模块对唯一生产者应用进行注册还包括：

所述注册模块在数据库存在隶属于所述主题的生产者注册信息的情况下，向所述生产者应用返回注册失败的信息；

所述注册模块对唯一消费者应用进行注册还包括：

所述注册模块在数据库不存在隶属于所述主题的生产者注册信息，或者存在隶属于所述主题的消费者注册信息的情况下，向所述消费者应用返回注册失败的信息。

13.根据权利要求11所述的消息队列，其特征在于，所述数据库为Redis；所述注册模块在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的操作包括：

所述注册模块根据所述主题名称生成第一键Key，然后根据第一Key查询Redis，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

14.根据权利要求11所述的消息队列，其特征在于，所述数据库为关系型数据库；所述注册模块在接收到生产者应用的注册请求后，根据所述注册请求携带的主题名称查询数据库的操作包括：

所述注册模块根据所述主题名称生成第一结构性查询语言SQL语句，然后根据所述第一SQL语句查询关系型数据库，以根据查询结果判断是否存在隶属于所述主题的生产者注册信息。

15.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1至7中任一所述的方法。

16.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至7中任一所述的方法。

Images