CN111984429A - 基于消息队列的通信方法及装置 - Google Patents

Abstract

本说明书一个或多个实施例提供一种基于消息队列的通信方法及装置，该方法可以包括：确定消息队列的消费位点，所述消息队列包含来自消息发送方的消息；读取排列于所述消费位点之后的至少一条消息，以提供至所述消息接收方；在收到对所述至少一条消息的消费情况之前，将所述消费位点更新至所述至少一条消息之后。

Description

基于消息队列的通信方法及装置

技术领域

本说明书一个或多个实施例涉及终端技术领域，尤其涉及一种基于消息队列的通信方法及装置。

背景技术

消息队列(Message queue)可以对传输过程中的消息进行保存，使得消息由消息发送方(或称为生产者)发出后暂存于消息队列中，而无需立即传递至消息接收方(或称为消费者)，从而实现消息发送方与消息接收方之间的异步通信。例如，消息队列可以应用于分布式***中，以对各个子***之间进行异步解耦，从而实现可靠的异步通信。

发明内容

有鉴于此，本说明书一个或多个实施例提供一种基于消息队列的通信方法及装置。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种基于消息队列的通信方法，包括：

确定消息队列的消费位点，所述消息队列包含来自消息发送方的消息；

读取排列于所述消费位点之后的至少一条消息，以提供至消息接收方；

在收到对所述至少一条消息的消费情况之前，将所述消费位点更新至所述至少一条消息之后。

根据本说明书一个或多个实施例的第二方面，提出了一种基于事务日志的队列消费确认方法，包括：

将消息队列中的至少一条消息提供至消息接收方；

在事务日志中记录所述消息接收方返回的消费确认，所述消费确认表明所述消息接收方对所述特定消息已成功消费；

根据所述事务日志中记录的消费确认，确定所述消息队列的消费进度。

根据本说明书一个或多个实施例的第三方面，提出了一种基于消息队列的通信装置，包括：

消费位点确定单元，确定消息队列的消费位点，所述消息队列包含来自消息发送方的消息；

读取单元，读取排列于所述消费位点之后的至少一条消息，以提供至消息接收方；

消费位点更新单元，在收到对所述至少一条消息的消费情况之前，将所述消费位点更新至所述至少一条消息之后。

根据本说明书一个或多个实施例的第四方面，提出了一种基于事务日志的队列消费确认装置，包括：

提供单元，将消息队列中的至少一条消息提供至消息接收方；

记录单元，在事务日志中记录所述消息接收方返回的消费确认，所述消费确认表明所述消息接收方对所述特定消息已成功消费；

确定单元，根据所述事务日志中记录的消费确认，确定所述消息队列的消费进度。

根据本说明书一个或多个实施例的第五方面，提出了一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如第一方面或第二方面所述的方法。

根据本说明书一个或多个实施例的第六方面，提出了一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如第一方面或第二方面所述方法的步骤。

附图说明

图1是一示例性实施例提供的一种基于消息队列的通信***的架构示意图。

图2A是一示例性实施例提供的一种基于消息队列的通信方法的流程图。

图2B是一示例性实施例提供的一种基于事务日志的队列消费确认方法的流程图。

图3是一示例性实施例提供的一种消息传递过程的流程图。

图4是一示例性实施例提供的一种向消息队列中添加消息的示意图。

图5是一示例性实施例提供的一种从消息队列中选取消息的示意图。

图6是一示例性实施例提供的一种更新消费位点及向事务日志记录位置信息的示意图。

图7是一示例性实施例提供的一种向事务日志记录消费确认的示意图。

图8是一示例性实施例提供的一种更新初始扫描位置及更新消息队列的示意图。

图9是一示例性实施例提供的一种设备的结构示意图。

图10是一示例性实施例提供的一种基于消息队列的通信装置的框图。

图11是一示例性实施例提供的另一种设备的结构示意图。

图12是一示例性实施例提供的一种基于事务日志的队列消费确认装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

图1是一示例性实施例提供的一种基于消息队列的通信***的架构示意图。如图1所示，该***可以包括服务器11、网络12、若干通信方，比如通信方13、通信方14等。

服务器11可以为包含一独立主机的物理服务器，或者该服务器11可以为主机集群承载的虚拟服务器。在运行过程中，服务器11可以通过相关技术中的技术手段，以实现和承载本说明书中的消息队列。

通信方13-14可以为用户使用的电子设备(如PC、手机、平板设备、笔记本电脑、可穿戴设备等)，或者通信方13-14可以为分布式***中的不同子***。在运行过程中，通信方13-14可以基于服务器11维护的消息队列实现异步通信，

图2A是一示例性实施例提供的一种基于消息队列的通信方法的流程图。如图2A所示，该方法应用于承载消息队列的计算设备(例如图1所示的服务器11等)，可以包括以下步骤：

步骤202A，确定消息队列的消费位点，所述消息队列包含来自消息发送方的消息。

在一实施例中，消息发送方与消息接收方之间可以为固定角色，比如在分布式***中，子***A对子***B生成的消息进行消费、子***B不会对子***A生成的消息进行消费，那么子***B为消息发送方、子***A为消息接收方；或者，消息发送方与消息接收方之间可以为非固定角色，比如在分布式***中，当子***A对子***B生成的消息进行消费时，子***B为消息发送方、子***A为消息接收方，而当子***B对子***A生成的消息进行消费时，子***A为消息发送方、子***B为消息接收方。

在一实施例中，消息队列中的各条消息之间依次排列，比如可以按照接收顺序进行排列。通过设定消息队列中的消费位点，可以将该消费位点作为起点，依次向后读取消息，以提供至消息接收方进行消费。在消息队列中的消息被读取后，消费位点会随之发生变化，以便于对下次读取消息的起始点进行准确定位。

在一实施例中，消息队列中的消息可以通过相关技术中的任意方式进行持久化。例如，可以采用关系型数据库进行持久化；或者，可以采用队列存储引擎(比如，可以通过如RocketMQ、KAFKA等工具实现该队列存储引擎)进行持久化。尤其是，由于消息队列中的消息最终需要存储于磁盘中，因而当采用队列存储引擎时，队列存储引擎通过采用append only模式进行磁盘访问，使得消息队列中的消息可以顺序存储于磁盘上，因而无论是消息队列中产生insert(***)、read(读取)或delete(删除)，都可以实现磁盘级别的顺序操作，不会出现譬如关系型数据库等所导致的随机IO问题，从而有助于提升操作效率。

步骤204A，读取排列于所述消费位点之后的至少一条消息，以提供至消息接收方。

在一实施例中，消息接收方可以向消息队列发起读请求，使得消息队列可以相应地向消息接收方返回读取的至少一条消息。或者，消息接收方可以向消息队列订阅消息，使得消息队列可以主动向消息接收方发送至少一条消息，且这一操作可以周期性实施(除非消息队列中不存在尚未消费的消息)。

在一实施例中，如上文所述，由于消息队列中的消息按照一定顺序(如接收顺序)进行依次排列，因而消息队列可以根据确定出的消息位点，按照上述顺序读取排列于消息位点之后的至少一条消息。当采用上述的队列存储引擎进行消息的存储和读取等操作时，由于消息在磁盘上顺序存储，可以避免出现随机IO而导致的性能问题，从而高效地实现对上述至少一条消息的读取，以提升通信效率。

步骤206A，在收到对所述至少一条消息的消费情况之前，将所述消费位点更新至所述至少一条消息之后。

在一实施例中，当消息队列向消息接收方提供至少一条消息后，可以随即将消费位点更新至该至少一条消息之后，以便于继续读取后续的消息并提供至消息接收方进行消费，实现了消息粒度的消费位点更新操作，而无需等待消息接收方反馈对先前消息的消费情况后再更新，避免消息接收方在消费位点更新前出现重启而导致对上述的至少一条消息进行重新消费。

在一实施例中，可以确定所述消息接收方对所述至少一条消息的消费情况，并根据所述消费情况对所述消息队列进行更新。假定消息队列中的消息存在三种状态：可见状态、不可见状态和删除状态；当消息队列收到来自消息发送方的消息后，首先将该消息设定为可见状态，使得消息队列可以读取该消息以提供至消息接收方；以上述的至少一条消息为例，当所述至少一条消息被读取后，消息队列可以将所述至少一条消息由可见状态切换至不可见状态，此时消息队列不会读取该至少一条消息来提供至消息接收方；然后，当所述至少一条消息中的任一消息被成功消费时，将所述任一消息由不可见状态切换至删除状态，这样消息队列不会读取该任一消息来提供至消息接收方，并且可以在后续按照预设规则删除该任一消息，回收相应的磁盘空间；而当所述任一消息未被成功消费时，将所述任一消息由不可见状态切换至删除状态，并将所述任一消息添加至所述消息队列的末位，从而配合于步骤206A中更新后的消费位点，并确保该任一消息可以被再次读取并提供至消息接收方，以确保通信可靠性。

在一实施例中，可以在事务日志中顺序记录所述至少一条消息在所述消息队列中的位置信息、所述消息接收方对所述位置信息对应消息的消费情况；类似地，每次读取消息并返回至消息接收方后，均可以在该事务日志中记录相应的位置信息和消费情况。然后，消息队列可以从所述事务日志的初始扫描位置开始，向后扫描已记录的位置信息和消费情况，以获知消息接收方对上述至少一条消息或其他消息的消费情况，并将所述初始扫描位置更新至扫描到的最后一条位置信息之后，以避免在后续过程中对位置信息和消费情况进行重新扫描，确保通信可靠性。

在一实施例中，消息接收方可以在成功消费某一消息后，向消息队列返回针对该消息的消费确认，否则不返回消费确认。相应地，事务日志中仅记录有消息队列接收到的消费确认，使得在上述扫描过程中可以基于该消费确认而确定相应位置信息对应的消息被成功消费，而事务日志中未记录有消费确认的位置信息，对应的消息被确定为未被成功消费。

在一实施例中，当所述至少一条消息被读取后，所述至少一条消息由可见状态切换至预设时长的不可见状态，该预设时长可供消息接收方对该至少一条消息进行消费和返回消费确认，而消息队列可在所述不可见状态超时后，触发对所述事务日志的扫描操作。该预设时长可以为预定义的固定时长，或者基于实际需求设定的自定义时长。

图2B是一示例性实施例提供的一种基于事务日志的队列消费确认方法的流程图。如图2B所示，该方法应用于承载消息队列的计算设备(例如图1所示的服务器11等)，可以包括以下步骤：

步骤202B，将消息队列中的至少一条消息提供至消息接收方。

在一实施例中，消息发送方与消息接收方之间可以为固定角色，比如在分布式***中，子***A对子***B生成的消息进行消费、子***B不会对子***A生成的消息进行消费，那么子***B为消息发送方、子***A为消息接收方；或者，消息发送方与消息接收方之间可以为非固定角色，比如在分布式***中，当子***A对子***B生成的消息进行消费时，子***B为消息发送方、子***A为消息接收方，而当子***B对子***A生成的消息进行消费时，子***A为消息发送方、子***B为消息接收方。

在一实施例中，消息队列中的各条消息之间依次排列，比如可以按照接收顺序进行排列。通过设定消息队列中的消费位点，可以将该消费位点作为起点，依次向后读取消息，以提供至消息接收方进行消费。在消息队列中的消息被读取后，消费位点会随之发生变化，以便于对下次读取消息的起始点进行准确定位。因此，向消息接收方提供的上述至少一条消息，可以为从消费位点开始向后依次读取的若干条消息。

在一实施例中，消息接收方可以向消息队列发起读请求，使得消息队列可以相应地向消息接收方返回读取的至少一条消息。或者，消息接收方可以向消息队列订阅消息，使得消息队列可以主动向消息接收方发送至少一条消息，且这一操作可以周期性实施(除非消息队列中不存在尚未消费的消息)。

在一实施例中，消息队列中的消息可以通过相关技术中的任意方式进行持久化。例如，可以采用关系型数据库进行持久化；或者，可以采用队列存储引擎(比如，可以通过如RocketMQ、KAFKA等工具实现该队列存储引擎)进行持久化。尤其是，由于消息队列中的消息最终需要存储于磁盘中，因而当采用队列存储引擎时，队列存储引擎通过采用append only模式进行磁盘访问，使得消息队列中的消息可以顺序存储于磁盘上，因而无论是消息队列中产生insert(***)、read(读取)或delete(删除)，都可以实现磁盘级别的顺序操作，不会出现譬如关系型数据库等所导致的随机IO问题，从而有助于提升操作效率。

在一实施例中，如上文所述，由于消息队列中的消息按照一定顺序(如接收顺序)进行依次排列，因而消息队列可以根据确定出的消息位点，按照上述顺序读取排列于消息位点之后的至少一条消息。当采用上述的队列存储引擎进行消息的存储和读取等操作时，由于消息在磁盘上顺序存储，可以避免出现随机IO而导致的性能问题，从而高效地实现对上述至少一条消息的读取，以提升通信效率。

步骤204B，在事务日志中记录所述消息接收方返回的消费确认，所述消费确认表明所述消息接收方对所述特定消息已成功消费。

步骤206B，根据所述事务日志中记录的消费确认，确定所述消息队列的消费进度。

在一实施例中，通过将消费确认记录于事务日志中，并根据事务日志确定消息队列的消费进度，使得消息队列与事务日志的维护相互解耦，可以异步实施。例如，在收到对上述至少一条消息的消费情况之前，即可将消费位点更新至该至少一条消息之后，而无需等待收到消费确认后再更新，可以尽快确认消息队列的消费进度，也无需在收到消费确认前对消费队列进行锁定，可以高效地持续消费队列中的消息。

在一实施例中，当消息队列向消息接收方提供至少一条消息后，可以随即将消费位点更新至该至少一条消息之后，以便于继续读取后续的消息并提供至消息接收方进行消费，实现了消息粒度的消费位点更新操作，而无需等待消息接收方反馈对先前消息的消费情况后再更新，避免消息接收方在消费位点更新前出现重启而导致对上述的至少一条消息进行重新消费。

在一实施例中，可以确定所述消息接收方对所述至少一条消息的消费情况，并根据所述消费情况对所述消息队列进行更新。假定消息队列中的消息存在三种状态：可见状态、不可见状态和删除状态；当消息队列收到来自消息发送方的消息后，首先将该消息设定为可见状态，使得消息队列可以读取该消息以提供至消息接收方；以上述的至少一条消息为例，当所述至少一条消息被读取后，消息队列可以将所述至少一条消息由可见状态切换至不可见状态，此时消息队列不会读取该至少一条消息来提供至消息接收方；然后，当所述至少一条消息中的任一消息被成功消费时，将所述任一消息由不可见状态切换至删除状态，这样消息队列不会读取该任一消息来提供至消息接收方，并且可以在后续按照预设规则删除该任一消息，回收相应的磁盘空间；而当所述任一消息未被成功消费时，将所述任一消息由不可见状态切换至删除状态，并将所述任一消息添加至所述消息队列的末位，从而配合于前述更新后的消费位点，并确保该任一消息可以被再次读取并提供至消息接收方，以确保通信可靠性。

在一实施例中，可以在事务日志中顺序记录所述至少一条消息在所述消息队列中的位置信息、所述消息接收方对所述位置信息对应消息的消费情况；类似地，每次读取消息并返回至消息接收方后，均可以在该事务日志中记录相应的位置信息和消费情况。然后，消息队列可以从所述事务日志的初始扫描位置开始，向后扫描已记录的位置信息和消费情况，以获知消息接收方对上述至少一条消息或其他消息的消费情况，并将所述初始扫描位置更新至扫描到的最后一条位置信息之后，以避免在后续过程中对位置信息和消费情况进行重新扫描，确保通信可靠性。

在一实施例中，消息接收方可以在成功消费某一消息后，向消息队列返回针对该消息的消费确认，否则不返回消费确认。相应地，事务日志中仅记录有消息队列接收到的消费确认，使得在上述扫描过程中可以基于该消费确认而确定相应位置信息对应的消息被成功消费，而事务日志中未记录有消费确认的位置信息，对应的消息被确定为未被成功消费。

在一实施例中，当所述至少一条消息被读取后，所述至少一条消息由可见状态切换至预设时长的不可见状态，该预设时长可供消息接收方对该至少一条消息进行消费和返回消费确认，而消息队列可在所述不可见状态超时后，触发对所述事务日志的扫描操作。该预设时长可以为预定义的固定时长，或者基于实际需求设定的自定义时长。

假定在分布式***中包括子***A和子***B，在某一功能或处理步骤中，由子***A作为生产者、子***B作为消费者，即子***A用于生成消息、子***B用于获取并消费该消息。出于对子***A与子***B之间的解耦目的，可以将消息队列机制应用于该子***A与子***B之间的消息传递过程。下面结合图3，对该消息传递过程进行详细描述；其中，图3是一示例性实施例提供的一种消息传递过程的流程图。如图3所示，该流程应用于消息队列，并具体描述了消息队列与子***A、子***B之间的交互配合，该流程可以包括以下步骤：

步骤302，消息队列接收消息并更新消息队列。

在一实施例中，子***A生成消息后，将消息发送至消息队列，以更新至消息队列中。例如图4所示，假定消息队列中原本包含消息40、41、42和43，这些消息依次排列(消息40排列在前、消息43排列在后)，那么当收到子***A发送的消息44时，可以将该消息44排列至消息43之后，即该消息44被添加至消息队列的末位。

在一实施例中，消息队列可以通过诸如RocketMQ、KAFKA等实现的队列存储引擎，将消息存储至磁盘中，或者从磁盘中读取或删除消息。队列存储引擎采用append only模式实现磁盘访问，使得消息队列收到的消息可以在磁盘上实现物理上的顺序存储，而避免诸如关系型数据库造成的随机IO问题，从而防止由于随机IO所带来的性能影响。

步骤304，消息队列确定offset。

步骤306，消息队列读取num条消息。

在一实施例中，offset为消费者对于消息队列进行消费的消费位点，用于指示消息队列：offset之前的消息已经被读取过，再次读取时应当从offset开始向后读取消息。而num可以为预定义的消息数量，比如num＝2或其他任意数值。

例如图5所示，假定先前读取到消息40处，那么offset的取值可以为0；相应地，当num＝2时，消息队列从offset向后依次读取2条消息，比如读取消息41、42，并返回至消费者。

步骤308，消息队列向事务日志中***checkpoint。

在一实施例中，checkpoint为被读取的消息在消息队列中所处位置的信息，其作用是通过该位置信息来映射对应的消息。例如，当消息41、42在消息队列中所处的位置分别为1、2时，可以向事务日志中记入如图6所示的checkpoint＝1、2，那么通过对比消息队列即可确定：checkpoint＝1表示消息队列中的消息41、checkpoint＝2表示消息队列中的消息42。

步骤310，消息队列更新offset＝offset+num。

在一实施例中，在从消息队列中读取一条或多条消息、以提供至消费者之后，比如将上述消息41-42提供至消费者，消息队列可以随即对offset的取值进行更新，比如将offset更新为原本的offset取值与num取值之和，即offset＝0+2＝2。

如果在读取消息41-42后并不立即更新offset，那么当消费者在读取消息41-42之后、更新offset之前发生重启，可能重复向消息队列发起读请求，造成消息队列对offset之后的消息41-42进行重复读取，而消费者会对该消息41-42进行重复消费。因此，通过对offset进行及时更新，即便消费者发生重启，也必然需要从offset开始向后读取，此时不会对已读取过的消息41-42进行重复读取，从而避免对消息41-42进行重复消费。

步骤312A，消息队列将已读取的消息由active(可见或可用)状态切换至inactive(不可见或不可用)状态。

在一实施例中，通过对已读取的消息进行状态切换，使得消息队列不会对处于inactive状态的消息进行读取等操作。以图6为例，消息41-42填充有“斜线”背景、表明其处于inactive状态，而消息43-44被标示为空白背景、表明其处于active状态。

步骤312B，消息队列启动预设时长的计时，并在计时结束后转入步骤316。

在一实施例中，上述的预设时长为已读取的消息处于inactive状态的时长，对应于消息队列等待消费者反馈消费情况的时间段，即：如果消费者在计时结束前反馈了对相关消息的成功消费确认，那么可以认为消费者已经成功消费了相关消息；否则，认为消费者并未成功消费相关消息。相关处理过程将在下文详述。这里，可以根据正常的链路延迟、消费者的响应时长等，选取恰当的预设时长，以确保消费者在正常情况或至少一部分极端情况下，均能够正常反馈对相关消息的消费确认。

步骤314，消息队列向事务日志***ack(即acknowledge，消费确认)。

在一实施例中，消费者在成功消费了某一消息后，可以向消息队列返回针对该消息的ack；或者，如果消息队列同时向消费者返回多条消息时，消费者可以针对该多条消息统一返回相应的ack。通常而言，ack中包含消费者已成功消费的消息的信息，比如消息的checkpoint的取值等。

例如图7所示，当消息队列将checkpoint＝1、2处的消息41、42提供至消费者时，消费者可以返回对应于该消息41、42中任一者的ack，这取决于消费者对各条消息的实际消费情况。比如，当消费者仅成功消费了消息41时，消息队列会仅收到对应于消息41的ack，比如该ack中包含消息41对应的checkpoint＝1，相应地可以在事务日志中记录“ack＝1”。

步骤316，消息队列从初始扫描位置开始，扫描事务日志。

在一实施例中，事务日志用于记录与消息队列相关的日志信息，比如图7所示的checkpoint＝1、2，ack＝1等。由于每一消息都会产生相应的checkpoint信息、可能产生相应的ack信息，因而该事务日志可以维护一初始扫描位置，使得消息队列仅需要从该初始扫描位置开始向后扫描、无需对初始扫描位置之前的信息进行扫描(比如，无需每次都扫描事务日志中记录的所有信息)，从而提升扫描效率。

例如图7所示，假定初始扫描位置ori＝0，即checkpoint≤0的消息对应的信息都不需要扫描，只需要扫描checkpoint＞0的消息对应的信息，那么消息队列可以对事务日志进行扫描后，得到checkpoint＝1、2，ack＝1，表明：需要确认消费者对checkpoint＝1和checkpoint＝2的消息的消费情况，而消费者已经针对checkpoint＝1的消息反馈了消费确认、尚未针对checkpoint＝2的消息反馈消费确认，因此可以确定：消息41已经被成功消费、消息42未被成功消费。

步骤318A，对于已经成功消费的消息，消息队列将其状态切换至deleted。

步骤318B，对于未成功消费的消息，消息队列一方面将其状态切换至deleted，另一方面将其重新添加至消息队列。

例如图8所示，消息41、42分别被标示为黑色背景，表明该消息41、42被切换至deleted状态；类似地，消息40也处于deleted状态。对于deleted状态的消息，消息队列可以在任意时刻实施删除操作，或者即便不实施删除操作，这些消息也不会被消息队列读取和提供至消费者。

同时，由于消息42并未被成功消费，因而消息队列需要确保该消息42能够被重新提供至消费者，以确保该消息42能够被再次消费。那么，从消息队列中各条消息之间的逻辑顺序而言，可以将该消息42重新添加至消息队列的末位，以形成如图8所示的消息45；从磁盘数据的写入顺序而言，队列存储引擎可以将消息42的内容重新写入磁盘中、写入位置处于消息44之后，以构成图8所示的消息45，该操作符合上述的append only模式。

由于offset已经在步骤310中更新至offset＝2，因而当消息队列需要再次向消费者提供消息时，会从checkpoint＝3开始选取消息；譬如，当num＝2时，消息队列可以依次选取checkpoint＝3、4的消息43、44；当再一次选取消息时，可以继续向后选取消息45等其他消息，此处不再赘述。

步骤320，消息队列更新事务日志的初始扫描位置。

在一实施例中，通过更新初始扫描位置，可以确保后续继续对事务日志进行扫描时，不会重复扫描到先前已扫描过的信息，从而避免重复扫描、提升扫描效率。

例如图7-8所示，假定事务日志的初始扫描位置原本取值为ori＝0；在经过图3所示实施例中对于消息41、42的处理后，事务日志中添加了checkpoint＝1、2和ack＝1等内容，使得消息队列根据ori＝0对事务日志进行扫描后，扫描到了上述的checkpoint＝1、2和ack＝1等内容，并据此对消息队列中的相关消息实施了状态切换、重新添加等处理，那么对应于offset被更新至offset＝2的操作，事务日志在后续过程中必然不会出现checkpoint≤2、ack≤2的情形，因而可以将初始扫描位置更新为ori＝2，从而避免后续过程中对先前已扫描过的内容造成重复扫描，而直接从checkpoint＝3开始扫描。

图9是一示例性实施例提供的一种设备的示意结构图。请参考图9，在硬件层面，该设备包括处理器902、内部总线904、网络接口906、内存908以及非易失性存储器910，当然还可能包括其他业务所需要的硬件。处理器902从非易失性存储器910中读取对应的计算机程序到内存908中然后运行，在逻辑层面上形成基于消息队列的通信装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图10，在软件实施方式中，该基于消息队列的通信装置可以包括：

消费位点确定单元1001，确定消息队列的消费位点，所述消息队列包含来自消息发送方的消息；

读取单元1002，读取排列于所述消费位点之后的至少一条消息，以提供至消息接收方；

消费位点更新单元1003，在收到对所述至少一条消息的消费情况之前，将所述消费位点更新至所述至少一条消息之后。

可选的，还包括：

消费情况确定单元1004，确定所述消息接收方对所述至少一条消息的消费情况；

队列更新单元1005，根据所述消费情况对所述消息队列进行更新。

可选的，所述消费情况确定单元1004具体用于：

在事务日志中顺序记录所述至少一条消息在所述消息队列中的位置信息、所述消息接收方对所述位置信息对应消息的消费情况；

从所述事务日志的初始扫描位置开始，向后扫描已记录的位置信息和消费情况；

将所述初始扫描位置更新至扫描到的最后一条位置信息之后。

可选的，当所述至少一条消息被读取后，所述至少一条消息由可见状态切换至预设时长的不可见状态；所述装置还包括：

触发单元1006，当所述不可见状态超时后，触发对所述事务日志的扫描操作。

可选的，

所述装置还包括：切换单元1007，当所述至少一条消息被读取后，将所述至少一条消息由可见状态切换至不可见状态；

所述队列更新单元1005具体用于：当所述至少一条消息中的任一消息被成功消费时，将所述任一消息由不可见状态切换至删除状态；当所述任一消息未被成功消费时，将所述任一消息由不可见状态切换至删除状态，并将所述任一消息添加至所述消息队列的末位。

可选的，所述消息队列中的消息由队列存储引擎进行持久化。

可选的，所述消息队列中的消息存储于磁盘中；其中，所述队列存储引擎采用append only模式进行磁盘访问。

图11是一示例性实施例提供的一种设备的示意结构图。请参考图11，在硬件层面，该设备包括处理器1102、内部总线1104、网络接口1106、内存1108以及非易失性存储器1110，当然还可能包括其他业务所需要的硬件。处理器1102从非易失性存储器1110中读取对应的计算机程序到内存1108中然后运行，在逻辑层面上形成基于事务日志的队列消费确认装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图12，在软件实施方式中，该基于事务日志的队列消费确认装置可以包括：

提供单元1201，将消息队列中的至少一条消息提供至消息接收方；

记录单元1202，在事务日志中记录所述消息接收方返回的消费确认，所述消费确认表明所述消息接收方对所述特定消息已成功消费；

确定单元1203，根据所述事务日志中记录的消费确认，确定所述消息队列的消费进度。

可选的，所述至少一条消息位于所述消息队列的消费位点之后；所述装置还包括：

更新单元1204，在收到针对所述至少一条消息的消费确认之前，将所述消费位点更新至所述至少一条消息之后，并在预设时长内将所述至少一条消息由可见状态切换至不可见状态；

处理单元1205，在所述预设时长之后，将所述至少一条消息由不可见状态切换至删除状态，并将所述至少一条消息中未被成功消费的消息添加至所述消息队列的末位。

上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (20)

1.一种基于消息队列的通信方法，其特征在于，包括：

确定消息队列的消费位点，所述消息队列包含来自消息发送方的消息；

读取排列于所述消费位点之后的至少一条消息，以提供至消息接收方；

在收到对所述至少一条消息的消费情况之前，将所述消费位点更新至所述至少一条消息之后。

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

确定所述消息接收方对所述至少一条消息的消费情况；

根据所述消费情况对所述消息队列进行更新。

3.根据权利要求2所述的方法，其特征在于，所述确定所述消息接收方对所述至少一条消息的消费情况，包括：

在事务日志中顺序记录所述至少一条消息在所述消息队列中的位置信息、所述消息接收方对所述位置信息对应消息的消费情况；

从所述事务日志的初始扫描位置开始，向后扫描已记录的位置信息和消费情况；

将所述初始扫描位置更新至扫描到的最后一条位置信息之后。

4.根据权利要求3所述的方法，其特征在于，当所述至少一条消息被读取后，所述至少一条消息由可见状态切换至预设时长的不可见状态；所述方法还包括：

当所述不可见状态超时后，触发对所述事务日志的扫描操作。

5.根据权利要求2所述的方法，其特征在于，

所述方法还包括：当所述至少一条消息被读取后，将所述至少一条消息由可见状态切换至不可见状态；

所述根据所述消费情况对所述消息队列进行更新，包括：当所述至少一条消息中的任一消息被成功消费时，将所述任一消息由不可见状态切换至删除状态；当所述任一消息未被成功消费时，将所述任一消息由不可见状态切换至删除状态，并将所述任一消息添加至所述消息队列的末位。

6.根据权利要求1所述的方法，其特征在于，所述消息队列中的消息由队列存储引擎进行持久化。

7.根据权利要求6所述的方法，其特征在于，所述消息队列中的消息存储于磁盘中；其中，所述队列存储引擎采用append only模式进行磁盘访问。

8.一种基于事务日志的队列消费确认方法，其特征在于，包括：

将消息队列中的至少一条消息提供至消息接收方；

在事务日志中记录所述消息接收方返回的消费确认，所述消费确认表明所述消息接收方对所述特定消息已成功消费；

根据所述事务日志中记录的消费确认，确定所述消息队列的消费进度。

9.根据权利要求8所述的方法，其特征在于，所述至少一条消息位于所述消息队列的消费位点之后；所述方法还包括：

在收到针对所述至少一条消息的消费确认之前，将所述消费位点更新至所述至少一条消息之后，并在预设时长内将所述至少一条消息由可见状态切换至不可见状态；

在所述预设时长之后，将所述至少一条消息由不可见状态切换至删除状态，并将所述至少一条消息中未被成功消费的消息添加至所述消息队列的末位。

10.一种基于消息队列的通信装置，其特征在于，包括：

消费位点确定单元，确定消息队列的消费位点，所述消息队列包含来自消息发送方的消息；

读取单元，读取排列于所述消费位点之后的至少一条消息，以提供至消息接收方；

消费位点更新单元，在收到对所述至少一条消息的消费情况之前，将所述消费位点更新至所述至少一条消息之后。

11.根据权利要求10所述的装置，其特征在于，还包括：

消费情况确定单元，确定所述消息接收方对所述至少一条消息的消费情况；

队列更新单元，根据所述消费情况对所述消息队列进行更新。

12.根据权利要求11所述的装置，其特征在于，所述消费情况确定单元具体用于：

在事务日志中顺序记录所述至少一条消息在所述消息队列中的位置信息、所述消息接收方对所述位置信息对应消息的消费情况；

从所述事务日志的初始扫描位置开始，向后扫描已记录的位置信息和消费情况；

将所述初始扫描位置更新至扫描到的最后一条位置信息之后。

13.根据权利要求12所述的装置，其特征在于，当所述至少一条消息被读取后，所述至少一条消息由可见状态切换至预设时长的不可见状态；所述装置还包括：

触发单元，当所述不可见状态超时后，触发对所述事务日志的扫描操作。

14.根据权利要求11所述的装置，其特征在于，

所述装置还包括：切换单元，当所述至少一条消息被读取后，将所述至少一条消息由可见状态切换至不可见状态；

所述队列更新单元具体用于：当所述至少一条消息中的任一消息被成功消费时，将所述任一消息由不可见状态切换至删除状态；当所述任一消息未被成功消费时，将所述任一消息由不可见状态切换至删除状态，并将所述任一消息添加至所述消息队列的末位。

15.根据权利要求10所述的装置，其特征在于，所述消息队列中的消息由队列存储引擎进行持久化。

16.根据权利要求15所述的装置，其特征在于，所述消息队列中的消息存储于磁盘中；其中，所述队列存储引擎采用append only模式进行磁盘访问。

17.一种基于事务日志的队列消费确认装置，其特征在于，包括：

提供单元，将消息队列中的至少一条消息提供至消息接收方；

记录单元，在事务日志中记录所述消息接收方返回的消费确认，所述消费确认表明所述消息接收方对所述特定消息已成功消费；

确定单元，根据所述事务日志中记录的消费确认，确定所述消息队列的消费进度。

18.根据权利要求17所述的装置，其特征在于，所述至少一条消息位于所述消息队列的消费位点之后；所述装置还包括：

更新单元，在收到针对所述至少一条消息的消费确认之前，将所述消费位点更新至所述至少一条消息之后，并在预设时长内将所述至少一条消息由可见状态切换至不可见状态；

处理单元，在所述预设时长之后，将所述至少一条消息由不可见状态切换至删除状态，并将所述至少一条消息中未被成功消费的消息添加至所述消息队列的末位。

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

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如权利要求1-9中任一项所述的方法。

20.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-9中任一项所述方法的步骤。

Images