CN108809855A - 消息管理方法、装置及电子设备 - Google Patents

Abstract

本申请提供一种消息管理方法、装置及电子设备，所述方法的一具体实施方式包括：将从Kafka消息队列中获取的多个待处理的目标消息进行缓存；处理缓存的所述目标消息，并记录消息处理状态信息；响应于满足预设的触发条件，基于当前的所述消息处理状态信息上报针对所述Kafka消息队列的偏移量；其中，所述偏移量在所述Kafka消息队列中对应的位置之前的目标消息均已被处理完成。该实施方式在客户端关闭时，如果未处理完缓存中的消息，当客户端再次启动后，仍然可以根据上次上报给服务端的偏移量从队列中拉取上次未处理完成的消息，从而避免了消息的丢失。

Description

消息管理方法、装置及电子设备

技术领域

本申请涉及互联网技术领域，特别涉及一种消息管理方法、装置及电子设备。

背景技术

Kafka是一个开源流处理平台，是一种高吞吐量的分布式发布订阅消息系统，可以用于处理网站中的动作流数据。在Kafka系统中，服务端可以将待处理的消息存储到队列中，客户端可以从服务端拉取队列中的消息，并存入缓存。目前来说，客户端在接收到待处理的消息后，会向服务端发送下次从队列中拉取消息的起始位置。如果客户端关闭，则下次启动后，可以接着从队列中的该起始位置拉取消息。然而，在客户端关闭时，如果未处理完缓存中的消息，则缓存中的数据就会丢失。当客户端再次启动后，只能根据上次发送给服务端的起始位置从队列中拉取新的消息，而无法找回未处理完成的消息，从而导致消息的丢失。

发明内容

为了解决上述技术问题之一，本申请提供一种消息管理方法、装置及电子设备。

根据本申请实施例的第一方面，提供一种消息管理方法，包括：

将从Kafka消息队列中获取的多个待处理的目标消息进行缓存；

处理缓存的所述目标消息，并记录消息处理状态信息；

响应于满足预设的触发条件，基于当前的所述消息处理状态信息上报针对所述Kafka消息队列的偏移量；其中，所述偏移量在所述Kafka消息队列中对应的位置之前的目标消息均已被处理完成。

可选的，所述将从Kafka消息队列中获取的多个待处理的目标消息进行缓存，包括：

确定所述目标消息在所述Kafka消息队列中所对应的队列序号；

将所述目标消息与对应的队列序号进行关联并存储至缓存；

所述记录消息处理状态信息，包括：

基于所述目标消息对应的队列序号记录消息处理状态信息。

可选的，所述基于所述目标消息对应的队列序号记录消息处理状态信息，包括：

记录被处理完成的目标信息所对应的队列序号，得到消息处理状态信息。

可选的，所述基于当前的所述消息处理状态信息上报针对所述Kafka消息队列的偏移量，包括：

从所述消息处理状态信息记录的队列序号中，按照从小到大的顺序选取首个与之后的队列序号不连续的队列序号；

根据所述首个与之后的队列序号不连续的队列序号确定针对所述Kafka消息队列的偏移量，并上报所述偏移量。

可选的，所述预设的触发条件包括以下任意一项或多项：

距离预设时刻的时间间隔大于或等于预设时长；

在所述预设时刻之后连续处理完成的消息数量大于或等于预设数量；

确定指定客户端即将关闭；以及

确定即将对所述Kafka消息队列进行重新分配。

根据本申请实施例的第二方面，提供一种消息管理装置，包括：

缓存模块，用于将从Kafka消息队列中获取的多个待处理的目标消息进行缓存；

处理模块，用于处理缓存的所述目标消息，

记录模块，用于记录消息处理状态信息；

上报模块，用于响应于满足预设的触发条件，基于当前的所述消息处理状态信息上报针对所述Kafka消息队列的偏移量；其中，所述偏移量在所述Kafka消息队列中对应的位置之前的目标消息均已被处理完成。

可选的，所述缓存模块包括：

确定子模块，用于确定所述目标消息在所述Kafka消息队列中所对应的队列序号；

存储子模块，用于将所述目标消息与对应的队列序号进行关联并存储至缓存；

所述记录模块被配置用于：

基于所述目标消息对应的队列序号记录消息处理状态信息。

可选的，所述预设的触发条件包括以下任意一项或多项：

距离预设时刻的时间间隔大于或等于预设时长；

在所述预设时刻之后连续处理完成的消息数量大于或等于预设数量；

确定指定客户端即将关闭；以及

确定即将对所述Kafka消息队列进行重新分配。

根据本申请实施例的第三方面，提供一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面中任一项所述的方法。

根据本申请实施例的第四方面，提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述第一方面中任一项所述的方法。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请的实施例提供的消息管理方法和装置，将从Kafka消息队列中获取的多个待处理的目标消息进行缓存，处理缓存的目标消息，并记录消息处理状态信息。响应于满足预设的触发条件，基于当前的消息处理状态信息，上报针对Kafka消息队列的偏移量，其中，该偏移量在该Kafka消息队列中对应的位置之前的目标消息均已被处理完成。由于本实施例上报的偏移量为满足预设的触发条件时，基于消息处理状态信息而得到的，并且，能够保证该偏移量在Kafka消息队列中对应的位置之前的目标消息均已被处理完成。因此，在客户端关闭时，如果未处理完缓存中的消息，当客户端再次启动后，仍然可以根据上次上报给服务端的偏移量从队列中拉取上次未处理完成的消息，从而避免了消息的丢失。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1A是本申请根据一示例性实施例示出的一种消息管理方法的流程图；

图1B是本申请根据一示例性实施例示出的一种消息管理的场景示意图；

图2是本申请根据一示例性实施例示出的另一种消息管理方法的流程图；

图3是本申请根据一示例性实施例示出的一种消息管理装置的框图；

图4是本申请根据一示例性实施例示出的另一种消息管理装置的框图；

图5是本申请根据一示例性实施例示出的另一种消息管理装置的框图；

图6是本申请根据一示例性实施例示出的一种电子设备的结构示意图。

具体实施方式

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

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

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

如图1A所示，图1A是根据一示例性实施例示出的一种消息管理方法的流程图，该方法可以应用于Kafka系统的客户端中，该方法包括以下步骤：

在步骤101中，将从Kafka消息队列中获取的多个待处理的目标消息进行缓存。

一般来说，Kafka系统的服务端可以将生成的消息存放在Kafka消息队列中。客户端可以向服务端发送消息获取请求，以请求获取多个待处理的目标消息，该消息获取请求携带Kafka消息队列中目标消息的起始位置。服务端可以根据该起始位置，从Kafka消息队列中连续取出多个消息作为目标消息，并将目标消息返回给客户端。在本实施例中，客户端首先可以从Kafka消息队列中获取多个连续的目标消息，并将获取到的目标消息存放在缓存中。

在步骤102中，处理缓存的目标消息，并记录消息处理状态信息。

在本实施例中，客户端可以从缓存中取出目标消息并进行处理，在对目标消息进行处理的过程中，可以根据对目标消息的处理情况记录消息处理状态信息。该消息处理状态信息能够体现出当前客户端对目标消息的处理完成状况，即能够指示当前客户端已经处理完成的目标消息。例如，该消息处理状态信息可以包括缓存的目标消息中已被处理完成的目标消息所对应的标识信息(如，队列序号等)。可以理解，该消息处理状态信息可以是任意能够体现出当前客户端对目标消息的处理完成状况的信息，本申请对该消息处理状态信息的具体内容和形式方面不限定。

在步骤103中，响应于满足预设的触发条件，基于当前的消息处理状态信息上报针对Kafka消息队列的偏移量，其中，该偏移量在该Kafka消息队列中对应的位置之前的目标消息均已被处理完成。

在本实施例中，当确定满足预设的触发条件时，可以基于当前的消息处理状态信息，上报针对Kafka消息队列的偏移量。其中，需要保证该偏移量在该Kafka消息队列中对应的位置之前的目标消息均已被处理完成。

例如，如图1B所示，消息3-消息10为按照Kafka消息队列中的顺序，缓存的目标消息。当确定满足预设的触发条件时，基于当前的消息处理状态信息，可知消息3-消息6以及消息8和消息9均已被处理完成，消息7和消息10未被处理完成。可见，按照Kafka消息队列的顺序，消息4-消息7中的任意一个消息之前的目标消息(消息4之前的目标消息为消息3，消息5之前的目标消息为消息3-消息4，消息6之前的目标消息为消息3-消息5，消息7之前的目标消息为消息3-消息6)均已被处理完成。因此，可以将消息4-消息7中的任意一个消息在Kafka消息队列中所对应的队列序号作为待上报的偏移量。可选地，可以将消息7在Kafka消息队列中所对应的队列序号作为待上报的偏移量。

在本实施例中，可以预先设定一个或多个触发条件，当满足任意一个预设的触发条件时，均可以触发上报偏移量。例如，预设的触发条件可以是距离预设时刻的时间间隔大于或等于预设时长，也可以是在预设时刻之后连续处理的消息数量大于或等于预设数量等等。可以理解，预设的触发条件还可以是其它任意合理的条件，本申请对预设的触发条件的具体内容和数量方面不限定。

需要说明的是，客户端在满足预设的触发条件时，上报更新偏移量。当客户端关闭或者客户端程序出现异常时，若缓存的目标消息还未处理完成，则缓存的目标消息将会丢失。但是，当客户端重新启动后，客户端还可以从服务端获取最近一次上报的偏移量，将该偏移量在Kafka消息队列中所对应的位置作为拉取消息的起始位置，并重新拉取待处理的消息。而该偏移量在Kafka消息队列中对应的位置之前的目标消息均已被处理完成，因此，客户端还能获取上次未处理完成的消息，并继续进行处理。

本申请的上述实施例提供的消息管理方法，将从Kafka消息队列中获取的多个待处理的目标消息进行缓存，处理缓存的目标消息，并记录消息处理状态信息。响应于满足预设的触发条件，基于当前的消息处理状态信息，上报针对Kafka消息队列的偏移量，其中，该偏移量在该Kafka消息队列中对应的位置之前的目标消息均已被处理完成。由于本实施例上报的偏移量为满足预设的触发条件时，基于消息处理状态信息而得到的，并且，能够保证该偏移量在Kafka消息队列中对应的位置之前的目标消息均已被处理完成。因此，在客户端关闭时，如果未处理完缓存中的消息，当客户端再次启动后，仍然可以根据上次上报给服务端的偏移量从队列中拉取上次未处理完成的消息，从而避免了消息的丢失。

在一些可选实施方式中，预设的触发条件可以包括以下任意一项或多项：距离预设时刻的时间间隔大于或等于预设时长；在预设时刻之后连续处理的消息数量大于或等于预设数量；确定指定客户端即将关闭；以及，确定即将对Kafka消息队列进行重新分配。

具体来说，在一种实现方式中，可以预先设定一个预设时长(如，10秒，或者20秒，或者30秒等)，当距离预设时刻的时间间隔大于或等于预设时长时，可以确定满足预设的触发条件，触发上报偏移量，以不断对偏移量进行更新备份。其中，预设时刻可以是客户端拉取到目标消息的时刻，也可以是客户端上次上报偏移量的时刻，可以理解，预设时刻可以是任意合理的时刻，本申请对预设时刻的具体设定方面不限定。预设时长可以是根据经验设定的任意合理的时长，本申请对预设时长的具体设定方面不限定。

在另一种实现方式中，可以预先设定一个预设数量(如，1，或者2，或者3等)，当在预设时刻之后连续处理的消息数量大于或等于预设数量时，可以确定满足预设的触发条件，触发上报偏移量，以不断对偏移量进行更新备份。其中，预设时刻可以是客户端拉取到目标消息的时刻，也可以是客户端上次上报偏移量的时刻，可以理解，预设时刻可以是任意合理的时刻，本申请对预设时刻的具体设定方面不限定。预设数量可以是根据经验设定的任意合理的数量，本申请对预设数量的具体设定方面不限定。

在另一种实现方式中，当确定指定客户端即将关闭时，可以确定满足预设的触发条件，触发上报偏移量。其中，指定客户端可以是执行主体对应的客户端。当确定客户端即将关闭时，客户端中缓存的目标消息可能还未被处理完成，此时如果关闭客户端，缓存的目标消息就会丢失。因此，需要在客户端即将关闭时，及时对偏移量进行更新备份。

在另一种实现方式中，当确定即将对Kafka消息队列进行重新分配时，可以确定满足预设的触发条件，触发上报偏移量。具体来说，当对Kafka消息队列进行重新分配后，可能会更换其它客户端继续处理Kafka消息队列中的消息。而更换的其它客户端需要确定首次从Kafka消息队列中拉取消息所的位置。因此，需要在即将对Kafka消息队列进行重新分配时，及时对偏移量进行更新备份。

上述实施例，能够及时的上报更新针对Kafka消息队列的偏移量，因此，促进了有效信息的更新。

如图2所示，图2根据一示例性实施例示出的另一种消息管理方法的流程图，该实施例描述了记录消息处理状态信息的过程，该方法可以应用于Kafka系统的客户端中，包括以下步骤：

在步骤201中，确定从Kafka消息队列中获取的多个待处理的目标消息在Kafka消息队列中所对应的队列序号。

在步骤202中，将目标消息与对应的队列序号进行关联并存储至缓存。

一般来说，存放在Kafka消息队列中的消息均对应一个队列序号，该队列序号可以作为消息的唯一性标识，并且，该队列序号可以用消息在Kafka消息队列中的顺序标号来表示，能够表征消息在Kafka消息队列中的位置。例如，Kafka消息队列中的消息所对应的队列序号按照从前到后的顺序可以是1、2、3、4、5、6……，队列序号为n的消息为队列中的第n个消息。

在本实施例中，当客户端从Kafka消息队列中获取到多个待处理的目标消息后，首先，可以确定每个目标消息在Kafka消息队列中所对应的队列序号。然后，可以将每个目标消息与对应的队列序号进行关联并存储至缓存。

在步骤203中，处理缓存的目标消息，并基于目标消息对应的队列序号记录消息处理状态信息。

在本实施例中，客户端可以从缓存的多个目标消息中取出目标消息进行处理。需要说明的是，客户端不可能同时取出并处理完成所有目标消息，只能分别取出部分目标消息，并分别进行处理。因此，在对目标消息进行处理的过程中，可以基于目标消息对应的队列序号记录消息处理状态信息。

可选地，可以记录被处理完成的目标信息所对应的队列序号，得到消息处理状态信息。其中，被处理完成的目标信息可以是被成功处理的目标消息，以及未被成功处理，并且被重复处理次数超过预设次数的目标消息。具体来说，在对任意一个目标消息进行处理时，如果该目标消息被成功处理，则可以记录该目标消息所对应的队列序号。如果该目标消息未被成功处理，则可以重新处理该目标消息，当该目标消息被重复处理的次数超过预设次数时，停止对该目标消息进行处理，并且记录该目标消息所对应的队列序号。

在步骤204中，响应于满足预设条件，基于当前的消息处理状态信息上报针对Kafka消息队列的偏移量。

在本实施例中，当满足预设条件时，可以基于当前的消息处理状态信息上报针对Kafka消息队列的偏移量。可选地，可以从消息处理状态信息记录的队列序号中，按照从小到大的顺序选取首个与之后的队列序号不连续的队列序号，并根据首个与之后的队列序号不连续的队列序号确定偏移量，并向服务端上报该偏移量。需要说明的是，将首个与之后的队列序号不连续的队列序号设为参考值，可以直接将该参考值作为偏移量，也可以将该参考值减去1所得的数值作为偏移量，可选地，还可以将该参考值加1所得的数值作为偏移量，可以理解，本申请对此方面不限定。

例如，如果消息处理状态信息记录的队列序号包括3、4、5、8、9，由此可知，队列序号3之后的队列序号为4，4与3连续；队列序号4之后的队列序号为5，5与4连续；而队列序号5之后的队列序号为8，8与5不连续。因此，可以确定5为首个与之后的队列序号不连续的队列序号。可以根据队列序号5确定偏移量，例如，可以直接将5作为偏移量，也可以将5减去1所得的数值4作为偏移量，可选地，还可以将该5加1所得的数值6作为偏移量。

需要说明的是，对于与图1A实施例中相同的步骤，在上述图2实施例中不再进行赘述，相关内容可参见图1A实施例。

本申请的上述实施例提供的消息管理方法，确定从Kafka消息队列中获取的多个待处理的目标消息在Kafka消息队列中所对应的队列序号，将目标消息与对应的队列序号进行关联并存储至缓存，处理缓存的目标消息，并基于目标消息对应的队列序号记录消息处理状态信息。响应于满足预设条件，基于当前的消息处理状态信息上报偏移量。从而能够在客户端关闭又再次启动后，仍然可以根据上次上报给服务端的偏移量从队列中拉取上次未处理完成的消息，有助于避免消息的丢失。

应当注意，尽管在上述实施例中，以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

下面结合一个完整的消息管理的应用实例，对本申请方案进行示意性说明。

应用场景可以为：Kafka系统中的客户端A从Kafka服务端B的消息队列中获取多个待处理的目标消息，这些目标消息在消息队列中所对应的队列序号为3、4、5、6、7、8、9、10，客户端A可以将这些消息分别与对应的队列序号关联地存储至缓存中。客户端A可以从缓存中分别取出目标消息进行处理。

在客户端A对目标消息进行处理的过程中，如果处理完成一个目标消息，则可以将该被处理完成的消息所对应的队列序号记录下来，得到消息处理状态信息。当满足预设的触发条件时，如果消息处理状态信息包括队列序号3、4、5和8，因此，可以确定当前队列序号为3、4、5和8的目标消息已经被处理完成。可以将5作为参考值，将5加1得到的数值6作为待上报的偏移量(队列序号6之前的目标消息均已被处理完成)。然后，将偏移量6上报给服务端B。

如果在上报偏移量6之后，客户端A忽然异常关闭(如异常断电等)，那么，缓存中未被处理完成的目标消息(对应的队列序号为6、7、9和10的目标消息)将被删除。但是，当客户端A再次被重新启动后，客户端A可以从服务端B获取上次上报的偏移量6，并将队列序号6作为拉取消息的起始位置，可以重新获取上次未被处理完成的目标消息。

可见，应用上述方案，在客户端关闭时，如果未处理完缓存中的消息，当客户端再次启动后，仍然可以根据上次上报给服务端的偏移量从队列中拉取上次未处理完成的消息，从而避免了消息的丢失。

与前述消息管理方法的实施例相对应，本申请还提供了消息管理装置的实施例。

如图3所示，图3是本申请根据一示例性实施例示出的一种消息管理装置框图，该装置可以包括：缓存模块301，处理模块302，记录模块303和上报模块304。

其中，缓存模块301，用于将从Kafka消息队列中获取的多个待处理的目标消息进行缓存。

处理模块302，用于处理缓存的上述目标消息。

记录模块303，用于记录消息处理状态信息。

上报模块304，用于响应于满足预设的触发条件，基于当前的消息处理状态信息上报针对Kafka消息队列的偏移量。其中，该偏移量在Kafka消息队列中对应的位置之前的目标消息均已被处理完成。

如图4所示，图4是本申请根据一示例性实施例示出的另一种消息管理装置框图，该实施例在前述图3所示实施例的基础上，缓存模块301可以包括：确定子模块401和存储子模块402。

其中，确定子模块401，用于确定目标消息在Kafka消息队列中所对应的队列序号。

存储子模块402，用于将目标消息与对应的队列序号进行关联并存储至缓存。

其中，记录模块303被配置用于：基于目标消息对应的队列序号记录消息处理状态信息。

在一些可选实施方式中，记录模块303可以通过如下方式基于目标消息对应的队列序号记录消息处理状态信息：记录被处理完成的目标信息所对应的队列序号，得到消息处理状态信息。

如图5所示，图5是本申请根据一示例性实施例示出的另一种消息管理装置框图，该实施例在前述图3所示实施例的基础上，上报模块304可以包括：选取子模块501和上报子模块502。

其中，选取子模块501，用于从消息处理状态信息记录的队列序号中，按照从小到大的顺序选取首个与之后的队列序号不连续的队列序号。

上报子模块502，用于根据上述首个与之后的队列序号不连续的队列序号确定针对Kafka消息队列的偏移量，并上报偏移量。

在另一些可选实施方式中，预设的触发条件包括以下任意一项或多项：

距离预设时刻的时间间隔大于或等于预设时长；

在预设时刻之后连续处理完成的消息数量大于或等于预设数量；

确定指定客户端即将关闭；以及

确定即将对Kafka消息队列进行重新分配。

应当理解，上述装置可以预先设置在客户端中，也可以通过下载等方式而加载到客户端中。上述装置中的相应模块可以与客户端中的模块相互配合以实现消息管理方案。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请实施例还提供了一种计算机可读存储介质，该存储介质存储有计算机程序，计算机程序可用于执行上述图1A至图2任一实施例提供的消息管理方法。

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

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (10)

1.一种消息管理方法，其特征在于，所述方法包括：

将从Kafka消息队列中获取的多个待处理的目标消息进行缓存；

处理缓存的所述目标消息，并记录消息处理状态信息；

响应于满足预设的触发条件，基于当前的所述消息处理状态信息上报针对所述Kafka消息队列的偏移量；其中，所述偏移量在所述Kafka消息队列中对应的位置之前的目标消息均已被处理完成。

2.根据权利要求1所述的方法，其特征在于，所述将从Kafka消息队列中获取的多个待处理的目标消息进行缓存，包括：

确定所述目标消息在所述Kafka消息队列中所对应的队列序号；

将所述目标消息与对应的队列序号进行关联并存储至缓存；

所述记录消息处理状态信息，包括：

基于所述目标消息对应的队列序号记录消息处理状态信息。

3.根据权利要求2所述的方法，其特征在于，所述基于所述目标消息对应的队列序号记录消息处理状态信息，包括：

记录被处理完成的目标信息所对应的队列序号，得到消息处理状态信息。

4.根据权利要求3所述的方法，其特征在于，所述基于当前的所述消息处理状态信息上报针对所述Kafka消息队列的偏移量，包括：

从所述消息处理状态信息记录的队列序号中，按照从小到大的顺序选取首个与之后的队列序号不连续的队列序号；

根据所述首个与之后的队列序号不连续的队列序号确定针对所述Kafka消息队列的偏移量，并上报所述偏移量。

5.根据权利要求1-4中任一所述的方法，其特征在于，所述预设的触发条件包括以下任意一项或多项：

距离预设时刻的时间间隔大于或等于预设时长；

在所述预设时刻之后连续处理完成的消息数量大于或等于预设数量；

确定指定客户端即将关闭；以及

确定即将对所述Kafka消息队列进行重新分配。

6.一种消息管理装置，其特征在于，所述装置包括：

缓存模块，用于将从Kafka消息队列中获取的多个待处理的目标消息进行缓存；

处理模块，用于处理缓存的所述目标消息，

记录模块，用于记录消息处理状态信息；

上报模块，用于响应于满足预设的触发条件，基于当前的所述消息处理状态信息上报针对所述Kafka消息队列的偏移量；其中，所述偏移量在所述Kafka消息队列中对应的位置之前的目标消息均已被处理完成。

7.根据权利要求6所述的装置，其特征在于，所述缓存模块包括：

确定子模块，用于确定所述目标消息在所述Kafka消息队列中所对应的队列序号；

存储子模块，用于将所述目标消息与对应的队列序号进行关联并存储至缓存；

所述记录模块被配置用于：

基于所述目标消息对应的队列序号记录消息处理状态信息。

8.根据权利要求6或7所述的装置，其特征在于，所述预设的触发条件包括以下任意一项或多项：

距离预设时刻的时间间隔大于或等于预设时长；

在所述预设时刻之后连续处理完成的消息数量大于或等于预设数量；

确定指定客户端即将关闭；以及

确定即将对所述Kafka消息队列进行重新分配。

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

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