CN111190747A - 用于消息队列的消息丢失检测方法和装置 - Google Patents
用于消息队列的消息丢失检测方法和装置 Download PDFInfo
- Publication number
- CN111190747A CN111190747A CN201911330718.6A CN201911330718A CN111190747A CN 111190747 A CN111190747 A CN 111190747A CN 201911330718 A CN201911330718 A CN 201911330718A CN 111190747 A CN111190747 A CN 111190747A
- Authority
- CN
- China
- Prior art keywords
- message
- consumer
- database
- service
- identifier
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种用于消息队列的消息丢失检测方法和装置。其中，该方法包括：接收生产者发送的业务消息和业务消息的消息标识，业务消息用于表示待消费者执行的目标任务；将业务消息存储至消息队列和将消息标识存储至数据库，消息队列和数据库与消费者之间独立通信；通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识；在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。本申请解决了相关技术中不能准确检测丢失的消息的技术问题。
Description
技术领域
本申请涉及互联网领域，具体而言，涉及一种用于消息队列的消息丢失检测方法和装置。
背景技术
远程过程调用RPC(Remote Procedure Call)，通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议，RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层，RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
在分布式***架构中，RPC是一项通用技术，用来实现消息可靠有序的传递，该技术是分布式***环境中确保***稳定运行的关键因素之一，以openstack-neutron组件(一种用于网络虚拟化的组件)为例，其***架构如图1所示。在如图1所示的***架构中，如果用户给neutron-server(生产者)发送HTTP请求，该请求用来请求创建两个网段之间的路由条目，实现两个网段之间的IP三层可达，若生产者没有将请求准确的发送给L3代理(或称L3-agent，即接收采用FANOUT方式发送的业务消息的消费者的代理)，则L3代理就无法给对应的网关配置路由项，本次HTTP请求的功能就不能实现。
在生产者将请求发送给L3代理的过程中，生产者通过消息队列MQ(全称是MessageQueue)发送消息给消费者xxx-agent(其中“xxx”为具体消费者的标识，如L3和OVS)，可能会出现以下几种异常情况导致生产者没有将请求准确的发送给消费者：
(1)生产者在发送消息给消息队列的时候出现异常，比如TCP连接中断，导致消息没有发送到消息队列中，该异常生产者应该是可以捕获到；
(2)消息队列突然宕机，保存到消息队列的队列Queue中的消息没有持久化，重启以后消息丢失；
(3)消费者与消息队列之间的连接断开，但是生产者还给这个消费者发送消息，导致消息队列中对应的队列出现消息堆积，且不能发送给生产者。
在发生可能导致消息丢失的以上几种异常情况时，业界普遍采用以下解决方案：
方案一，消息持久化：主要包括对Exchange设置持久化，Queue设置持久化，消息Message持久化发送，在发送消息设置中设置发送模式deliveryMode＝2，在默认情况下，如果消息队列集群宕机重启，会导致所有的Exchange和Queue以及没有被消费的业务消息全部丢失，通过Exchange持久化，Queue持久化以及业务消息持久化，在消息队列宕机重启以后，能够快速的恢复到宕机前的状态。
方案二，ack确认机制：目前的消息发送确认中，ConfirmCallback只确认消息是否正确到达Exchange中；ReturnCallback在消息没有正确到达队列时触发回调，如果正确到达队列则不执行。在消息接收确认时，默认情况下消息消费者是自动发送ack确认消息的，该方案采用自动确认，会在消息发送给消费者代理后立即确认，这样存在丢失消息的可能，如消费者代理未保存成功、未成功发送给消费者等。
在上述方案一和方案二的缺点，首先方案一涉及到持久化的过程，持久化是一个频繁对硬盘进行读写的操作，在分布式集群规模比较大的时候，消息队列压力会比较大，消息队列消息持久化会对集群规模产生瓶颈；方案一和方案二还有几个共同的问题：一是如果Exchange在把消息发送给Queue的过程中出错的话，生产者和消费者都不能对该错误进行有效的识别，进而出现消息丢失，即仍然不能解决上述问题；二是如果消费者和消息队列之间的TCP连接断开，消费者就收不到Fanout类型的消息，而且消息队列也不会对该消息进行持久化和确认重传。
可见，以上两种技术方案仍然不能保证消息被准确地传输到接收端(消费者)。
针对上述的问题，目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种用于消息队列的消息丢失检测方法和装置，以至少解决相关技术中不能准确检测丢失的消息的技术问题。
根据本申请实施例的一个方面，提供了一种用于消息队列的消息丢失检测方法，应用于消息处理***，消息处理***包括有消息队列和数据库，该方法包括：接收生产者发送的业务消息和业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；将业务消息存储至消息队列和将消息标识存储至数据库，消息队列和数据库与消费者之间独立通信；通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识；在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。
根据本申请实施例的另一个方面，提供了一种用于消息队列的消息丢失检测方法，应用于消息的消费者，该方法包括：接收来自消息处理***的消息队列发送的业务消息并在本地存储业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；向消息处理***的数据库发送标识获取请求，以获取数据库中存储的消息标识；根据本地存储的消息标识和数据库存储的消息标识确定是否存在丢失的业务消息。
根据本申请实施例的另一个方面，提供了一种用于消息队列的消息丢失检测方法，应用于消息的生产者，该方法包括：生成待发送的业务消息，其中，业务消息包括消息标识；向消息处理***的消息队列发送业务消息，以使业务消息存储至消息队列，供消费者读取消费；向消息处理***的数据库发送业务消息的消息标识，以使消息标识存储至数据库，以供消费者在确定是否存在丢失业务消息时查询。
根据本申请实施例的另一方面，还提供了一种用于消息队列的消息丢失检测装置，应用于消息处理***，消息处理***包括有消息队列和数据库，该装置包括：第一接收单元，用于接收生产者发送的业务消息和业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；存储单元，用于将业务消息存储至消息队列和将消息标识存储至数据库，其中，消息队列和数据库与消费者之间独立通信；第一发送单元，用于通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识；第一检测单元，用于在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。
根据本申请实施例的另一方面，还提供了一种用于消息队列的消息丢失检测装置，应用于消息的消费者，该装置包括：第二接收单元，用于接收来自消息处理***的消息队列发送的业务消息并在本地存储业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；获取单元，用于向消息处理***的数据库发送标识获取请求，以获取数据库中存储的消息标识；第二检测单元，用于根据本地存储的消息标识和数据库存储的消息标识确定是否存在丢失的业务消息。
根据本申请实施例的另一方面，还提供了一种用于消息队列的消息丢失检测装置，应用于消息的生产者，该装置包括：生成单元，用于生成待发送的业务消息，其中，业务消息包括消息标识；第二发送单元，用于向消息处理***的消息队列发送业务消息，以使业务消息存储至消息队列，供消费者读取消费；第三发送单元，用于向消息处理***的数据库发送业务消息的消息标识，以使消息标识存储至数据库，以供消费者在确定是否存在丢失业务消息时查询。
根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。
根据本申请实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。
在本申请实施例中，通过提供的数据库，生产者和消费者可以实现数据同步，消费者可以通过对比数据库中存储的消息标识和本地的消息标识来确定是否存在丢失的消息，可以解决相关技术中不能准确检测丢失的消息的技术问题，进而达到对丢失的消息进行监测的技术效果。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是相关技术中的业务消息的处理***的硬件环境的示意图；
图2是根据本申请实施例的业务消息的处理***的硬件环境的示意图；
图3是根据本申请实施例的一种可选的用于消息队列的消息丢失检测方法的流程图；
图4是根据本申请实施例的一种可选的用于消息队列的消息丢失检测方法的流程图；
图5是根据本申请实施例的一种可选的用于消息队列的消息丢失检测方法的流程图；
图6是根据本申请实施例的一种可选的用于消息队列的消息丢失检测方法的流程图；
图7是根据本申请实施例的一种可选的用于消息队列的消息丢失检测装置的示意图；
图8是根据本申请实施例的一种可选的用于消息队列的消息丢失检测装置的示意图；
图9是根据本申请实施例的一种可选的用于消息队列的消息丢失检测装置的示意图；以及，
图10是根据本申请实施例的一种终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先，在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：
传输控制协议(TCP，Transmission Control Protocol)是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。
用户数据报协议UDP(User Datagram Protocol)，是OSI(Open SystemInterconnection，开放式***互联)参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，UDP在IP报文的协议号是17。
互联网协议地址IP(英语：Internet Protocol Address，又译为网际协议地址)，是分配给用户上网使用的网际协议的设备的数字标签。
HTTP(HyperText Transfer Protocol)：是一个简单的请求-响应协议(超文本传输协议)，它通常运行在TCP之上，它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII码形式给出；而消息内容则具有一个类似MIME的格式。
根据本申请实施例的一方面，提供了一种用于消息队列的消息丢失检测方法的方法实施例。
可选地，上述方法可以应用于如图2所示的硬件环境中。如图2所示，包括消费者所在的设备(可简称消费者)，生产者所在的设备(简称生产者)和队列所在的设备(如存储器、数据库)等构成的分布式***，可选地，该***还可包括L3代理所在的代理设备和OVS(OpenvSwitch，一种虚拟交换软件)代理所在的代理设备，消费者的设备和代理设备可以统称为消费者。
本申请实施例的用于消息队列的消息丢失检测方法可以由分布式***中的设备(如生产者、消费者、消息队列所在的设备)来执行。
图3是根据本申请实施例的一种可选的用于消息队列的消息丢失检测方法的流程图，该方法应用于消息处理***，消息处理***包括有消息队列和数据库(数据库中存储消息标识)，如图3所示，该方法可以包括以下步骤：
步骤S302，消息处理***接收生产者发送的业务消息和业务消息的消息标识，业务消息用于表示待消费者执行的目标任务。
上述的业务消息可为按照生产者与消费者之间进行通讯的格式生成的消息包，该消息可以通过携带任务本身或者目标任务的任务标识来表示待执行的任务为目标任务。
步骤S304，将业务消息存储至消息队列和将消息标识存储至数据库，消息队列和数据库与消费者之间独立通信，例如，消息队列和数据库可分别保存在位于不同位置的存储器上，以避免消息队列所在的存储器出现故障时数据库所在的存储器也同时出现故障。
步骤S306，通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识。
步骤S308，在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。
在本申请的上述技术方案中，生产者将业务消息发送给消息队列，也将业务消息的消息标识(即Message_id)保存在数据库(如Redis数据库)中，消费者消费到的每一条业务消息，也都将消息标识保存在本地缓存中，以便周期性的查询数据库中的消息标识，并检查查询到的消息标识是否已经被自身消费了，对于没有消费到的消息标识，则说明消息队列在传递消息的过程中，对应消息标识的消息出现丢失。
在该技术方案中，通过提供的数据库，生产者和消费者可以实现数据同步，消费者可以通过对比数据库中存储的消息标识和本地的消息标识来确定是否存在丢失的消息，可以解决相关技术中不能准确检测丢失的消息的技术问题，进而达到对丢失的消息进行监测的技术效果。下面结合图3所示的步骤进一步详述本申请的技术方案：
在步骤S302提供的技术方案中，生产者接收到让消费者执行目标任务的请求，进而生成业务消息，将其发送给消息处理***，消息处理***接收生产者发送的业务消息和业务消息的消息标识。
生产者可向用户提供接口(如rest接口)，通过暴露给用户的接口，用户可以通过HTTP请求的方式调用该接口，如通过该接口发送基于HTTP的任务请求。
在步骤S304提供的技术方案中，将业务消息存储至消息队列和将消息标识存储至数据库。
可选地，在将业务消息存储至消息队列和将消息标识存储至数据库时，可以根据消息的类型选择发送的对象，在业务消息的类型为第一类型(如Fanout类型)的情况下，将业务消息存储至所有消息队列，并将消息标识与第一类型关联后存储至数据库，为第一类型的消息被设定为发送给所有消息队列供所有消费者进行消费；在业务消息的类型为第二类型(如openstack中Direct类型的消息)的情况下，将业务消息存储至与业务消息指定的消费者关联的消息队列，并将消息标识与业务消息指定的消费者关联后存储至数据库，为第二类型的消息被设定为发送给与指定的消费者关联的消息队列供指定的消费者进行消费。
上述关联可以是为该消息标识配置指定的字符(如字符“0”表示第一类型，字符“1”表示第二类型)来标识，也可以是按照预先沟通好的表示该类型的格式来存储，如存储在表格中的指定位置。
可选地，在接收生产者发送的业务消息的消息标识之后，可将消息标识存储至预设存储空间，预设存储空间用于对保存至数据库的消息标识进行冗余备份；在数据库保存的消息标识丢失的情况下，将预设存储空间备份的消息标识复制至数据库进行存储。
在计算机的组成结构中，有一个很重要的部分，就是存储器，存储器是用来存储程序和数据的部件，对于计算机来说，有了存储器，才有记忆功能，才能保证正常工作。存储器的种类很多，按其用途可分为主存储器和辅助存储器，主存储器又称内存储器(简称内存)，内存只用于暂时存放程序和数据，一旦关闭电源或发生断电，其中的程序和数据就会丢失；辅助存储器又称外存储器(简称外存)，能长期保存信息，并且不依赖于电来保存信息。
本申请的消息队列可采用内存来存储，数据库也可以建立在外存上，如磁盘，为了提升数据处理速度，数据库还可建立在与外存保持数据同步的内存上，通过内存来保证数据处理速度，同时通过外存(即上述预设存储空间)来避免内存因为异常而产生的数据丢失。
在该技术方案中，消息队列可在内存上的rabbitmq(是实现了高级消息队列协议AMQP的开源消息代理软件，亦称面向消息的中间件)中实现；数据库在内存中创建，该数据库(如Redis)可以远程访问，不同的进程都可以连接到同一个数据库上；该数据库采用的是基于内存的操作，速度快；该数据库不仅仅支持简单的key-value类型的数据，同时还提供列表list，集合set，有序集合zset，哈希hash等数据结构的存储。
消息队列所在的rabbitmq和数据库之间可不直接交互，进程间正常的通信可通过rabbitmq实现，数据库作为一个存储工具，生产者发送消息给消费者的时候，将消息标识保存在数据库中，然后消费者可以根据生产者保存在数据库中的消息标识检查自己是否全部消费了生产者发送的消息。
在步骤S306提供的技术方案中，通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识。
类似地，在消息队列将其中的业务消息分发给消费者时，消费队列也存在两种类型，一种类型是与第一类型对应的消息队列，第一类型对应的消息队列可直接存储第一类型的业务消息，而不用存储所有消费者的信息(此处的存储任何消费者的信息相当于是指定该业务消息需要与所有消费者关联)；另一种类型是与第二类型对应的消息队列，与第二类型对应的消息队列虽然也是直接存储第二类型的业务消息，但是每个队列可仅仅存储同一个消费者的业务消息，换言之，此类型下的每个消息队列是与一个消费者绑定的。
上述描述了不同场景(即不同类型)下的消息处理方案，第一类型的消息相当于是一种广播，所有的消费者都能收到，所以不需要考虑这个消息是发给谁的，对于消费者而言，每个消费者都要消费所有为第一类型的消息。对于第二类型的消息，生产者将其发送给请求(如在任务请求中携带消费者的设备标识)所指定的消费者，如生产者将消息发送给某一个特定主机host上的消费者，其他消费者不消费此消息，在将该消息的消息标识保存到数据库上的消息队列的时候可指明该消息的host，避免其他与该消息无关的消费者去错误地处理该消息。
在步骤S308提供的技术方案中，在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。
可选地，为了减轻数据库的存储压力，在通过数据库将消息标识发送给消费者之后，删除数据库中被消费者查询过的且对应的业务消息已经被消费者消费的消息标识，以减少重复比对造成资源浪费。
图4是根据本申请实施例的一种可选的用于消息队列的消息丢失检测方法的流程图，如图4所示，该方法可以是由消费者来执行，该方法可以包括以下步骤：
步骤S402，消费者接收来自消息处理***的消息队列发送的业务消息并在本地存储业务消息的消息标识，业务消息用于表示待消费者执行的目标任务。
步骤S404，消费者向消息处理***的数据库发送标识获取请求，以获取数据库中存储的消息标识。
可选地，由于业务消息是随着时间越来越多的，故可以按照预设查询周期(如十分钟)，周期性地向数据库发送标识获取请求，以便查询这个周期内是否存在丢失的业务消息。
步骤S406，消费者根据本地存储的消息标识和数据库存储的消息标识确定是否存在丢失的业务消息。
可选地，根据本地存储的消息标识和数据库存储的消息标识确定是否存在丢失的业务消息包括：将本地存储的消息标识与数据库存储的消息标识进行比对，得到比对结果；根据比对结果确定是否存在丢失的业务消息。
可选地，根据比对结果确定是否存在丢失的业务消息包括：在比对结果为存在第一类消息标识的情况下，确定第一类消息标识(具体的数量可以大于等于0的整数)对应的业务消息为丢失的业务消息，第一类消息标识表征数据库存储的、且在本地存储中查找不到的消息标识；在比对结果为不存在第一类消息标识的情况下，确定不存在丢失的业务消息。
可选地，有的业务消息的丢失是因为网络延迟而导致的，而某些业务消息是真实丢失的业务消息，为了避免检测错误，在比对结果为存在第一类消息标识时，启动计时器；在计时器的计时时长达到第一时长(如1分钟)时，确定是否接收到第一类消息标识对应的业务消息；确定第一类消息标识对应的业务消息为丢失的业务消息包括：若确定未接收到第一类消息标识对应的业务消息时，确定第一类消息标识对应的业务消息丢失；否则确定第一类消息标识对应的业务消息未丢失(即上述因为网络延迟而导致的短暂丢失)。
可选地，在计时器的计时时长达到第一时长时，确定是否接收到第一类消息标识对应的业务消息包括：在计时器的计时时长达到第一时长时，判断是否还存在第一类消息标识；当不存在第一类消息标识时，确定接收到第一类消息标识对应的业务消息。在判断是否存在第一类消息标识时，如果存在，确定此刻第一类消息标识的数量，判断第一类消息标识的数量相对于前一次是否减少，如果减少，可以通过与前一次的对比确定接收到了所减少的第一类消息标识对应的业务消息。
可选地，在确定第一类消息标识对应的业务消息丢失后，可生成告警信息，以提示用户第一类消息标识的消息标识对应的业务消息丢失，并采取对应的策略，如通知生产者重新发送。
图5是根据本申请实施例的一种可选的用于消息队列的消息丢失检测方法的流程图，如图5所示，该方法可以是由生产者来执行，该方法可以包括以下步骤：
步骤S502，生产者生成待发送的业务消息，业务消息包括消息标识。
步骤S504，生产者向消息处理***的消息队列发送业务消息，以使业务消息存储至消息队列，供消费者读取消费。
步骤S506，生产者向消息处理***的数据库发送业务消息的消息标识，以使消息标识存储至数据库，以供消费者在确定是否存在丢失业务消息时查询。
可选地，向消息处理***的消息队列发送业务消息包括：在业务消息的类型为第一类型的情况下，向所有消息队列发送业务消息，以使业务消息存储至所有消息队列，为第一类型的消息被设定为发送给所有消息队列供所有消费者进行消费；在业务消息的类型为第二类型的情况下，将业务消息发送给与业务消息指定的消费者关联的消息队列，其中，为第二类型的消息被设定为发送给与指定的消费者关联的消息队列供指定的消费者进行消费。
在本申请的实施例中，以使用数据库Redis为例(此处使用的数据库还可以替换为其他数据库，如Mysql)，Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。本方案可通过借助Redis，消费者直接和生产者进行数据比对，检测自己是否消费了所有发送给自己的消息，而不是借助消息队列的可靠性。生产者将消息发送给消息队列之后，将消息的消息标识保存在Redis中，消费者消费到的每一条消息，也都将消息标识保存在本地变量中，周期性的查询Redis中的消息标识，检查从Redis中查到的消息标识自身是否已经消费了，如果查询到没有消费到的Redis中的消息标识，则说明消息队列在传递消息的过程中，对应消息标识的消息出现丢失。
作为一种可选的实施例，下面结合具体实施方式进一步详述本申请的技术方案。
生产者和消费者分别建一条到相同数据库Redis的连接，然后根据消息类型进行处理。
如果生产者给所有的消费者发送一个使用Fanout类型标记的消息，在发送消息之前将该消息的消息标识保存到Redis的队列里面，如使用Lpush命令将一个或多个消息标识***到列表头部，然后再把报文消息(即业务消息)发送给消息队列，消费者在消费消息的时候，将拿到的消息的消息标识保存到自己的缓存cache中，然后再处理消息。在消费者进程中，可设置一个定时任务，定时从Redis中查询所属Exchange模式为Fanout类型的消息标识，然后比对从Redis中拿到的消息标识和自己的缓存中的消息标识，找出Redis中没有被消费的消息标识，即找出丢失或者消息堆积的业务消息。对于Fanout类型的消息，如果某一个消费者与消息队列断开，消息队列和生产者都是无感的，通过消费者自身比对生产者保存在Redis中的消息标识可以检测丢失的消息。
如果生产者使用Direct模式(该模式下课通过路由host的routingKey和Exchange决定某个唯一的队列Queue可以接收消息)给部分消费者发送消息，即以指定host的消费者作为路由键，则将发送的host和消息标识作为关键字key保存在Redis中，消费者消费消息的时候，如果Exchange是Direct，则将消息标识和自己的host保存到缓存中，再处理业务消息。在消费者进程中，设置一个定时任务，可定时从Redis中查询所属Exchange和所属host的消息标识，然后与缓存中的消息标识进行比对，找出Redis中没有被消费的消息标识，即丢失或者消息堆积的业务消息。在Direct模式下，如果消费者与消息队列之间的TCP连接断开，Exchange还会将消息通过路由键匹配发送到指定的消息队列里面，不过消费者与消息队列的连接断开会出现消息堆积。
由于需要周期性处理消息标识，为了避免出现资源浪费，应该将处理完的消息标识从消费者进程的缓存和Redis中删除，避免重复校验和形成数据大量积累。此处解决方案如下:生产者发送消息之前先将消息标识保存到Redis列表中，如通过Lpush(key,Message_id)实现，并且对一个列表进行修剪，如通过命令trim(如ltrim，该命令可实现让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除)实现，设置长度为MAX_LENGTH，ltrim(key,0,self.Redis_cache_size)，以控制Redis中消息的数量cache_size，避免数据量过大。
要控制消费者进程中缓存的量，消费者可周期性执行消息检测功能，在检测过程中要注意把校验过的消息从缓存中删掉，而Redis中有但是自身缓存中没有的消息标识，就是应该被消费但是没有被消费的消息标识，保存该消息标识，设置一个时间戳，然后等超过时间阈值了进行报警。
上述方案的具体实现过程可参见图6：
步骤S602，生产者收到10条HTTP请求(即任务请求)，request_id(即请求标识)分别是0-9。
每个HTTP请求可发送消息队列给计算节点HOST-A的OVS-AGENT，对应业务消息的Exchange类型为Direct，名称为OVS-AGENT，ROUTE-KEY为HOST-A。
步骤S604，生产者在发送消息给消息队列rabbitmq(或称MQ)之前，先将消息标识保存的数据库Redis中，保存的方式为Lpush(OVS-AGENT-HOST-A,0)…Lpush(OVS-AGENT-HOST-A,9)，每次保存Redis，可对该队列做一次修剪，避免消费者进程已经校验过的消息标识长期存留导致队列长度(如需要将长度控制在LENGTH内)过大，可通过ltrim(OVS-AGENT-HOST-A,0,LENGTH)实现。
Redis驱动可以提供操作Redis的接口，类似地，消息队列驱动提供操作消息队列的接口。
步骤S606，HOST-A上的OVS-AGENT进程在消费消息的时候把消息标识(也可称为request_id)保存到变量里面，假如消息标识从0到6和9都收到了，则在消费者进程的缓存中存在列表local_Message_ids＝[0,1,2,3,4,5,6,9]，用来表示收到的消息标识。
步骤S608，HOST-A的OVS-agent(消费者)进程执行周期性任务，获取数据库中存储的消息标识。
先从Redis中获取key为OVS-AGENT-HOST-A(Exchange名称和路由键的组合)列表元素，Redis_Message_ids＝[0,1,2,3,4,5,6,7,8,9]。
消费者没有消费的消息标识miss_Message_ids就可以通过计算得出，计算公式为miss_Message_ids＝Redis_Message_ids-local_Message_ids。计算结果为miss_Message_ids＝[7,8]。
此时可同步一下Redis中的消息标识，因为Redis中保存消息标识后使用了修剪，限制了Redis中列表的长度，所以会导致老的消息标识已经在Redis中被删除了，这些被Redis删除的消息标识也应该在消费者进程中删除，避免消费者进程中local_Message_ids列表越滚越大。处理方案如下：expired_ids＝local_Message_ids-Redis_Message_ids；local_Message_ids.difference_update(expired_ids)。
在上述步骤中，消费者进程(ovs-agent)查到了有哪些消息标识是自己没有消费的，但是这个消息标识也可能是因为时延而非故障的问题导致，所以可设置一个时间阈值，做一个超时检测，而不能简单的认为该消息标识丢失，具体参见如下内容：
将miss_Message_ids中的元素一一取出，以miss_Message_id为key，获取此时时间戳作为value，保存到匹配表map中，miss_Message_map[‘7’]＝now_time，miss_Message_map[‘8’]＝now_time；
遍历miss_Message_map，获取当前时间戳，用当前时间戳减去miss_Message_map中每一个选项的value，如果超出阈值，则作为key值的消息标识就可以认为该消息标识已经丢失，通过告警接口通知运维人员。
上述方案是以Redis为例实现了生产者和消费者之间的数据传递，也可以采用mysql等数据库替代Redis，或者其他进程间通信的方式同步消息标识。采用本申请的技术方案，生产者和消费者除了使用rabbitmq实现远程过程调用RPC外，还使用了其他第三方的组件实现进程间通信，rabbitmq实现RPC其实也是一种进程间的通信，这里主要使用了两种工具实现进程间通信，来检测生产者和消费者之间的通信数据是否出现异常。该方案能够在rabbitmq之外添加检测，避免了因为rabbitmq的问题导致消息丢失而工作人员或者进程日志无感的情况。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。
根据本申请实施例的另一个方面，还提供了一种用于实施上述用于消息队列的消息丢失检测方法的用于消息队列的消息丢失检测装置。图7是根据本申请实施例的一种可选的用于消息队列的消息丢失检测装置的示意图，如图7所示，该装置可以包括：
第一接收单元701，用于接收生产者发送的业务消息和业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；
存储单元703，用于将业务消息存储至消息队列和将消息标识存储至数据库，其中，消息队列和数据库与消费者之间独立通信；
第一发送单元705，用于通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识；
第一检测单元707，用于在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。
需要说明的是，该实施例中的第一接收单元701可以用于执行本申请实施例中的步骤S302，该实施例中的存储单元703可以用于执行本申请实施例中的步骤S304，该实施例中的第一发送单元705可以用于执行本申请实施例中的步骤S306，该实施例中的第一检测单元707可以用于执行本申请实施例中的步骤S308。
通过上述模块，通过提供的数据库，生产者和消费者可以实现数据同步，消费者可以通过对比数据库中存储的消息标识和本地的消息标识来确定是否存在丢失的消息，可以解决相关技术中不能准确检测丢失的消息的技术问题，进而达到对丢失的消息进行监测的技术效果。
可选地，上述存储单元还可用于：在接收生产者发送的业务消息的消息标识之后，将消息标识存储至预设存储空间，其中，预设存储空间用于对保存至数据库的消息标识进行冗余备份；以便在数据库保存的消息标识丢失的情况下，将预设存储空间备份的消息标识复制至数据库进行存储。
可选地，上述存储单元还可用于：在业务消息的类型为第一类型的情况下，将业务消息存储至所有消息队列，并将消息标识与第一类型关联后存储至数据库，其中，为第一类型的消息被设定为发送给所有消息队列供所有消费者进行消费；在业务消息的类型为第二类型的情况下，将业务消息存储至与业务消息指定的消费者关联的消息队列，并将消息标识与业务消息指定的消费者关联后存储至数据库，其中，为第二类型的消息被设定为发送给与指定的消费者关联的消息队列供指定的消费者进行消费。
可选地，上述装置还可包括：第一删除单元，用于在通过数据库将消息标识发送给消费者之后，删除数据库中被消费者查询过的且对应的业务消息已经被消费者消费的消息标识。
根据本申请实施例的另一个方面，还提供了一种用于实施上述用于消息队列的消息丢失检测方法的用于消息队列的消息丢失检测装置。图8是根据本申请实施例的一种可选的用于消息队列的消息丢失检测装置的示意图，如图8所示，该装置可以包括：
第二接收单元801，用于接收来自消息处理***的消息队列发送的业务消息并在本地存储业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务。
获取单元803，用于向消息处理***的数据库发送标识获取请求，以获取数据库中存储的消息标识。
第二检测单元805，用于根据本地存储的消息标识和数据库存储的消息标识确定是否存在丢失的业务消息。
需要说明的是，该实施例中的第二接收单元801可以用于执行本申请实施例中的步骤S402，该实施例中的获取单元803可以用于执行本申请实施例中的步骤S404，该实施例中的第二检测单元805可以用于执行本申请实施例中的步骤S406。
可选地，第二检测单元还可用于：将本地存储的消息标识与数据库存储的消息标识进行比对，得到比对结果；根据比对结果确定是否存在丢失的业务消息。
可选地，第二检测单元还可用于：在比对结果为存在第一类消息标识的情况下，确定第一类消息标识对应的业务消息为丢失的业务消息；在比对结果为不存在第一类消息标识的情况下，确定不存在丢失的业务消息；其中，第一类消息标识表征数据库存储的、且在本地存储中查找不到的消息标识。
可选地，上述装置还可包括：第二删除单元，用于从本地存储中删除第二类消息标识，其中，第二类消息标识为通过比对结果确定数据库中和本地存储中均存在的消息标识。
可选地，第二检测单元还可用于：在比对结果为存在第一类消息标识时，启动计时器；在计时器的计时时长达到第一时长时，确定是否接收到第一类消息标识对应的业务消息；确定第一类消息标识对应的业务消息为丢失的业务消息时，若确定未接收到第一类消息标识对应的业务消息时，确定第一类消息标识对应的业务消息丢失。
可选地，上述装置还可包括：告警单元，用于在确定第一类消息标识对应的业务消息丢失后，生成告警信息，以提示用户第一类消息标识的消息标识对应的业务消息丢失。
可选地，第二检测单元还可用于：在计时器的计时时长达到第一时长时，判断是否还存在第一类消息标识；当不存在第一类消息标识时，确定接收到第一类消息标识对应的业务消息。
可选地，获取单元还可用于：按照预设查询周期，周期性地向数据库发送标识获取请求。
根据本申请实施例的另一个方面，还提供了一种用于实施上述用于消息队列的消息丢失检测方法的用于消息队列的消息丢失检测装置。图9是根据本申请实施例的一种可选的用于消息队列的消息丢失检测装置的示意图，如图9所示，该装置可以包括：
生成单元901，用于生成待发送的业务消息，其中，业务消息包括消息标识；
第二发送单元903，用于向消息处理***的消息队列发送业务消息，以使业务消息存储至消息队列，供消费者读取消费；
第三发送单元905，用于向消息处理***的数据库发送业务消息的消息标识，以使消息标识存储至数据库，以供消费者在确定是否存在丢失业务消息时查询。
需要说明的是，该实施例中的生成单元901可以用于执行本申请实施例中的步骤S502，该实施例中的第二发送单元903可以用于执行本申请实施例中的步骤S504，该实施例中的第三发送单元905可以用于执行本申请实施例中的步骤S506。
可选地，第三发送单元还可用于：在业务消息的类型为第一类型的情况下，向所有消息队列发送业务消息，以使业务消息存储至所有消息队列，其中，为第一类型的消息被设定为发送给所有消息队列供所有消费者进行消费；在业务消息的类型为第二类型的情况下，将业务消息发送给与业务消息指定的消费者关联的消息队列，其中，为第二类型的消息被设定为发送给与指定的消费者关联的消息队列供指定的消费者进行消费。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图2所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
根据本申请实施例的另一个方面，还提供了一种用于实施上述用于消息队列的消息丢失检测方法的服务器或终端。
图10是根据本申请实施例的一种终端的结构框图，如图10所示，该终端可以包括：一个或多个(图10中仅示出一个)处理器1001、存储器1003、以及传输装置1005，如图10所示，该终端还可以包括输入输出设备1007。
其中，存储器1003可用于存储软件程序以及模块，如本申请实施例中的用于消息队列的消息丢失检测方法和装置对应的程序指令/模块，处理器1001通过运行存储在存储器1003内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的用于消息队列的消息丢失检测方法。存储器1003可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1003可进一步包括相对于处理器1001远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的传输装置1005用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置1005包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置1005为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。
其中，具体地，存储器1003用于存储应用程序。
处理器1001可以通过传输装置1005调用存储器1003存储的应用程序，以执行下述步骤：
接收生产者发送的业务消息和业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；
将业务消息存储至消息队列和将消息标识存储至数据库，其中，消息队列和数据库与消费者之间独立通信；
通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识；
在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。
处理器1001还用于执行下述步骤：
接收来自消息处理***的消息队列发送的业务消息并在本地存储业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；
向消息处理***的数据库发送标识获取请求，以获取数据库中存储的消息标识；
根据本地存储的消息标识和数据库存储的消息标识确定是否存在丢失的业务消息。
处理器1001还用于执行下述步骤：
生成待发送的业务消息，其中，业务消息包括消息标识；
向消息处理***的消息队列发送业务消息，以使业务消息存储至消息队列，供消费者读取消费；
向消息处理***的数据库发送业务消息的消息标识，以使消息标识存储至数据库，以供消费者在确定是否存在丢失业务消息时查询。
可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。
本领域普通技术人员可以理解，图10所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)、PAD等终端设备。图10其并不对上述电子装置的结构造成限定。例如，终端还可包括比图10中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图10所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。
本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行用于消息队列的消息丢失检测方法的程序代码。
可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：
接收生产者发送的业务消息和业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；
将业务消息存储至消息队列和将消息标识存储至数据库，其中，消息队列和数据库与消费者之间独立通信；
通过消息队列将业务消息发送给消费者，以使消费者执行目标任务并存储业务消息的消息标识；
在数据库接收到消费者的查询请求时，通过数据库将消息标识发送给消费者，以使消费者根据数据库存储的消息标识和消费者存储的消息标识确定是否存在丢失的业务消息。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
接收来自消息处理***的消息队列发送的业务消息并在本地存储业务消息的消息标识，其中，业务消息用于表示待消费者执行的目标任务；
向消息处理***的数据库发送标识获取请求，以获取数据库中存储的消息标识；
根据本地存储的消息标识和数据库存储的消息标识确定是否存在丢失的业务消息。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
生成待发送的业务消息，其中，业务消息包括消息标识；
向消息处理***的消息队列发送业务消息，以使业务消息存储至消息队列，供消费者读取消费；
向消息处理***的数据库发送业务消息的消息标识，以使消息标识存储至数据库，以供消费者在确定是否存在丢失业务消息时查询。
可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。
在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。
Claims (19)
1.一种用于消息队列的消息丢失检测方法，所述方法应用于消息处理***，所述消息处理***包括有消息队列和数据库，其特征在于，包括：
接收生产者发送的业务消息和所述业务消息的消息标识，其中，所述业务消息用于表示待消费者执行的目标任务；
将所述业务消息存储至所述消息队列和将所述消息标识存储至所述数据库，其中，所述消息队列和数据库与所述消费者之间独立通信；
通过所述消息队列将所述业务消息发送给所述消费者，以使所述消费者执行所述目标任务并存储所述业务消息的消息标识；
在所述数据库接收到所述消费者的查询请求时，通过所述数据库将所述消息标识发送给所述消费者，以使所述消费者根据所述数据库存储的消息标识和所述消费者存储的消息标识确定是否存在丢失的业务消息。
2.根据权利要求1所述的方法，其特征在于，在接收生产者发送的所述业务消息的消息标识之后，所述方法还包括：
将所述消息标识存储至预设存储空间，其中，所述预设存储空间用于对保存至所述数据库的消息标识进行冗余备份；
在所述数据库保存的消息标识丢失的情况下，将所述预设存储空间备份的消息标识复制至所述数据库进行存储。
3.根据权利要求1或2所述的方法，其特征在于，将所述业务消息存储至所述消息队列和将所述消息标识存储至所述数据库包括：
在所述业务消息的类型为第一类型的情况下，将所述业务消息存储至所有所述消息队列，并将所述消息标识与所述第一类型关联后存储至所述数据库，其中，为所述第一类型的消息被设定为发送给所有所述消息队列供所有所述消费者进行消费；
在所述业务消息的类型为第二类型的情况下，将所述业务消息存储至与所述业务消息指定的消费者关联的所述消息队列，并将所述消息标识与所述业务消息指定的消费者关联后存储至所述数据库，其中，为所述第二类型的消息被设定为发送给与指定的消费者关联的所述消息队列供指定的消费者进行消费。
4.根据权利要求1或2所述的方法，其特征在于，在通过所述数据库将所述消息标识发送给所述消费者之后，所述方法还包括：
删除所述数据库中被所述消费者查询过的且对应的业务消息已经被所述消费者消费的消息标识。
5.一种用于消息队列的消息丢失检测方法，所述方法应用于消息的消费者，其特征在于，包括：
接收来自消息处理***的消息队列发送的业务消息并在本地存储所述业务消息的消息标识，其中，所述业务消息用于表示待消费者执行的目标任务；
向所述消息处理***的数据库发送标识获取请求，以获取所述数据库中存储的消息标识；
根据本地存储的消息标识和所述数据库存储的消息标识确定是否存在丢失的业务消息。
6.根据权利要求5所述的方法，其特征在于，根据本地存储的消息标识和所述数据库存储的消息标识确定是否存在丢失的业务消息包括：
将本地存储的消息标识与数据库存储的消息标识进行比对，得到比对结果；
根据比对结果确定是否存在丢失的业务消息。
7.根据权利要求6所述的方法，其特征在于，根据比对结果确定是否存在丢失的业务消息包括：
在所述比对结果为存在第一类消息标识的情况下，确定所述第一类消息标识对应的业务消息为丢失的业务消息；
在所述比对结果为不存在所述第一类消息标识的情况下，确定不存在丢失的业务消息；
其中，所述第一类消息标识表征所述数据库存储的、且在本地存储中查找不到的消息标识。
8.根据权利要求6所述的方法，其特征在于，所述方法还包括：
从本地存储中删除第二类消息标识，其中，所述第二类消息标识为通过所述比对结果确定的在所述数据库中和本地存储中均存在的消息标识。
9.根据权利要求7中所述的方法，其特征在于，所述方法还包括：
在所述比对结果表示存在第一类消息标识时，启动计时器；
在所述计时器的计时时长达到第一时长时，确定是否接收到所述第一类消息标识对应的业务消息；
所述确定所述第一类消息标识对应的业务消息为丢失的业务消息，包括：
若确定未接收到所述第一类消息标识对应的业务消息时，确定所述第一类消息标识对应的业务消息丢失。
10.根据权利要求9所述的方法，其特征在于，所述方法还包括：
在确定所述第一类消息标识对应的业务消息丢失后，生成告警信息，以提示用户所述第一类消息标识对应的业务消息丢失。
11.根据权利要求9所述的方法，其特征在于，所述在所述计时器的计时时长达到第一时长时，确定是否接收到所述第一类消息标识对应的业务消息包括：
在所述计时器的计时时长达到第一时长时，判断是否还存在第一类消息标识；
当不存在第一类消息标识时，确定接收到所述第一类消息标识对应的业务消息。
12.根据权利要求5所述的方法，其特征在于，所述向所述消息处理***的数据库发送标识获取请求，包括：
按照预设查询周期，周期性地向所述数据库发送所述标识获取请求。
13.一种用于消息队列的消息丢失检测方法，所述方法应用于消息的生产者，其特征在于，包括：
生成待发送的业务消息，其中，所述业务消息包括消息标识；
向消息处理***的消息队列发送所述业务消息，以使所述业务消息存储至所述消息队列，供消费者读取消费；
向所述消息处理***的数据库发送所述业务消息的消息标识，以使所述消息标识存储至数据库，以供所述消费者在确定是否存在丢失业务消息时查询。
14.根据权利要求13所述的方法，其特征在于，向消息处理***的消息队列发送所述业务消息包括：
在所述业务消息的类型为第一类型的情况下，向所有所述消息队列发送所述业务消息，以使所述业务消息存储至所有所述消息队列，其中，为所述第一类型的消息被设定为发送给所有所述消息队列供所有所述消费者进行消费；
在所述业务消息的类型为第二类型的情况下，将所述业务消息发送给与所述业务消息指定的消费者关联的所述消息队列，其中，为所述第二类型的消息被设定为发送给与指定的消费者关联的所述消息队列供指定的消费者进行消费。
15.一种用于消息队列的消息丢失检测装置，应用于消息处理***，所述消息处理***包括有消息队列和数据库，其特征在于，包括：
第一接收单元，用于接收生产者发送的业务消息和所述业务消息的消息标识，其中，所述业务消息用于表示待消费者执行的目标任务；
存储单元，用于将所述业务消息存储至所述消息队列和将所述消息标识存储至所述数据库，其中，所述消息队列和数据库与所述消费者之间独立通信；
第一发送单元，用于通过所述消息队列将所述业务消息发送给所述消费者，以使所述消费者执行所述目标任务并存储所述业务消息的消息标识；
第一检测单元，用于在所述数据库接收到所述消费者的查询请求时，通过所述数据库将所述消息标识发送给所述消费者，以使所述消费者根据所述数据库存储的消息标识和所述消费者存储的消息标识确定是否存在丢失的业务消息。
16.一种用于消息队列的消息丢失检测装置，应用于消息的消费者，其特征在于，包括：
第二接收单元，用于接收来自消息处理***的消息队列发送的业务消息并在本地存储所述业务消息的消息标识，其中，所述业务消息用于表示待消费者执行的目标任务；
获取单元，用于向所述消息处理***的数据库发送标识获取请求，以获取所述数据库中存储的消息标识；
第二检测单元，用于根据本地存储的消息标识和所述数据库存储的消息标识确定是否存在丢失的业务消息。
17.一种用于消息队列的消息丢失检测装置，应用于消息的生产者，其特征在于，包括：
生成单元，用于生成待发送的业务消息，其中，所述业务消息包括消息标识；
第二发送单元，用于向消息处理***的消息队列发送所述业务消息，以使所述业务消息存储至所述消息队列，供消费者读取消费；
第三发送单元，用于向所述消息处理***的数据库发送所述业务消息的消息标识，以使所述消息标识存储至数据库，以供所述消费者在确定是否存在丢失业务消息时查询。
18.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，所述程序运行时执行上述权利要求1至14任一项中所述的方法。
19.一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器通过所述计算机程序执行上述权利要求1至14任一项中所述的方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911330718.6A CN111190747A (zh) | 2019-12-20 | 2019-12-20 | 用于消息队列的消息丢失检测方法和装置 |
| PCT/CN2020/137532 WO2021121370A1 (zh) | 2019-12-20 | 2020-12-18 | 用于消息队列的消息丢失检测方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911330718.6A CN111190747A (zh) | 2019-12-20 | 2019-12-20 | 用于消息队列的消息丢失检测方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111190747A true CN111190747A (zh) | 2020-05-22 |
Family
ID=70707426
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911330718.6A Pending CN111190747A (zh) | 2019-12-20 | 2019-12-20 | 用于消息队列的消息丢失检测方法和装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN111190747A (zh) |
| WO (1) | WO2021121370A1 (zh) |
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111784329A (zh) * | 2020-06-30 | 2020-10-16 | 京东数字科技控股有限公司 | 业务数据的处理方法和装置、存储介质、电子装置 |
| CN112099975A (zh) * | 2020-09-25 | 2020-12-18 | Oppo广东移动通信有限公司 | 一种消息处理方法及***、存储介质 |
| CN112328418A (zh) * | 2020-11-27 | 2021-02-05 | 行吟信息科技（上海）有限公司 | 一种提升mq同步可靠性的方法和*** |
| CN112416614A (zh) * | 2020-10-28 | 2021-02-26 | 网宿科技股份有限公司 | 基于消息队列的数据处理方法、***及服务器 |
| CN112491998A (zh) * | 2020-11-18 | 2021-03-12 | 平安消费金融有限公司 | 消息推送方法及相关设备 |
| CN113014618A (zh) * | 2021-01-12 | 2021-06-22 | 腾讯科技（深圳）有限公司 | 消息处理方法、***和电子设备 |
| WO2021121370A1 (zh) * | 2019-12-20 | 2021-06-24 | 北京金山云网络技术有限公司 | 用于消息队列的消息丢失检测方法和装置 |
| CN113114725A (zh) * | 2021-03-19 | 2021-07-13 | 中新网络信息安全股份有限公司 | 一种基于http协议多节点数据交互***及其实现方法 |
| CN113194125A (zh) * | 2021-04-19 | 2021-07-30 | 天津市滨海新区环境创新研究院 | 基于物联网平台的丢包重传方法及*** |
| CN113296977A (zh) * | 2021-02-24 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 一种消息处理方法及装置 |
| CN113315676A (zh) * | 2021-05-20 | 2021-08-27 | 北京达佳互联信息技术有限公司 | 一种断链检测的方法、装置及电子设备 |
| CN114567664A (zh) * | 2022-03-04 | 2022-05-31 | 苏州浪潮智能科技有限公司 | 消息处理结果监控方法、装置、计算机设备和存储介质 |
| CN114884975A (zh) * | 2022-04-29 | 2022-08-09 | 青岛海尔科技有限公司 | 业务消息的处理方法和装置、存储介质及电子装置 |
| CN115237637A (zh) * | 2022-08-10 | 2022-10-25 | 中国建设银行股份有限公司 | 一种消息发送***、方法、装置、电子设备及存储介质 |
| CN115811470A (zh) * | 2023-02-09 | 2023-03-17 | 广州钛动科技股份有限公司 | 一种基于高可用消息框架的异步数据处理方法及其*** |
| CN115987779A (zh) * | 2022-12-22 | 2023-04-18 | 上海通联金融服务有限公司 | 一种检测消息队列消费者是否存活的方法 |
| CN118260321A (zh) * | 2024-05-31 | 2024-06-28 | 中国民用航空总局第二研究所 | 一种数据查询方法、装置、电子设备及存储介质 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104346233A (zh) * | 2014-10-13 | 2015-02-11 | 中国外汇交易中心 | 一种用于计算机***的故障恢复方法及装置 |
| US20160277152A1 (en) * | 2015-03-20 | 2016-09-22 | Vmware, Inc. | Method and system for robust message retransmission |
| CN108984325A (zh) * | 2018-07-20 | 2018-12-11 | 北京北信源信息安全技术有限公司 | 消息队列消费方法和装置 |
| CN109766195A (zh) * | 2018-12-13 | 2019-05-17 | 平安普惠企业管理有限公司 | 监测消息队列中数据丢失的方法及相关产品 |
| CN110392120A (zh) * | 2019-08-15 | 2019-10-29 | 锐捷网络股份有限公司 | 一种消息推送过程中故障的恢复方法及装置 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103761141A (zh) * | 2013-12-13 | 2014-04-30 | 北京奇虎科技有限公司 | 一种实现消息队列的方法及装置 |
| CN106888218A (zh) * | 2017-04-01 | 2017-06-23 | 网易（杭州）网络有限公司 | 消息处理方法、装置、客户端及服务端 |
| CN108667719B (zh) * | 2018-04-26 | 2020-11-27 | 广州品唯软件有限公司 | 一种实时消息传递方法及*** |
| CN111190747A (zh) * | 2019-12-20 | 2020-05-22 | 北京金山云网络技术有限公司 | 用于消息队列的消息丢失检测方法和装置 |
-
2019
- 2019-12-20 CN CN201911330718.6A patent/CN111190747A/zh active Pending
-
2020
- 2020-12-18 WO PCT/CN2020/137532 patent/WO2021121370A1/zh active Application Filing
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104346233A (zh) * | 2014-10-13 | 2015-02-11 | 中国外汇交易中心 | 一种用于计算机***的故障恢复方法及装置 |
| US20160277152A1 (en) * | 2015-03-20 | 2016-09-22 | Vmware, Inc. | Method and system for robust message retransmission |
| CN108984325A (zh) * | 2018-07-20 | 2018-12-11 | 北京北信源信息安全技术有限公司 | 消息队列消费方法和装置 |
| CN109766195A (zh) * | 2018-12-13 | 2019-05-17 | 平安普惠企业管理有限公司 | 监测消息队列中数据丢失的方法及相关产品 |
| CN110392120A (zh) * | 2019-08-15 | 2019-10-29 | 锐捷网络股份有限公司 | 一种消息推送过程中故障的恢复方法及装置 |
Cited By (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021121370A1 (zh) * | 2019-12-20 | 2021-06-24 | 北京金山云网络技术有限公司 | 用于消息队列的消息丢失检测方法和装置 |
| CN111784329B (zh) * | 2020-06-30 | 2024-04-05 | 京东科技控股股份有限公司 | 业务数据的处理方法和装置、存储介质、电子装置 |
| CN111784329A (zh) * | 2020-06-30 | 2020-10-16 | 京东数字科技控股有限公司 | 业务数据的处理方法和装置、存储介质、电子装置 |
| CN112099975A (zh) * | 2020-09-25 | 2020-12-18 | Oppo广东移动通信有限公司 | 一种消息处理方法及***、存储介质 |
| CN112099975B (zh) * | 2020-09-25 | 2024-03-26 | Oppo广东移动通信有限公司 | 一种消息处理方法及***、存储介质 |
| CN112416614A (zh) * | 2020-10-28 | 2021-02-26 | 网宿科技股份有限公司 | 基于消息队列的数据处理方法、***及服务器 |
| CN112491998B (zh) * | 2020-11-18 | 2023-08-08 | 平安消费金融有限公司 | 消息推送方法及相关设备 |
| CN112491998A (zh) * | 2020-11-18 | 2021-03-12 | 平安消费金融有限公司 | 消息推送方法及相关设备 |
| CN112328418A (zh) * | 2020-11-27 | 2021-02-05 | 行吟信息科技（上海）有限公司 | 一种提升mq同步可靠性的方法和*** |
| CN113014618B (zh) * | 2021-01-12 | 2022-04-29 | 腾讯科技（深圳）有限公司 | 消息处理方法、***和电子设备 |
| CN113014618A (zh) * | 2021-01-12 | 2021-06-22 | 腾讯科技（深圳）有限公司 | 消息处理方法、***和电子设备 |
| CN113296977A (zh) * | 2021-02-24 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 一种消息处理方法及装置 |
| CN113114725A (zh) * | 2021-03-19 | 2021-07-13 | 中新网络信息安全股份有限公司 | 一种基于http协议多节点数据交互***及其实现方法 |
| CN113194125A (zh) * | 2021-04-19 | 2021-07-30 | 天津市滨海新区环境创新研究院 | 基于物联网平台的丢包重传方法及*** |
| CN113315676B (zh) * | 2021-05-20 | 2022-11-04 | 北京达佳互联信息技术有限公司 | 一种断链检测的方法、装置及电子设备 |
| CN113315676A (zh) * | 2021-05-20 | 2021-08-27 | 北京达佳互联信息技术有限公司 | 一种断链检测的方法、装置及电子设备 |
| CN114567664B (zh) * | 2022-03-04 | 2023-08-11 | 苏州浪潮智能科技有限公司 | 消息处理结果监控方法、装置、计算机设备和存储介质 |
| CN114567664A (zh) * | 2022-03-04 | 2022-05-31 | 苏州浪潮智能科技有限公司 | 消息处理结果监控方法、装置、计算机设备和存储介质 |
| CN114884975A (zh) * | 2022-04-29 | 2022-08-09 | 青岛海尔科技有限公司 | 业务消息的处理方法和装置、存储介质及电子装置 |
| CN114884975B (zh) * | 2022-04-29 | 2024-03-22 | 青岛海尔科技有限公司 | 业务消息的处理方法和装置、存储介质及电子装置 |
| CN115237637A (zh) * | 2022-08-10 | 2022-10-25 | 中国建设银行股份有限公司 | 一种消息发送***、方法、装置、电子设备及存储介质 |
| CN115987779A (zh) * | 2022-12-22 | 2023-04-18 | 上海通联金融服务有限公司 | 一种检测消息队列消费者是否存活的方法 |
| CN115811470A (zh) * | 2023-02-09 | 2023-03-17 | 广州钛动科技股份有限公司 | 一种基于高可用消息框架的异步数据处理方法及其*** |
| CN118260321A (zh) * | 2024-05-31 | 2024-06-28 | 中国民用航空总局第二研究所 | 一种数据查询方法、装置、电子设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021121370A1 (zh) | 2021-06-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111190747A (zh) | 用于消息队列的消息丢失检测方法和装置 | |
| CN106844137B (zh) | 服务器的监控方法和装置 | |
| CN111176873B (zh) | 一种微服务自动下线方法、装置、计算机设备及存储介质 | |
| CN106598633B (zh) | 配置文件的更新方法、客户端及服务器 | |
| CN107682172B (zh) | 控制中心装置、业务***处理的方法及介质 | |
| CN106993043B (zh) | 基于代理的数据通信***和方法 | |
| CN112506702B (zh) | 数据中心容灾方法、装置、设备及存储介质 | |
| CN103514173A (zh) | 数据处理的方法和节点设备 | |
| US7499987B2 (en) | Deterministically electing an active node | |
| US9026839B2 (en) | Client based high availability method for message delivery | |
| CN113709247A (zh) | 资源获取方法、装置、***、电子设备及存储介质 | |
| CN111083049B (zh) | 一种用户表项恢复方法、装置、电子设备及存储介质 | |
| CN113691520A (zh) | 获取流媒体信息的方法、装置、存储介质及电子装置 | |
| JP4757670B2 (ja) | システム切替方法、その計算機システム及びプログラム | |
| JP3730545B2 (ja) | サービス制御アプリケーション実行方法及びシステム | |
| CN114338477B (zh) | 一种通信链路监控方法、装置、设备及存储介质 | |
| CN113259468B (zh) | 一种网络设备配置方法及装置 | |
| CN111641664B (zh) | 一种爬虫设备业务请求方法、装置、***和存储介质 | |
| CN110149232B (zh) | 分布式存储块升级iscsi服务方法、***、装置及存储介质 | |
| CN114138895A (zh) | 多数据源的数据同步方法、装置、计算机设备和存储介质 | |
| JP2007141129A (ja) | システム切替方法、その計算機システム及びプログラム | |
| WO2019105067A1 (zh) | 通道建立方法以及基站 | |
| CN102355456B (zh) | 一种重启计数器的管理方法及装置 | |
| JP2009278436A (ja) | 通信システム及び冗長構成管理方法 | |
| EP2739010A1 (en) | Method for improving reliability of distributed computer systems based on service-oriented architecture |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |