CN110365749B - 消息推送方法、消息推送***和一种存储介质 - Google Patents

Abstract

本发明公开了一种消息推送方法、消息推送***和一种存储介质，其中消息推送方法包括：消息队列接收消息源推送的订单消息，将所述订单消息推送至订阅推送服务的推送节点；所述推送节点在接收到所述订单消息后，等待店铺端连接后将所述订单详情推送至所述店铺端。本发明解决了传统轮循方法中存在的，资源浪费、消息实时性较差的情况，可以实现即时消息推送；对店铺网络架构也无需额外的技术要求，消息即时性、准确性也可以得到保障。

Description

消息推送方法、消息推送***和一种存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种消息推送方法、消息推送***和一种存储介质。

背景技术

当客户端数据来源在云端(或者用户端)，并且不确定何时会产生数据，比如店铺端从云端获取各渠道互联网订单时，通常采用轮循的方式，主动、定时地向Web端请求，并在本地缓存，在下一次请求后，再将本地缓存的数据与新数据进行比较，筛选出已经处理过的数据，避免重复处理；另一种方式是使用推送技术，但通常前提是店铺内部网络可以直接寻址。

然而，对于使用轮循方式，当客户端基数较大时，会产生巨量的无用请求，业务不繁忙时段轮循也不会间断，造成不必要的资源开销；同时，业务繁忙时段，可能由于轮循周期较长，影响消息实时性，即，轮循周期越短，实时性越好，资源浪费越多；轮循周期越长，实时性越差，资源浪费越少。而且，传统店铺的网络质量并不理想，轮循产生的流量开销很高，对使用3G、4G网络，VPN网络，流量包月网络的店铺而言会产生额外的成本。对于不能直接寻址的店铺网络架构，目前没有较为理想的实时推送方法。

发明内容

有鉴于此，本发明实施例提供了一种消息推送方法、一种消息推送***以及一种计算机可读的存储介质，能够解决了传统轮循方法中存在的，资源浪费、消息实时性较差的情况，实现即时消息推送。

本发明的第一方面提供一种消息推送方法，其包括：

消息队列接收消息源推送的订单消息，将所述订单消息推送至订阅推送服务的推送节点；

所述推送节点在接收到所述订单消息后，等待店铺端连接后将所述订单消息推送至所述店铺端。

所述消息推送方法的一些实施例中，所述消息队列采用分布式方式部署的消息队列集群。

所述消息推送方法的一些实施例中，所述消息队列集群中的各个消息队列绑定在广播模式的交换器下，通过所述交换器接收所述订单消息。

所述消息推送方法的一些实施例中，所述推送节点在将所述订单消息推送至所述店铺端之后，还包括：接收所述店铺端返回的推送成功的信息，对所述订单消息进行已推送标记；

并且，所述消息队列集群中的其他推送节点在识别到所述已推送标记后删除所述订单消息。

所述消息推送方法的一些实施例中，所述推送节点在将所述订单详情推送至所述店铺端的过程中，所述推送节点在接收到所述订单消息后，解析出所述订单消息指向的所述店铺端的目的店铺，在判断所述目的店铺在线后，将所述订单消息推送至所述目的店铺。

所述消息推送方法的一些实施例中，所述消息源通过Web API将消息推送至消息队列。

所述消息推送方法的一些实施例中，所述店铺端通过前置分流设施，与推送节点建立常连接。

本发明的第二方面提供了一种消息推送***，其包括消息队列和推送节点；所述消息队列用于接收消息源推送的订单消息，将所述订单消息推送至订阅推送服务的推送节点；所述推送节点用于在接收到所述订单消息后，等待店铺端连接后将所述订单消息推送至所述店铺端。

所述消息推送***的一些实施例中，所述推送节点采用虚拟主机，推送所述订单消息，且所述虚拟主机设置在店铺网络的DMZ区域。

本发明的第三方面提供了一种计算机可读的存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现所述消息推送方法。

本发明解决了传统轮循方法中存在的，资源浪费、消息实时性较差的情况，可以实现即时消息推送；对店铺网络架构也无需额外的技术要求，消息即时性、准确性也可以得到保障。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1显示了根据本发明实施例的消息推送方法的示例性业务消息流转示意图。

图2显示了根据本发明实施例的消息推送***的示例性网络拓扑图。

图3显示了根据本发明实施例的消息推送***的示例性***框架图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的实施方式；相反，提供这些实施方式使得本发明将全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的结构，因而将省略对它们的重复描述。

所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员应意识到，没有特定细节中的一个或更多，或者采用其它的方法、组元、材料等，也可以实践本发明的技术方案。在某些情况下，不详细示出或描述公知结构、材料或者操作以避免模糊本发明。

下面结合附图和实施例对本发明的技术内容进行进一步地说明。

本发明为解决传统轮循方法中存在的，资源浪费、消息实时性较差的情况，提供了一种基于店铺复杂网络的消息实时推送的方法和***，可以实现即时消息推送，对店铺网络架构也无需额外的技术要求，消息即时性、准确性也可以得到保障。

参阅图2，显示了根据本发明实施例的消息推送***的示例性网络拓扑图，如图所示，该消息推送***主要包括消息队列和推送节点。消息队列采用分布式方式部署的消息队列集群11，即多机多部署，如在2台机器上分别启动3个服务实例，形成6个服务实例的分布式集群，如图3所示，这些消息队列集群可存储于RabbitMQ服务器中，RabbitMQ是部署最广泛的开源消息队列代理，作为一个中间软件模块，把消息从一个软件服务传递到另外一个软件服务上去。消息源10通过Web API将消息推送至消息队列集群11，消息队列集群11接收消息源10推送的订单消息，将订单消息推送至订阅推送服务的推送节点12。推送节点12订阅各自创建的并且互相独立的消息队列，同时绑定在FANOUT模式的交换器(EXCHANGE)下，这样可以让同一条消息在每个推送节点各自的消息队列中产生一份拷贝。推送节点12在接收消息后，开始消费过程，即成功从Web端拉取订单详请，缓存该订单详请并保存，等待店铺端连接后，将缓存的完成的订单详情推送至店铺端13。店铺端13可以是运行Windows/Linux/Android等操作***的收银设备。店铺端13为由多个店铺组成的店铺集群，店铺端13通过负载均衡(或配置中心)设施，与推送节点12建立常连接。推送节点12根据订单消息解析到消息目的店铺，判断目的店铺当前在线后，将缓存的完整消息推送至店铺端机器，并在成功收到返回后，将此条订单消息标记为已推送成功，防止重复推送，同时向消息队列集群11发送确认消费应答；其他分布式推送节点在识别到某条订单消息的已推送标记后，将该订单消息从本推送节点删除。

其中，在FANOUT模式的交换器(EXCHANGE)下，所有绑定到此交换器的消息队列都可以接收消息(纯广播的，所有消费者都能收到消息)，因此，可以让同一条订单消息在每个推送节点各自的消息队列中产生一份拷贝，确保每一个消息队列中的该订单消息的实时性和统一性。

值得一提的是，上述订单消息是订单的概要信息，并不一定包含订单的详请，比如，某一消费者通过网络在某一店铺下单后，生成一订单，该订单的概要信息(即订单消息)可只包含“某某消费者在某某店铺下单”的信息，即仅包含消费者信息和店铺信息，以及有“下单事件”发生的信息，并不包含该订单中的具体商品、价格等详细信息。这样可以减小消息队列从Web端获取信息的流量，加速信息的获取，提升消息推送的实时性。同时，推送节点只负责接收各自订阅的消息队列推送的消息，使得推送服务具有针对性，保证消息推送的准确性，避免无效推送。另外，推送节点在接收到订单消息后再与Web端链接，获取订单详情，并缓存至本地数据库中，待消息订单指向的目的店铺连接后，才将缓冲的订单详情推送至目的店铺的终端机器上，可以避免无效推送，节约网络资源。

再配合图3，显示了根据本发明实施例的消息推送***的示例性***框架图，如图所示，该消息推送***的基础架构可分为三层，第一层为服务模块，负责业务消息处理及推送；第二层为存储缓存模块，采用开源组件RabbitMQ及Redis搭建；第三层为数据中心基础设施，即客户IDC机房的基础网络及设备形态等，包括但不限于虚拟主机集群；其IDC虚拟主机一般在店铺网络的DMZ区域。DMZ是英文“demilitarized zone”的缩写，中文名称为“隔离区”，也称“非军事化区”。它是为了解决安装防火墙后外部网络的访问用户不能访问内部网络服务器的问题，而设立的一个非安全***与安全***之间的缓冲区。该缓冲区位于企业内部网络和外部网络之间的小网络区域内。在这个小网络区域内可以放置一些必须公开的服务器设施，如企业Web服务器、FTP服务器和论坛等。另一方面，通过这样一个DMZ区域，更加有效地保护了内部网络。因为这种网络部署，比起一般的防火墙方案，对来自外网的攻击者来说又多了一道关卡。

如图3所示，服务模块执行消息队列和推送节点的操作，可包含连接管理、连接路由、连接通信、API访问、分布式协作、消息分发、消息池、消费者等子单元。具体来说，连接管理用于店铺端设备和推送节点彼此间，及与Web端、推送节点之间的连接情况；连接路由即实现消息到店铺端的推送连接路由与选择功能；连接通信即用于实现店铺端和推送节点彼此间，及与Web端、推送节点之间的通信连接；API访问用于实现推送节点与Web之间的连接；分布式协作用于运行推送节点与消息队列集群中各个消息队列的分布及协作；消息分发由交换机实现消息在各个消息队列上的分开情况；消息池用于消息的汇集和存储；消费者用于管理消费者信息。

本发明还提供了一种消息推送方法，主要包括：消息队列接收消息源推送的订单消息，将所述订单消息推送至订阅推送服务的推送节点；所述推送节点在接收到所述订单消息后，获取并缓存所述订单消息的订单详情，等待店铺端连接后将所述订单详情推送至所述店铺端(如不需要获取详请时，推送节点无需“获取并缓存所述订单消息的订单详情”的步骤，将接收的订单消息推送至店铺端)。

具体来说，参阅图1，显示了根据本发明实施例的消息推送方法的示例性业务消息流转示意图，如图所示，该消息推送方法步骤：

消息源10通过Web API将消息推送至消息队列集群11，同时推送服务(推送节点，对应于每一个消费者)采用分布式方式部署，即多机多部署，如在2台机器上分别启动3个服务实例，形成6个服务实例的分布式集群。

推送服务订阅各自创建的、并且互相独立的消息队列，同时绑定在FANOUT模式的交换器(EXCHANGE)下，这样可以让同一条消息在每个推送服务各自的消息队列中产生一份拷贝。

推送服务在接收消息后，开始消费过程，即成功从消息源10(Web端)拉取订单的详请，缓存该订单详请并保存(缓存于Redis数据库中)，等待店铺端13连接。

店铺端13通过负载均衡如LVS，或“配置中心”如Apollo，ZooKeeper等前置分流设施，与推送服务建立常连接。推送服务根据消息体解析到消息目的店铺，判断目的店铺当前在线后，将缓存的完整消息推送至店铺端机器，并在成功收到返回后，将此条消息标记为已推送成功，防止重复推送，同时向消息队列集群发送确认消费应答；其他分布式推送节点在识别到某条消息的已推送标记后，将该消息从本节点删除。

本方法解决了传统轮循方法中存在的，资源浪费、消息实时性较差的情况，可以实现即时消息推送，单节点平均处理能力可以达到200次/秒，同时分布式节点可以横向扩容；对店铺网络架构也无需额外的技术要求，消息即时性、准确性也可以得到保障。

值得一提的是，本发明还提供了一种存储介质的实施例，用于存储机器可读程序指令，当该机器可读程序指令运行时，执行根据本发明消息推送方法：消息队列接收消息源推送的订单消息，将所述订单消息推送至订阅推送服务的推送节点；所述推送节点在接收到所述订单消息后，获取并缓存所述订单消息的订单详情，等待店铺端连接后将所述订单详情推送至所述店铺端。其中，该存储介质可以是ROM、RAM、移动硬盘、磁碟、光盘、U盘等。

需要说明的是，本说明书所附图式所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。同时，本说明书中所引用的如“上”、“下”、“左”、“右”、“中间”及“一”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。

以上所述仅是本发明的较佳实施例而已，并非对本发明做任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案的范围内，当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。

Claims (5)

1.一种消息推送方法，其特征在于，包括：

消息队列接收消息源推送的订单消息，所述订单消息是订单的概要信息，不包含订单的详请，将所述订单消息推送至订阅推送服务的推送节点，所述推送节点只负责接收各自订阅的消息队列推送的消息；所述消息队列采用分布式方式部署的消息队列集群；所述消息队列集群中的各个消息队列绑定在广播模式的交换器下，通过所述交换器接收所述订单消息；

所述推送节点在接收到所述订单消息后再与Web端链接，获取订单详情并缓存至本地数据库中，等待店铺端连接后将所述订单消息推送至所述店铺端；其中，所述推送节点在将所述订单消息推送至所述店铺端之后，还包括：接收所述店铺端返回的推送成功的信息，对所述订单消息进行已推送标记；并且，所述消息队列集群中的其他推送节点在识别到所述已推送标记后删除所述订单消息；所述店铺端为由多个店铺组成的店铺集群，所述店铺端通过负载均衡与所述推送节点建立常连接；所述推送节点采用虚拟主机，推送所述订单消息，且所述虚拟主机设置在店铺网络的DMZ区域。

2.如权利要求1所述的消息推送方法，其特征在于，所述推送节点在将所述订单消息推送至所述店铺端的过程中，所述推送节点在接收到所述订单消息后，解析出所述订单消息指向的所述店铺端的目的店铺，在判断所述目的店铺在线后，将所述订单消息推送至所述目的店铺。

3.如权利要求1所述的消息推送方法，其特征在于，所述消息源通过Web API将消息推送至消息队列。

4.一种消息推送***，其特征在于：包括消息队列和推送节点；所述消息队列用于接收消息源推送的订单消息，所述订单消息是订单的概要信息，不包含订单的详请，将所述订单消息推送至订阅推送服务的推送节点，所述推送节点只负责接收各自订阅的消息队列推送的消息；所述推送节点用于在接收到所述订单消息后再与Web端链接，获取订单详情并缓存至本地数据库中，等待店铺端连接后将所述订单消息推送至所述店铺端；所述消息队列采用分布式方式部署的消息队列集群；所述消息队列集群中的各个消息队列绑定在广播模式的交换器下，通过所述交换器接收所述订单消息；所述推送节点在将所述订单消息推送至所述店铺端之后，还用于：接收所述店铺端返回的推送成功的信息，对所述订单消息进行已推送标记；并且，所述消息队列集群中的其他推送节点在识别到所述已推送标记后删除所述订单消息；所述店铺端为由多个店铺组成的店铺集群，所述店铺端通过负载均衡与所述推送节点建立常连接；所述推送节点采用虚拟主机，推送所述订单消息，且所述虚拟主机设置在店铺网络的DMZ区域。

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

Images