CN113918364A - 一种基于Redis的轻量级消息队列处理方法及装置 - Google Patents

Abstract

本申属于计算机技术领域。具体涉及一种基于Redis的轻量级消息队列处理方法、装置及计算机，包括：接收生产者发送的待处理的消息队列数据，待处理的消息队列数据包括ID号；将待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区及备份存储区；根据ID号，判断待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；若判断结果为待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取生产者写入的消息队列数据，将待处理的消息发送给消费者；若判断结果为待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取消息队列数据。避免了重复消息的处理并保证了消息的可靠性。

Description

一种基于Redis的轻量级消息队列处理方法及装置

技术领域

本申请属于计算机技术领域，具体涉及一种基于Redis的轻量级消息队列处理方法及装置。

背景技术

我们在处理消息队列在存取消息时，需要满足以下三个需求，分别是消息保序、处理重复的消息和保证消息可靠性。虽然消费者是异步处理消息，但是，消费者仍然需要按照生产者发送消息的顺序来处理消息，避免后发送的消息被先处理了。对于要求消息保序的场景来说，一旦出现这种消息被乱序处理的情况，就可能会导致业务逻辑被错误执行，从而给业务方造成损失。消费者从消息队列读取消息时，有时会因为网络堵塞而出现消息重传的情况。此时，消费者可能会收到多条重复的消息。对于重复的消息，消费者如果多次处理的话，就可能造成一个业务逻辑被多次执行，如果业务逻辑正好是要修改数据，那就会出现数据被多次修改的问题了。消费者在处理消息的时候，还可能出现因为故障或宕机导致消息没有处理完成的情况。此时，消息队列需要能提供消息可靠性的保证，也就是说，当消费者重启后，可以重新读取消息再次进行处理，否则，就会出现消息漏处理的问题了。

因此，为了满足以上功能的需求，设计了一种基于Redis的轻量级消息队列处理方法及装置。

发明内容

为至少在一定程度上克服相关技术中存在的问题，本申请提供一种基于Redis的轻量级消息队列处理方法及装置，以便满足消息队列的消息存取需求，避免了重复消息的处理并保证了消息的可靠性。

为实现以上目的，本申请采用如下技术方案：

第一方面，一种基于Redis的消息队列处理方法，所述方法包括：

接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；

将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区及备份存储区；

根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；

若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取所述生产者写入的消息队列数据，将所述待处理的消息发送给消费者；

若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。

进一步地，所述接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号，包括：

按照时间顺序接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号。

进一步地，所述待处理的消息队列数据包括ID号为所述待处理的消息队列数据包括全局唯一ID号。

进一步地，将所述待处理的消息队列数据按照时间顺序以及JSON文件格式存储在目标存储区及备份存储区。

进一步地，还包括：当未在所述目标存储区读取到所述待处理的消息队列数据时，则从所述备份存储区读取所述待处理消息队列数据。

第二方面，一种基于Redis的消息队列处理装置，所述装置包括：

接收模块，用于接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；

存储模块，用于将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区；

判断模块，用于根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；

处理模块，用于若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取所述生产者写入的消息队列数据；

放弃处理模块，用于若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。

第三方面，一种计算机，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现第一方面所述的方法。

本申请采用以上技术方案，至少具备以下有益效果：

一种基于Redis的轻量级消息队列处理方法，所述方法包括：通过接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区及备份存储区；根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取所述生产者写入的消息队列数据；若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。本申请所提供的方法按顺序保存消息，避免了重复消息的处理并保证了消息的可靠性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

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

图1是根据一示例性实施例示出一种基于Redis的轻量级消息队列处理方法步骤流程图。

图2是根据另一示例性实施例示出一种基于Redis的轻量级消息队列处理方法示意程图。

图3是根据另一示例性实施例示出一种基于Redis的轻量级消息队列处理方法示意程图。

图4是根据另一示例性实施例示出一种基于Redis的轻量级消息队列处理方法示意程图。

图5是根据一示例性实施例示出一种基于Redis的轻量级消息队列处理装置结构示意程图。

图6是根据一示例性实施例示出一种计算机结构示意程图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将对本申请的技术方案进行详细的描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本申请所保护的范围。

请参阅图1，图1是根据一示例性实施例示出一种基于Redis的轻量级消息队列处理方法步骤流程图。

所述方法包括：

步骤S11、接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；

一般把消息队列中发送消息的组件称为生产者，把接收消息的组件称为消费者。

步骤S12、将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区及备份存储区；

步骤S13、根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；

步骤S14、若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数据ID号不同，则从消息队列中读取所述生产者写入的消息队列数据，将所述待处理的消息发送给消费者；

即对比收到的待处理的消息队列数据ID号和记录的已处理过的已处理的消息数据ID号，来判断当前收到的待处理的消息队列数据有没有经过处理。如果已经处理过，那么，就不再进行处理了。这种处理特性也称为幂等性，幂等性就是指，对于同一条消息，收到一次的处理结果和收到多次的处理结果是一致的。

步骤S15、若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。

需要说明的是，消息队列要能支持组件通信消息的快速读写，而Redis本身支持数据的高速访问，可以满足消息队列的读写性能需求。在分布式系统中，当两个组件要基于消息队列进行通信时，一个组件会把要处理的数据以消息的形式传递给消息队列，然后，这个组件就可以继续执行其他操作了；远端的另一个组件从消息队列中把消息读取出来，再在本地进行处理。

Redis包括基于List的消息队列和基于Streams的消息队列，List本身就是按先进先出的顺序对数据进行存取的，所以，如果使用List作为消息队列保存消息的话，就已经能满足消息保序的需求了。Streams是Redis专门为消息队列设计的数据类型，它提供了丰富的消息队列操作命令。

XADD：插入消息，保证有序，可以自动生成全局唯一ID；XADD命令可以往消息队列中插入新消息，消息的格式是键-值对形式。对于插入的每一条消息，Streams可以自动为其生成一个全局唯一的ID号。

XREAD：用于读取消息，可以按ID读取数据；当消费者需要读取消息时，可以直接使用XREAD命令从消息队列中读取。XREAD在读取消息时，可以指定一个消息ID，并从这个消息ID的下一条消息开始进行读取。

消费者也可以在调用XRAED时设定block配置项，实现类似于BRPOP的阻塞读取操作。当消息队列中没有消息时，一旦设置了block配置项，XREAD就会阻塞，阻塞的时长可以在block配置项进行设置。

XREADGROUP：按消费组形式读取消息；

XPENDING和XACK：XPENDING命令可以用来查询每个消费组内所有消费者已读取但尚未确认的消息，而XACK命令用于向消息队列确认消息处理已完成。

如图2所示，为本申请所提供的一种基于redis的轻量级消息队列处理方法示意图，在一个实施例中，假设组件1即生产者，需要对采集到的数据进行求和计算，并写入数据库，但是，消息到达的速度很快，组件1没有办法及时地既做采集，又做计算，并且写入数据库。所以，本申请所提供的基于redis的轻量级消息队列处理方法，将组件1把数据x和y保存为JSON格式的消息，再发到消息队列，组件1就可以继续接收新的数据了。组件2即消费者，则异步地从消息队列中把数据读取出来，在服务器2上进行求和计算后，再写入数据库。

Redis的List和Streams两种数据类型，就可以满足消息队列的这三个需求。

一些实施例中，所述接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号，包括：

按照时间顺序接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号。

一些实施例中，所述待处理的消息队列数据包括ID号为所述待处理的消息队列数据包括全局唯一ID号。

如图3所示是本申请所提供的一种基于redis的轻量级消息队列处理方法，

基于List的消息队列实现方法包括，List本身就是按先进先出的顺序对数据进行存取的，所以，如果使用List作为消息队列保存消息的话，就已经能满足消息保序的需求了。具体来说，生产者使用LPUSH命令把要发送的消息依次写入List，而消费者则使用RPOP命令，从List的另一端按照消息的写入顺序，依次读取消息并进行处理。如图3所示，生产者先用LPUSH写入了两条库存消息，分别是5和3，表示要把库存更新为5和3；消费者则用RPOP把两条消息依次读出，然后进行相应的处理。

在消费者读取数据时，有一个潜在的性能风险点。在生产者往List中写入数据时，List并不会主动地通知消费者有新消息写入，如果消费者想要及时处理消息，就需要在程序中不停地调用RPOP命令(比如使用一个while(1)循环)。如果有新消息写入，RPOP命令就会返回结果，否则，RPOP命令返回空值，再继续循环。所以，即使没有新消息写入List，消费者也要不停地调用RPOP命令，这就会导致消费者程序的CPU一直消耗在执行RPOP命令上，带来不必要的性能损失。

为了解决这个问题，Redis提供了BRPOP命令。BRPOP命令也称为阻塞式读取，客户端在没有读到队列数据时，自动阻塞，直到有新的数据写入队列，再开始读取新数据。和消费者程序自己不停地调用RPOP命令相比，这种方式能节省CPU开销。

可以理解为，本申请所提供的一种基于Redis的轻量级消息队列处理方法，所述方法包括：通过接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区及备份存储区；根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取所述生产者写入的消息队列数据；若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。本申请所提供的方法按顺序保存消息，避免了重复消息的处理并保证了消息的可靠性。

在一个实施例中，还包括：当未在所述目标存储区读取到所述待处理的消息队列数据时，则从所述备份存储区读取所述待处理消息队列数据。

如图4所示，为本申请另一个实施例所提供的一种基于Redis的轻量级消息队列处理方法。

在解决重复消息处理的问题中，生产者在发送消息前为每条消息队列数据生成全局唯一的ID号，生成之后，在用LPUSH命令把消息插入List时，则在消息中包含这个全局唯一ID。这样就保证了消息可靠性。当消费者程序从List中读取一条消息后，List就不会再留存这条消息了。所以，如果消费者程序在处理消息的过程出现了故障或宕机，就会导致消息没有处理完成，那么，消费者程序再次启动后，就没法再次从List中读取消息了。生产者先用LPUSH把消息“5”“3”插入到消息队列mq中。消费者程序使用BRPOPLPUSH命令读取消息“5”，同时，消息“5”还会被Redis插入到mqback队列中。如果消费者程序处理消息“5”时宕机了，等它重启后，可以从mqback中再次读取消息“5”，继续处理。

一些实施例中，按照时间顺序接收生产者发送的待处理的消息队列数据，所述消息队列数据包括全局唯一ID号。

一些事实中，将所述待处理的消息队列数据按照时间顺序以及JSON文件格式存储在目标存储区及备份存储区。

如图5所示，本申请还提供了一种基于Redis的消息队列处理装置5，所述装置包括：

接收模块51，用于接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；

存储模块52，用于将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区；

判断模块53，用于根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；

处理模块54，用于若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取所述生产者写入的消息队列数据；

放弃处理模块55，用于若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。

关于上述实施例中的一种基于Redis的轻量级消息队列处理装置，其中各个模块执行操作的具体方式已经在上述相关方法的实施例中进行了详细描述，此处将不做详细阐述说明。

请参阅图6，图6是根据一示例性实施例示出的一种计算机框图示意图，该计算机6包括：

包括存储器61和处理器62，所述存储器61中存储有计算机可读指令，所述计算机可读指令被所述处理器62执行时，使得所述处理器执行如上任一项所述方法的步骤。

为便于理解本申请还提供了，实际操作用的实施例，

Streams本身可以使用XGROUP创建消费组，创建消费组之后，Streams可以使用XREADGROUP命令让消费组内的消费者读取消息，

例如，创建一个名为group1的消费组，这个消费组消费的消息队列是mqZto，则执行如下命令，

XGROUP create mqZto group1 0

OK

然后，让group1消费组里的消费者consumer1从mqZto中读取所有消息，其中，命令最后的参数“>”，表示从第一条尚未被消费的消息开始读取。因为在consumer1读取消息前，group1中没有其他消费者读取过消息，所以，consumer1就得到mqZto消息队列中的所有消息了(一共4条)。其代码如下：

XREADGROUP group group1 consumer1 streams mqZto>

1)1)"mqZto"

2)1)1)"73161233878583"

2)1)"repo"2)"4"

2)1)"73161233555744"

2)1)"repo"2)"3"

3)1)"73161233525655"

2)1)"repo"2)"2"

4)1)"73161232876076"

2)1)"repo"2)"1"

消息队列中的消息一旦被消费组里的一个消费者读取了，就不能再被该消费组内的其他消费者读取了。比如说，我们执行完刚才的XREADGROUP命令后，再执行下面的命令，让group1内的consumer2读取消息时，consumer2读到的就是空值，因为消息已经被consumer1读取完了，如下所示：

XREADGROUP group group1 consumer2 streams mqZto 0

1)1)"mqZto"

2)(empty list or set)

使用消费组的目的是让组内的多个消费者共同分担读取消息，所以，通常会让每个消费者读取部分消息，从而实现消息读取负载在多个消费者间是均衡分布的。例如，我们执行下列命令，让group2中的consumer1、2、3各自读取一条消息。如下所示：

XREADGROUP group group2 consumer1 count 1streams mqZto>

1)1)"mqZto"

2)1)1)"73161233878583"

2)1)"repo"

2)"4"

XREADGROUP group group2 consumer2 count 1streams mqZto>

1)1)"mqZto"

2)1)1)"73161233555744"

2)1)"repo"

2)"3"

XREADGROUP group group2 consumer3 count 1streams mqZto>

1)1)"mqZto"

2)1)1)"73161233525655"

2)1)"repo"

2)"2"

为了保证消费者在发生故障或宕机再次重启后，仍然可以读取未处理完的消息，Streams自动使用内部队列(也称为PENDING List)留存消费组里每个消费者读取的消息，直到消费者使用XACK命令通知Streams“消息已经处理完成”。如果消费者没有成功处理消息，它就不会给Streams发送XACK命令，消息仍然会留存。此时，消费者可以在重启后，用XPENDING命令查看已读取、但尚未确认处理完成的消息。

在另一个实施例中，例如，查看一下group2中各个消费者已读取、但尚未确认的消息个数。其中，XPENDING返回结果的第二、三行分别表示group2中所有消费者读取的消息最小ID和最大ID。如下所示：

XPENDING mqZto group2

1)(integer)3

2)"7599203861727"

3)"7599274925823"

4)1)1)"consumer1"

2)"1"

2)1)"consumer2"

2)"1"

3)1)"consumer3"

2)"1"

如果还需要进一步查看某个消费者具体读取了哪些数据，可以执行下面的命令：

XPENDING mqZto group2-+10consumer2

1)1)"7599274912765"

2)"consumer2"

3)(integer)51333

4)(integer)1

consumer2已读取的消息的ID是7599274912765。

一旦消息7599274912765被consumer2处理了，consumer2就可以使用XACK命令通知Streams，然后这条消息就会被删除。当我们再使用XPENDING命令查看时，就可以看到，consumer2已经没有已读取、但尚未确认处理的消息了。如下所示：

XACK mqZto group2 7599274912765-0

(integer)1XPENDING mqZto group2-+10consumer2

(empty list or set)

关于Redis做消息队列的问题，需要考虑业务层面的数据体量，以及对性能、可靠性、可扩展性的需求。如果分布式系统中的组件消息通信量不大，那么，Redis只需要使用有限的内存空间就能满足消息存储的需求，而且，Redis的高性能特性能支持快速的消息读写，不失为消息队列的一个好的解决方案。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”、“多”的含义是指至少两个。

应该理解，当元件被称为“固定于”或“设置于”另一个元件，它可以直接在另一个元件上或者可能同时存在居中元件；当一个元件被称为“连接”另一个元件，它可以是直接连接到另一个元件或者可能同时存在居中元件,此外，这里使用的“连接”可以包括无线连接；使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为：表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行装置执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (7)

1.一种基于Redis的轻量级消息队列处理方法，其特征在于，所述方法包括：

接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；

将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区及备份存储区；

根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；

若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取所述生产者写入的消息队列数据，将所述待处理的消息发送给消费者；

若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。

2.根据权利要求1所述的方法，其特征在于，所述接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号，包括：

按照时间顺序接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号。

3.根据权利要求1所述的方法，其特征在于，所述待处理的消息队列数据包括ID号为所述待处理的消息队列数据包括全局唯一ID号。

4.根据权利要求1所述的方法，其特征在于，将所述待处理的消息队列数据按照时间顺序以及JSON文件格式存储在目标存储区及备份存储区。

5.根据权利要求1所述的方法，其特征在于，还包括：当未在所述目标存储区读取到所述待处理的消息队列数据时，则从所述备份存储区读取所述待处理消息队列数据。

6.一种基于Redis的轻量级消息队列处理装置，其特征在于，所述装置包括：

接收模块，用于接收生产者发送的待处理的消息队列数据，所述待处理的消息队列数据包括ID号；

存储模块，用于将所述待处理的消息队列数据按照时间顺序以及预设存储格式存储在目标存储区；

判断模块，用于根据所述ID号，判断所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是否相同，得到判断结果；

处理模块，用于若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息数ID号不同，则从消息队列中读取所述生产者写入的消息队列数据；

放弃处理模块，用于若所述判断结果为所述待处理的消息队列数据ID号与已处理的消息队列数据ID号是相同，则放弃读取所述消息队列数据。

7.一种计算机，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至5任一项所述的方法。

Images