CN113452774B - 消息推送方法、装置、设备及存储介质 - Google Patents

Abstract

本申请涉及一种消息推送方法、装置、设备及存储介质，其中方法应用于后端服务器，所述后端服务器部署为实例集群，所述消息推送方法包括：各实例同时从消息中间件中消费当前消息，所述当前消息是由负载均衡模块分发到后端服务器的目标实例，并由所述目标实例发送至消息中间件的，所述目标实例由负载均衡模块根据均衡策略确定；各实例均将消费到的当前消息发送至后端服务器的对应客户端，以使所述对应客户端接收当前与其建立连接的实例发送的当前消息。本申请能够将推送的消息准确发送至客户端，解决多实例部署的后端服务器不能准确推送消息给前端用户的问题。

Description

消息推送方法、装置、设备及存储介质

技术领域

本申请涉及消息推送方法、装置、设备及存储介质，属于数据处理技术领域。

背景技术

很多场景中，后端的业务执行完成后，需要对前端用户进行消息触达，保证消息高效、安全、可靠地推送到前端用户。

目前市面上常见的后端(单实例)给前端(web端用户)推送消息方案，通过使用WebSocket直接发送，如图1所示，服务A要发送消息给服务B的web端用户2，当只有一个服务B实例时，服务A通过API接口调用方式推送消息给服务B，此时web端2只能与服务B建立了连接，服务B直接通过WebSocket方式推送给web端2即可。该方案简单高效，清晰明了。

但单实例受限于硬件资源有限，随着用户数量增长，无法满足系统使用。为提升硬件资源使用率，增加系统吞吐量，服务B通常会扩展为多实例部署，服务A通过负载均衡将请求推送的消息分摊到服务B的不同服务实例上。

上述多实例部署的方案中，服务B在使用WebSocket与web端用户进行交互时，无法得知web端用户与哪一个服务实例建立了连接，不能准确的推送消息给web端用户。

发明内容

本申请提供了一种消息推送方法、装置、设备及存储介质，以解决多实例部署的后端服务器不能准确推送消息给前端用户的问题。

为解决上述技术问题，本申请提供如下技术方案：

本申请实施例的第一方面，提供了一种消息推送方法，应用于后端服务器，后端服务器部署为实例集群，本申请的消息推送方法包括：

各实例同时从消息中间件中消费当前消息，当前消息是由负载均衡模块分发到后端服务器的目标实例，并由目标实例发送至消息中间件的，目标实例由负载均衡模块根据均衡策略确定；

各实例均将消费到的当前消息发送至后端服务器的对应客户端，以使对应客户端接收当前与其建立连接的实例发送的当前消息。

本方案将分发至后端服务器目标实例的消息，发送至消息中间件，使得同一条消息可同时在每个实例中消费，且每个实例都会尝试将消息发给同一个客户端用户，当前与客户端建立正确连接的实例，消息成功发送。因此，后端服务器可以部署任意数量的实例，均能将消息准确推送至客户端用户，可有效解决多实例后端服务器无法与前端客户端正常通信的问题，同时大大提高系统的吞吐量。

可选地，在本申请第一方面的一种可能的实施方式中，消息中间件的消息类设置多个分区，每个分区通过内存数据库存储获取的消息队列，且通过内存数据库记录消息队列对应的消费位置。

本方案通过内存数据库暂存发布至分区的消息，并通过内存数据库记录消费位置，使得实例在消费消息时，可以根据记录的消费位置来获取消息，从而保证每条消息均能够被成功消费。

可选地，在本申请第一方面的一种可能的实施方式中，各实例同时从消息中间件中消费当前消息，包括：

对各分区，依次获取内存数据库中记录的对应分区的消息队列的消费位置；

为对应的分区创建消费线程，消费线程用以根据消费位置，从对应的分区的消息队列中获取待推送的当前消息；

解析当前消息携带的消息推送请求，得到待推送的客户端用户信息；

根据待推送的客户端用户信息，将当前消息发送给后端服务器的对应客户端；

更新内存数据库记录的消费位置。

本方案通过内存数据库记录消费位置，每个实例在每次消费完当前消息之后，均更新消费位置，可以保证下次从正确位置继续消费新的消息，避免消息漏消费或重复消费。

可选地，在本申请第一方面的一种可能的实施方式中，获取内存数据库中记录的对应分区的消息队列的消费位置之前，还包括：

获取消息中间件的分区信息；

若未获取到分区信息，则判定消息中间件存在分区异常，则停止从消息中间件中消费当前消息的步骤；

直到消息中间件更新分区信息，并获取到分区信息后，触发获取内存数据库中记录的对应分区的消息队列的消费位置的步骤。

本方案通过获取分区信息，可以判断消息中间件是否存在分区异常，这样可以避免各实例在分区异常的情况下，还不断的去消息中间件获取消息，从而减少计算资源的浪费，提高消息消费的效率。

可选地，在本申请第一方面的一种可能的实施方式中，为对应的分区创建消费线程之前，还包括：

若未获取到消费位置，则判定消息中间件为初始化运行，从当前分区对应的消息队列的初始位置开始消费消息。

第二方面提供一种消息推送方法，应用于负载均衡模块，方法包括：

监听用于请求向后端服务器对应客户端推送消息的消息推送请求，后端服务器部署为实例集群；

监听到消息推送请求后，获取待推送的当前消息，消息推送请求中包含客户端用户信息；

将当前消息携带消息推送请求分发至后端服务器的目标实例，以指示该目标实例将当前消息发送至消息中间件，以使实例集群中的各实例同时消费当前消息，并根据客户端用户信息将消费到的当前消息发送至后端服务器的对应客户端，以指示对应客户端接收当前与其建立连接的实例发送的当前消息。

本申请实施例的第三方面，提供一种消息推送装置，应用于后端服务器，后端服务器部署为实例集群，本申请实施例的消息推送装置包括：

消息消费模块，用于各实例同时从消息中间件中消费当前消息，当前消息是由负载均衡模块分发到后端服务器的目标实例，并由目标实例发送至消息中间件的，目标实例由负载均衡模块根据均衡策略确定；

消息发送模块，用于各实例均将消费到的当前消息发送至后端服务器的对应客户端，以使对应客户端接收当前与其建立连接的实例发送的当前消息。

本申请实施例的第四方面，提供一种消息推送装置，其特征在于，应用于负载均衡模块，本实施例的消息推送装置包括：

请求监听模块，用于监听用于请求向后端服务器对应客户端推送消息的的消息推送请求，后端服务器部署为实例集群；

消息获取模块，用于监听到消息推送请求后，获取待推送的当前消息，消息推送请求中包含客户端用户信息；

消息分发模块，用于将当前消息携带消息推送请求分发至后端服务器的目标实例，以指示该目标实例将当前消息发送至消息中间件，以使实例集群中的各实例同时消费当前消息，并根据客户端用户信息将消费到的当前消息发送至后端服务器的对应客户端，以指示对应客户端接收当前与其建立连接的实例发送的当前消息。

本申请实施例的第五方面，提供一种电子设备，包括处理器和存储器，存储器存储有计算机程序，计算机程序被处理器执行时，用于实现本申请实施例第一方面或第二方面的任一种可能的实施方式中消息推送方法的步骤。

本申请实施例的第六方面，提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时，用于实现本申请实施例第一方面或第二方面的任一种可能的实施方式中消息推送方法的步骤。

本申请将分发至后端服务器目标实例的消息，发送至消息中间件，使得同一条消息可同时在每个实例中消费，且每个实例都会尝试将消息发给同一个客户端用户，当前与客户端建立正确连接的实例，消息成功发送。因此，后端服务器可以部署任意数量的实例，均能将消息准确推送至客户端用户，可有效解决多实例后端服务器无法与前端客户端正常通信的问题，同时大大提高系统的吞吐量。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，并可依照说明书的内容予以实施，以下以本申请的较佳实施例并配合附图详细说明如后。

附图说明

图1是现有技术提供的单实例部署的后端服务器对应的消息推送系统的结构示意图；

图2是现有技术提供的多实例部署的后端服务器对应的消息推送系统的结构示意图；

图3是本申请一个实施例提供的消息推送方法及装置应用的消息推送系统的结构示意图；

图4是本申请一个实施例提供的消息推送方法的流程图；

图5是本申请一个实施例提供的各实例消费消息的算法流程图；

图6是本申请另一个实施例提供的消息推送方法的流程图；

图7是本申请一个实施例的消息推送装置的结构示意图；

图8是本申请一个实施例提供的消息推送装置的结构示意图；

图9是本申请一个实施例提供的电子设备的结构框图。

具体实施方式

以下实施例用于说明本申请，但不用来限制本申请的范围。

图2给出了现有消息推送系统的组成框图，服务B扩展为3个实例部署，服务A通过负载均衡模块，将各个待推送的消息分发到服务B的不同实例上进行处理。若服务A要推送消息给服务B的Web端2用户，因服务B并不知道此时web端2用户与哪个实例创建了消息连接，因此，无法得知需要由哪个实例来发送WebSocket消息，导致无法准确发送消息的问题。

如图2所示，例如，服务A推送的当前消息被分发至实例B3进行处理，但web端2用户此时与实例B2建立了消息连接，因此，实例B3的WebSocket通道未建立连接，web端2用户无法接收到实例B3发送的当前消息。

针对上述技术问题，本申请实施例提供一种消息推送方法和装置。图3是本申请一个实施例提供的实现消息推送方法及装置的消息推送系统的结构图，如图3所示，该消息推送系统包括：消息推送服务器101、负载均衡模块102、后端服务器103、消息中间件104和客户端105。

消息推送服务器101通过负载均衡模块102，将消息发送至后端服务器103进行处理。

后端服务器103部署为多个实例，例如可以部署三个实例，即实例B1、实例B2和实例B3。负载均衡模块102根据均衡策略，确定目标实例，并将消息分发至目标实例进行处理。例如，图3所示，根据均衡策略(例如，各实例的连接状态、资源占用率等)，当前将实例B3确定为目标实例，由目标实例B3将待推送的消息发送至消息中间件104中。当然，不同时刻，各实例的运行状况可能发生变化，负载均衡模块102也可能将实例B1或实例B2确定为目标实例。

图3中，消息中间件104前后示出的两个后端服务器103是同一个后端服务器103，这样表示只是为了便于体现消息推送的顺序。

客户端105可以有多个，客户端105为电子设备，例如可以为智能移动设备、台式计算机等，用户可以通过客户端105上的Web浏览器(如图3中的Web端)与后端服务器103中的实例建立连接。本实施例中的客户端105与后端服务器103的实例之间通过WebSocket协议通信。

负载均衡模块102监听消息推送服务器101的消息推送请求，当监听到消息推送服务器101有消息推送请求后，获取待推送的当前消息，并将当前消息分发到目标实例(例如，实例B3)上进行处理。

实例B3在接收到当前消息后，将当前消息发送至消息中间件104，由消息中间件104将当前消息携带消息推送请求广播发送至实例B1、B2、B3，实例B1、B2、B3同时消费到当前消息，消息推送请求中包含客户端用户信息。

各实例根据消息推送请求中包含的客户端用户信息，将消费到的当前消息均发送至对应的客户端(例如web端2)。本实施例中，实例B1、B2、B3均尝试给web端2发送WebSocket消息，此时Web端2正在与实例B2建立消息连接，因此，实例B1、B3消息发送失败，实例B2消息发送成功，当前消息最终成功推送至web端2。

通过本申请实施例的方案，后端服务器103可扩展为任意多个实例运行，均能将消息准确推送至Web端用户，可有效解决多实例后端服务器无法与前端Web端用户正常通信的问题，同时大大提高系统的吞吐量。

图4是本申请一个实施例提供的消息推送方法的流程图，下面参见图4介绍本申请消息推送方法的具体实施方案。本申请实施例提供的消息推送方法可以应用于图3所示消息推送系统的后端服务器103中。下面以后端服务器103中的各个实例为执行主体，对本申请实施例的消息推送方法进行说明。在本申请一实施例中，消息推送方法包括以下几个步骤：

S401:各实例同时从消息中间件中消费当前消息。

具体地，消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。

本实施例的后端服务器部署为多个实例，当前消息是由负载均衡模块分发到后端服务器的目标实例，并由目标实例发送至消息中间件的，其中的目标实例由负载均衡模块根据均衡策略确定。

负载均衡模块实时监听消息推送服务器的消息推送请求，并当监听到消息推送服务器的消息推送请求后，根据均衡策略，确定目标实例，然后将当前消息分发至目标实例进行处理。

本实施例当前消息携带消息推送请求，其中的消息推送请求中包含对应客户端用户信息。

本实施例的均衡策略包括：通过检查后端服务器各实例的连接状态、资源占用率等来确定目标实例。

S402：各实例均将消费到的当前消息发送至后端服务器的对应客户端，以使所述对应客户端接收当前与其建立连接的实例发送的当前消息。

具体地，本实施例设置消息中间件，目标实例将接收到的当前消息处理后，发送至消息中间件，后端服务器的各个实例(例如实例B1、B2、B3)从消息中间件中同时消费当前消息。

各实例根据当前消息携带的消息推送请求，获取客户端用户信息，然后，各实例均尝试通过WebSocket协议向客户端用户信息对应的客户端发送当前消息，若此时对应客户端与实例B2建立消息连接，那么，实例B2发送成功，B1、B3发送失败，对应客户端成功接收到当前消息。

通过本实施例的方案，后端服务器可以任意扩展实例，均能将待推送的消息准确推送至对应的客户端，而且通过扩展实例，也可以大大提高系统吞吐量。

可选地，本实施例中，消息中间件为Kafka(卡夫卡)。后端服务器各实例消费当前消息是基于Kafka和Redis实现的。其中，Kafka是一个开源流处理平台，属于一种高吞吐量的分布式发布订阅消息系统。Kafka具有高性能、持久化、多副本备份和横向扩展能力。生产者往消息队列里写消息，消费者从消息队列里取消息。

Redis是一个key-value存储系统，支持存储的value类型包括string(字符串)、list(链表)、set(集合)、zset(有序集合)和hash(哈希类型)。Redis还能周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。Redis具有很高的读写性能。

消息中间件还可以是ActiveMQ、RabbitMQ、RocketMQ或ZeroMQ等，内存数据库还可以是Memcached、SQLite、Microsoft SQL Server Compact等，本实施例对消息中间件和内存数据库的类型不做限定。

可选地，本实施例Kafka的Topic消息类设置至少一个Partition分区，每个Partition分区通过Redis内存数据库存储获取的消息队列，且通过Redis内存数据库记录消息队列对应的offset消费位置。

具体地，每条发布到Kafka的消息都有一个类别，这个类别即为Topic，一个Topic的消息即为一个类，不同的Topic之间是相互独立的。一个Topic又可以划分为一个或多个Partition分区，创建Topic消息类时，可以指定Partition分区的数量。

每个Partition分区存储一部分消息，供消费者消费，每个Partition分区以队列的形式存储消息。本实施例通过Redis来存储获取的消息队列。

每个Partition分区也都有各自的消费位置offset信息，消费者在消费消息的过程中需要记录自己消费了多少数据，即消费位置信息。

可选地，本实施例中，如图5所示，后端服务器的各实例同时从消息中间件中消费当前消息，并将消费到的当前消息发送至后端服务器的对应客户端，包括：

S501：对各分区，依次获取内存数据库中记录的对应分区的消息队列的消费位置。

负载均衡模块将接收到的消息分发至目标实例后，目标实例会将消息发送至Kafka消息中间件，消息中间件Kafka根据各个分区对应的Redis的存储状态，对接收到的消息在各分区之间进行分配。发送到Kafka消息中间件中的消息会以消息队列的形式保存在各Partition分区的Redis中。

各实例可以从Partition分区的Redis保存的消息队列中获取对应的消息。

因为每个Partition分区中都存储有消息，各实例在消费消息时，通过循环每个Partition分区，对每个Partition分区均按照消息队列的消费位置，读取消息。

在当前时刻，各实例首先获取当前Partition分区的Redis中记录的offset消费位置，根据offset消费位置可以确定当前要获取的消息。

在首次初始化运行时，各实例均未开始消费消息，因此，redis中尚未记录offset消费位置信息，各实例将获取不到offset消费位置，此时，各实例将从当前Partition分区对应的消息队列的初始位置开始消费消息。

S502：为对应的分区创建消费线程，消费线程用以根据消费位置，从对应的分区的消息队列中获取待推送的当前消息。

offset消费位置体现的是消息的消费进度，Partition分区中的每条消息由offset来表示它在这个Partition分区中的位置信息，这个offset不是该消息在Partition分区中的实际存储位置，而是逻辑上的一个值，它唯一确定了Partition分区中的一条消息。

因此，根据offset消费位置即可获取待消费的当前消息。

S503：解析当前消息携带的消息推送请求，得到待推送的客户端用户信息。

S504：根据所述待推送的客户端用户信息，将当前消息发送给后端服务器的对应客户端。

每个实例均将消费到的当前消息，通过WebSocket发送至后端服务器的对应客户端。与该客户端建立连接的实例，消息发送成功，而未建立连接的实例，消息发送失败。该客户端接收到当前消息。

S505：更新内存数据库记录的消费位置。

消费完当前消息之后，更新offset消费位置。当下次再从消息队列中获取消息时，可以根据更新的offset消费位置，再次执行S501-S504，以从正确的位置继续消费新的消息。

本实施例每次发送到消息中间件中的消息均以消息队列的形式保存至Redis中，并通过Redis记录offset消费位置，每个实例在每次消费完当前消息之后，均更新offset消费位置，因为各实例同时从消息中间件中消费同一消息，每个实例在消费完当前消息之后，更新的offset消费位置也能保持一致。本实施例可以保证每条消息能够被成功且唯一消费，避免同一条消息的重复消费或者消息的漏消费。

可选地，本实施例在步骤S501之后，还包括：

获取Kafka的Partition分区信息，以判定Kafka是否存在分区异常。如存在分区异常，则结束程序。

本实施例中，如果没有获取到Partition分区信息，则判定Kafka分区异常，在Kafka分区异常异常的情况下，结束程序执行过程。

因为每个Partition分区均对应一个消息队列，在获取到Partition分区信息的情况下，循环各个Partition分区。对于当前Partition分区，获取Redis中记录的offset消费位置，并从对应的消息队列中获取当前消息。

分区异常，通常是kafka消息主题topic未创建或因为其他原因导致topic丢失，运维人员可以手动创建topic来恢复使用，否则消息中间件kafka作为消息分发的核心功能，当kafka出现异常时，整个系统也处于故障状态，导致消息无法正常消费。

本实施例通过判断Kafka是否存在分区异常，可以避免各实例在分区异常的情况下，还不断的去Kafka获取消息，从而减少计算资源的浪费，提高消息消费的效率

综上所述，本方案将分发至后端服务器目标实例的消息，发送至消息中间件，使得同一条消息可同时在每个实例中消费，且每个实例都会尝试通过WebSocket发给同一个客户端用户，当前与客户端建立正确连接的实例，消息成功发送。因此，后端服务器可以部署任意数量的实例，均能将消息准确推送至客户端用户，可有效解决多实例后端服务器无法与前端客户端正常通信的问题，同时大大提高系统的吞吐量。

图6是本申请另一个实施例提供的消息推送方法的流程图，本申请实施例提供的消息推送方法可以应用于图3所示消息推送系统的负载均衡模块。下面以负载均衡模块为执行主体，对本申请实施例的消息推送方法进行说明。如图6所示，在本申请一实施例中，消息推送方法包括以下几个步骤：

S601：监听用于请求向后端服务器对应客户端推送消息的的消息推送请求，后端服务器部署为实例集群。

S602：监听到消息推送请求后，获取待推送的当前消息，消息推送请求中包含客户端用户信息。

S603：将当前消息携带消息推送请求分发至后端服务器的目标实例，以指示该目标实例将当前消息发送至消息中间件，以使各实例同时消费当前消息，并根据客户端用户信息将消费到的当前消息发送至后端服务器的对应客户端，以指示对应客户端接收当前与其建立连接的实例发送的当前消息。

该实施例提供的消息推送方法请参阅图3-图5消息推送方法实施例中的相关实施步骤，在此不再赘述。

本申请将分发至后端服务器目标实例的消息，发送至消息中间件，使得同一条消息可同时在每个实例中消费，且每个实例都会尝试将消息发给同一个客户端用户，当前与客户端建立正确连接的实例，消息成功发送。因此，后端服务器可以部署任意数量的实例，均能将消息准确推送至客户端用户，可有效解决多实例后端服务器无法与前端客户端正常通信的问题，同时大大提高系统的吞吐量。

图7是本申请一个实施例提供的消息推送装置的结构示意图，如图7所示，本实施例的消息推送装置包括：

消息消费模块，用于各实例同时从消息中间件中消费当前消息，当前消息是由负载均衡模块在监听到消息推送请求后分发到后端服务器的目标实例，并由目标实例发送至消息中间件的，目标实例由负载均衡模块根据均衡策略确定；

消息发送模块，用于各实例均将消费到的当前消息发送至后端服务器的对应客户端，以使对应客户端接收当前与其建立连接的实例发送的当前消息，消息推送请求中包含客户端用户信息。

图8是本申请另一个实施例提供的消息推送装置的结构示意图，如图8所示，本实施例的消息推送装置包括：

请求监听模块，用于监听用于请求向后端服务器对应客户端推送消息的的消息推送请求，后端服务器部署为多个实例；

消息获取模块，用于监听到消息推送请求后，获取待推送的当前消息，消息推送请求中包含客户端用户信息；

消息分发模块，用于将当前消息携带消息推送请求分发至后端服务器的目标实例，以指示该目标实例将当前消息发送至消息中间件，以使各实例同时消费当前消息，并将消费到的当前消息发送至后端服务器的对应客户端，以指示对应客户端接收当前与其建立连接的实例发送的当前消息。

上述两实施例提供的消息推送装置与对应的消息推送方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

需要说明的是：上述实施例中提供的消息推送装置在进行消息推送时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要将上述功能分配由不同的功能模块完成，即将消息推送装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

图9是本申请一个实施例提供的电子设备的框图，本实施例电子设备可以是桌上型计算机、笔记本电脑、掌上电脑以及云端服务器等计算设备，该计算机设备可以包括，但不限于，处理器和存储器。其中，

处理器可以包括一个或多个处理核心，比如：4核心处理器、6核心处理器等。处理器可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable GateArray，现场可编程门阵列)、PLA(Programmable LogicArray，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central Processing Unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器还可以包括AI(ArtificialIntelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。处理器是计算机设备的控制中心，利用各种接口和线路连接整个计算机设备的各个部分。

存储器可以包括高速随机存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡、闪存卡(Flash Card)、至少一个磁盘存储器件、内存器件、或其他易失性固态存储器件。

存储器上存储有计算机程序，计算机程序可在处理器上运行，处理器执行计算机程序时，实现本申请消息推送方法相关实施例中的所有或部分实施步骤，和/或文本中描述的其他内容。

本领域技术人员可以理解，图9仅仅是本申请实施例的一种可能的实现方式，其他实施方式中，还可以包括更多或更少的部件，或者组合某些部件，或者不同部件，本实施例对此不作限定。

可选地，本申请还提供有一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时用于实现上述任一实施例或实施方式中的消息推送方法的步骤。

可选地，本申请还提供有一种计算机程序产品，该计算机程序产品包括计算机可读存储介质，计算机可读存储介质中存储有程序，程序由处理器加载并执行以实现上述任一实施例或实施方式中的消息推送方法的步骤。

以上各实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上各实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种消息推送方法，其特征在于，应用于后端服务器，所述后端服务器部署为实例集群，所述消息推送方法包括：

各实例同时从消息中间件中消费当前消息，所述当前消息是由负载均衡模块分发到后端服务器的目标实例，并由所述目标实例发送至消息中间件的，所述目标实例由负载均衡模块根据均衡策略确定；

各实例均将消费到的当前消息发送至后端服务器的对应客户端，以使所述对应客户端接收当前与其建立连接的实例发送的当前消息。

2.根据权利要求1所述的方法，其特征在于，所述消息中间件的消息类设置多个分区，每个所述分区通过内存数据库存储获取的消息队列，且通过所述内存数据库记录所述消息队列对应的消费位置。

3.根据权利要求2所述的方法，其特征在于，所述各实例同时从消息中间件中消费当前消息，包括：

对各所述分区，依次获取所述内存数据库中记录的对应分区的消息队列的消费位置；

为对应的分区创建消费线程，所述消费线程用以根据所述消费位置，从对应的分区的消息队列中获取待推送的当前消息；

解析所述当前消息携带的消息推送请求，得到待推送的客户端用户信息；

根据所述待推送的客户端用户信息，将所述当前消息发送给后端服务器的对应客户端；

更新所述内存数据库记录的消费位置。

4.根据权利要求3所述的方法，其特征在于，所述获取所述内存数据库中记录的对应分区的消息队列的消费位置之前，还包括：

获取所述消息中间件的分区信息；

若未获取到所述分区信息，则判定消息中间件存在分区异常，则停止从所述消息中间件中消费所述当前消息的步骤；

直到所述消息中间件更新分区信息，并获取到所述分区信息后，触发所述获取所述内存数据库中记录的对应分区的消息队列的消费位置的步骤。

5.根据权利要求3所述的方法，其特征在于，所述为对应的分区创建消费线程之前，还包括：

若未获取到所述消费位置，则判定所述消息中间件为初始化运行，从当前分区对应的消息队列的初始位置开始消费消息。

6.一种消息推送方法，其特征在于，应用于负载均衡模块，所述方法包括：

监听用于请求向后端服务器对应客户端推送消息的消息推送请求，所述后端服务器部署为实例集群；

监听到所述消息推送请求后，获取待推送的当前消息，所述消息推送请求中包含客户端用户信息；

将所述当前消息携带所述消息推送请求分发至所述后端服务器的目标实例，以指示该所述目标实例将所述当前消息发送至消息中间件，以使所述实例集群中的各实例同时消费所述当前消息，并根据所述客户端用户信息将消费到的所述当前消息发送至所述后端服务器的对应客户端，以指示所述对应客户端接收当前与其建立连接的实例发送的所述当前消息。

7.一种消息推送装置，其特征在于，应用于后端服务器，所述后端服务器部署为实例集群，所述装置包括：

消息消费模块，用于各实例同时从消息中间件中消费当前消息，所述当前消息是由负载均衡模块分发到后端服务器的目标实例，并由所述目标实例发送至消息中间件的，所述目标实例由负载均衡模块根据均衡策略确定；

消息发送模块，用于各实例均将消费到的当前消息发送至后端服务器的对应客户端，以使所述对应客户端接收当前与其建立连接的实例发送的当前消息。

8.一种消息推送装置，其特征在于，应用于负载均衡模块，所述装置包括：

请求监听模块，用于监听用于请求向后端服务器对应客户端推送消息的的消息推送请求，所述后端服务器部署为实例集群；

消息获取模块，用于监听到所述消息推送请求后，获取待推送的当前消息，所述消息推送请求中包含客户端用户信息；

消息分发模块，用于将当前消息携带消息推送请求分发至后端服务器的目标实例，以指示该所述目标实例将所述当前消息发送至消息中间件，以使实例集群中的各实例同时消费所述当前消息，并根据所述客户端用户信息将消费到的当前消息发送至后端服务器的对应客户端，以指示所述对应客户端接收当前与其建立连接的实例发送的当前消息。

9.一种电子设备，包括处理器和存储器，所述存储器存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，用于实现如权利要求1至5任一项或如权利要求6所述消息推送方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，用于实现如权利要求1至5任一项或如权利要求6所述消息推送方法的步骤。

Images