CN107423145A - 一种避免消息丢失的方法与装置 - Google Patents

Abstract

本发明实施例提供一种避免消息丢失的方法与装置，涉及互联网技术领域。其中，所述方法包括：响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列；若所述内存队列中有待处理消息，则以轮询的方式查询所述内存队列中消息的处理情况；若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。本发明实施例能够避免系统或消息消费程序的重启/升级导致内存中缓存的待处理消息丢失的情况。

Description

一种避免消息丢失的方法与装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种避免消息丢失的方法与装置。

背景技术

Kafka是由LinkedIn开发的一个分布式的消息队列系统，消息生产者生产消息，并将消息发送至Kafka集群中进行存储，消息消费者从Kafka集群中获取消息进行处理。

现有技术中，消息消费者从Kafka集群中获取多条消息至本地内存的同时，服务端会记录下该消息消费者相应的消费位置以便该消费者下次从相应的消费位置处开始获取消息。获取到的消息保存在本地内存中之后，消息消费者的消息消费程序逐一从本地内存中提取消息进行处理。若在本地内存中的消息未被处理完时出现系统或消费程序的重启或升级操作，这势必会导致本地内存中未被处理消息的丢失，并且就算系统或消费程序再次重启后，也只能从服务端记录下的消费位置开始获取数据，不仅无法具体得知本地内存中有多少消息被丢失，也无法从Kafka集群中重复获取丢失的消息。

发明内容

本发明提供一种避免消息丢失的方法与装置，目的在于避免系统或消息消费程序的重启/升级导致内存中缓存的待处理消息的丢失。

为了解决上述技术问题，本发明提供了一种避免消息丢失的方法，该方法包括：

响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列；

若所述内存队列中有待处理消息，则以轮询的方式查询所述内存队列中消息的处理情况；

若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。

可选地，所述以轮询的方式查询所述内存队列中消息的处理情况，包括：

等时间间隔地多次查询所述内存队列中是否还存在有待处理消息。

可选地，所述方法，还包括：

从所述内存队列中获取所述待处理消息进行处理。

可选地，所述方法，还包括：

在所述系统或消息处理程序重启/升级完成后且所述消息处理程序被再次启动时，根据服务端记录的偏移量，从Kafka集群保存的队列中所述偏移量对应的位置处开始获取待处理消息至所述内存队列。

可选地，所述方法，还包括：

从所述Kafka集群中获取待处理消息时，向所述服务端上报消息消费信息以更新所述zookeeper中的偏移量。

为了解决上述技术问题，本发明还提供了一种避免消息丢失的装置，该装置，包括：

第一关闭模块，用于响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列；

查询模块，用于若所述内存队列中有待处理消息，则以轮询的方式查询所述内存队列中消息的处理情况；

第二关闭模块，用于若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。

本发明实施例提供的技术方案，在接收到系统或消息处理程序的重启或升级指令时，并不是直接关闭消息处理程序，而是先关闭消息获取通道以停止从Kafka集群中获取待处理消息至本地内存，并且以轮询的方式查询本地内存中是否还存在待处理消息，若有，则继续由消息处理程序进行处理，直到内存中待处理消息被处理完，才会关闭消息处理程序，以执行系统或消息处理程序的重启或升级操作。这样一来，就避免了系统或消息消费程序的重启/升级导致内存中缓存的待处理消息丢失，同时也避免了消息消费程序统计出的数据不准确等问题。

附图说明

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

图1为本发明一实施例提供的避免消息丢失的方法的流程示意图；

图2为本发明又一实施例提供的避免消息丢失的方法的流程示意图；

图3为本发明一实施例提供的避免消息丢失的装置的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应当理解，尽管在本发明实施例中可能采用术语第一、第二、第三等来描述XXX，但这些XXX不应限于这些术语。这些术语仅用来将XXX彼此区分开。例如，在不脱离本发明实施例范围的情况下，第一XXX也可以被称为第二XXX，类似地，第二XXX也可以被称为第一XXX。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于监测”。类似地，取决于语境，短语“如果确定”或“如果监测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当监测(陈述的条件或事件)时”或“响应于监测(陈述的条件或事件)”。

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

图1为本发明一实施例提供的避免消息丢失的方法的流程示意图。如图1所示，该方法包括：

101、响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列。

102、若所述内存队列中有待处理消息，则以轮询的方式查询所述内存队列中消息的处理情况。

103、若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。

在实际应用中，用户启动设备上的消息处理程序来处理消息时，响应于消息处理程序的启动操作，向Kafka集群发送与之建立连接的请求，Kafka集群在接收到所述建立连接的请求后，向用户设备返回一请求响应，一旦用户设备接收到所述请求响应，则表明用户设备与Kafka集群建立了连接，也即是建立了消息获取通道。用户设备通过消息获取通道从Kafka集群中获取待处理消息，并将所述待处理消息缓存至设备内存中，消息处理程序则从所述内存中逐一提取待处理消息进行处理。

需要说明的是，消息处理程序处理从Kafka集群中获取到的消息的过程，可以认为是一个数据统计的过程。由于Kafka集群中保存的消息类似于日志类消息，消息格式通常为消息生产者+消息内容+时间戳。例如，某一条消息为：礼物赠送者1+礼物数量N+201706011153，表明的是，礼物赠送者1在2017年6月1日上午11点53分这一时刻送出N个礼物，消息处理程序可将从Kafka集群中获取到的该礼物赠送者1的多条送礼消息，进行处理得到该礼物赠送者历史赠送礼物的总量。

通常，运行在用户设备上的系统或是处理消息的消息处理程序是需进行重启以解决相关运行故障问题或是进行升级以添加新增的功能的。在本实施例中，响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列。

在一种可实现的方案中，响应于系统或消息处理程序的重启/升级指令，用户设备向Kafka集群发送一断开连接请求，Kafka集群在接收到所述断开连接请求后，断开与用户设备的连接，或者Kafka集群在接收到所述断开连接请求时，向用户设备返回一请求响应，用户设备在接收到所述请求响应后，主动断开与Kafka集群的连接。断开用户设备与Kafka集群之间的连接，也即是关闭消息获取通道，这样，用户设备就无法继续从Kafka集群中获取待处理消息至内存队列中。

上述步骤102中，在关闭消息获取通道后，会去查看内存队列中是否还存在有待处理消息，若有，则由消息处理程序继续从内存队列中获取待处理消息进行逐一处理，并且，还会以轮询的方式查询所述内存队列中的消息是否被处理完。

在一种可实现的方案中，若查询到内存队列中存在有待处理消息，则根据内存队列中待处理消息的消息量以及消息处理程序处理消息的速度来决定下一次查询时刻，例如，消息处理程序处理消息的速度为M条/秒，在某一次查询中，发现内存队列中还存在有N条待处理消息，可选择在N/M秒后执行下一次查询。

在另一种可实现的方案中，若查询到内存队列中存在有待处理消息，则等时间间隔地多次查询所述内存队列中是否还存在有待处理消息。例如，每隔1s，去查询所述内存队列中的待处理消息是否被消息处理程序处理完毕。

上述步骤103中，若在第一查询发现内存队列中不存在待处理消息或是在多次查询后发现内存队列中的待处理消息被处理完毕，则关闭所述消息处理程序，以启动所述用户设备上的系统或消息处理程序的重启/升级操作。

本发明实施例提供的技术方案，在接收到系统或消息处理程序的重启或升级指令时，并不是直接关闭消息处理程序，而是先关闭消息获取通道以停止从Kafka集群中获取待处理消息至本地内存，并且以轮询的方式查询本地内存中是否还存在待处理消息，若有，则继续由消息处理程序进行处理，直到内存中待处理消息被处理完，才会关闭消息处理程序，以执行系统或消息处理程序的重启或升级操作。这样一来，就避免了系统或消息消费程序的重启/升级导致内存中缓存的待处理消息丢失，同时也避免了消息消费程序统计出的数据不准确等问题。

图2为本发明又一实施例提供的避免消息丢失的方法的流程示意图。如图2所示，该方法包括：

201、响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列。

202、若所述内存队列中有待处理消息，则等时间间隔地多次查询所述内存队列中是否还存在有待处理消息。

203、若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。

204、在所述系统或消息处理程序重启/升级完成后且所述消息处理程序被再次启动时，根据服务端记录的偏移量，从Kafka集群保存的队列中所述偏移量对应的位置处开始获取待处理消息至所述内存队列。

在一种可实现的方案中，在消息处理程序启动时，会在该消息处理程序中注册一接收系统Kill信号的钩子Shutdown Hook。响应于系统或消息处理程序需要进行重启/或升级指令，系统会向运行中的消息处理程序发送一Kill信号，消息处理程序中注册的钩子Shutdown Hook接收该Kill信号。在接收到该Kill信号后，首先关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列，并查询所述内存队列中是否有待处理消息，根据查询结果判断是执行步骤202还是步骤203。

需要说明的是，执行步骤202后，可能会重复数次去查询所述内存队列中是否还存在有待处理消息，只有在查询结果显示：所述内存队列中不存在待处理消息时，才会执行步骤203。

上述步骤202和步骤203可参照上述实施例中相应内容，在此不再赘述。

上述步骤204中，在用户设备上的系统重启或升级后，并响应于所述消息处理程序的再次启动操作，或者，响应于所述消息处理程序的重启或升级的完成事件，与kafka集群建立消息获取通道，并根据服务端记录的偏移量，通过消息获取通道从Kafka集群保存的队列中所述偏移量对应的位置处开始获取待处理消息至所述内存队列。其中，所述偏移量记录下了该用户设备从Kafka集群中获取消息的消息获取位置。

需要说明的是，发送至Kafka集群的消息以消息队列的形式存储，且每条消息都对应存储一索引值，索引值表明消息在消息队列中的存储位置。例如，发送至Kafka集群中某一消息队列中的第一条消息的索引值为0，第二条消息的索引值为1，第三条消息的索引值为2，依次类推，为存储至该消息队列中的每一条消息建立索引。

从所述Kafka集群中获取待处理消息时，向所述服务端上报消息消费信息以更新所述服务端中的偏移量。其中，所述消息消费信息可以携带有本次用户设备从Kafka集群中获取到的索引值最大的待处理消息的索引值，还可以携带上本次用户设备从Kafka集群中获取到的待处理消息的总量。

若所述消息消费信息携带的是本次用户设备从Kafka集群中获取到的索引值最大的待处理消息的索引值，则将所述索引值作为新的偏移量来更新服务端记录的偏移量。这样，在所述系统或消息处理程序重启/升级完成后且所述消息处理程序被再次启动时，根据服务端记录的偏移量，从Kafka集群保存的队列中索引值为所述偏移量的位置的下一位置处开始获取待处理消息至所述内存队列。例如，服务端记录的偏移量为80，则从Kafka集群保存的相应队列中从索引值为81的消息处开始获取消息。

若所述消息消费信息中携带的是本次用户设备从Kafka集群中获取到的待处理消息的总量，则将服务端记录的偏移量的值加上所述总量值得到新的偏移量。需要说明的是，所述服务端记录的偏移量记录了该用户设备在本次获取之前从Kafka集群中保存的相应队列中获取的总消息数。这样，在所述系统或消息处理程序重启/升级完成后且所述消息处理程序被再次启动时，根据服务端记录的偏移量，从Kafka集群保存的队列中索引值为所述偏移量的位置处开始获取待处理消息至所述内存队列。例如，服务端记录的偏移量为80，则从Kafka集群保存的相应队列中从索引值为80的消息处开始获取消息。

作为可选地，所述服务端可以为Zookeeper，即在Zookeeper中记录所述偏移量。

在一种可实现的方案中，从所述Kafka集群中每获取一条待处理消息时，所述Zookeeper中的偏移量的值增1。响应于所述消息处理程序的再次启动操作，根据Zookeeper中记录的偏移量，从Kafka集群保存的消息队列中索引值为所述偏移量的位置处开始获取待处理消息。例如，Zookeeper中记录的偏移量为50，则在Kafka相应的消息队列中获取索引值为50及之后的消息。

本发明实施例提供的技术方案，在接收到系统或消息处理程序的重启或升级指令时，并不是直接关闭消息处理程序，而是先关闭消息获取通道以停止从Kafka集群中获取待处理消息至本地内存，并且以轮询的方式查询本地内存中是否还存在待处理消息，若有，则继续由消息处理程序进行处理，直到内存中待处理消息被处理完，才会关闭消息处理程序，以执行系统或消息处理程序的重启或升级操作。这样一来，就避免了系统或消息消费程序的重启/升级导致内存中缓存的待处理消息丢失，同时也避免了消息消费程序统计出的数据不准确等问题。

图3为本发明一实施例提供的避免消息丢失的装置的结构示意图。如图3所示，该装置包括：第一关闭模块301、查询模块302以及第二关闭模块303。

第一关闭模块301，用于响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列。

查询模块302，用于若所述内存队列中有待处理消息，则以轮询的方式查询所述内存队列中消息的处理情况。

第二关闭模块303，用于若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。

可选地，所述查询模块302具体用于：

等时间间隔地多次查询所述内存队列中是否还存在有待处理消息。

可选地，该装置，还包括：

处理模块，用于从所述内存队列中获取所述待处理消息进行处理。

可选地，该装置，还包括：

获取模块，用于在所述系统或消息处理程序重启/升级完成后且所述消息处理程序被再次启动时，根据服务端记录的偏移量，从Kafka集群保存的队列中所述偏移量对应的位置处开始获取待处理消息至所述内存队列。

可选地，该装置，还包括：

上报模块，用于从所述Kafka集群中获取待处理消息时，向所述服务端上报消息消费信息以更新所述服务端中的偏移量。

所述装置与前述的方法流程描述对应，不足之处参考上述方法流程的叙述，不再一一赘述。

本发明实施例提供的技术方案，在接收到系统或消息处理程序的重启或升级指令时，并不是直接关闭消息处理程序，而是先关闭消息获取通道以停止从Kafka集群中获取待处理消息至本地内存，并且以轮询的方式查询本地内存中是否还存在待处理消息，若有，则继续由消息处理程序进行处理，直到内存中待处理消息被处理完，才会关闭消息处理程序，以执行系统或消息处理程序的重启或升级操作。这样一来，就避免了系统或消息消费程序的重启/升级导致内存中缓存的待处理消息丢失，同时也避免了消息消费程序统计出的数据不准确等问题。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种避免消息丢失的方法，其特征在于，包括：

响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列；

若所述内存队列中有待处理消息，则以轮询的方式查询所述内存队列中消息的处理情况；

若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。

2.根据权利要求1所述的方法，其特征在于，所述以轮询的方式查询所述内存队列中消息的处理情况，包括：

等时间间隔地多次查询所述内存队列中是否还存在有待处理消息。

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

从所述内存队列中获取所述待处理消息进行处理。

4.根据权利要求1-3中任一项所述的方法，其特征在于，还包括：

在所述系统或消息处理程序重启/升级完成后且所述消息处理程序被再次启动时，根据服务端记录的偏移量，从Kafka集群保存的队列中所述偏移量对应的位置处开始获取待处理消息至所述内存队列。

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

从所述Kafka集群中获取待处理消息时，向所述服务端上报消息消费信息以更新所述服务端中的偏移量。

6.一种避免消息丢失的装置，其特征在于，包括：

第一关闭模块，用于响应于系统或消息处理程序的重启/升级指令，关闭消息获取通道以停止从Kafka集群中获取待处理消息至内存队列；

查询模块，用于若所述内存队列中有待处理消息，则以轮询的方式查询所述内存队列中消息的处理情况；

第二关闭模块，用于若所述内存队列中没有所述待处理消息，则关闭所述消息处理程序，以执行所述系统或所述消息处理程序的重启/升级操作。

7.根据权利要求6所述的装置，其特征在于，所述查询模块具体用于：

等时间间隔地多次查询所述内存队列中是否还存在有待处理消息。

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

处理模块，用于从所述内存队列中获取所述待处理消息进行处理。

9.根据权利要求6-8中任一项所述的装置，其特征在于，还包括：

获取模块，用于在所述系统或消息处理程序重启/升级完成后且所述消息处理程序被再次启动时，根据服务端记录的偏移量，从Kafka集群保存的队列中所述偏移量对应的位置处开始获取待处理消息至所述内存队列。

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

上报模块，用于从所述Kafka集群中获取待处理消息时，向所述服务端上报消息消费信息以更新所述服务端中的偏移量。