[发明专利]一种流计算应用中实现持久化的方法及装置

说明书

技术领域

本申请涉及流计算技术，尤指一种流计算应用中是实现持久化的方法及装置。

背景技术

通常，在流计算中将数据流称为消息，而对数据流的一系列计算、处理称为消费。

流计算产品主要用于实时计算。实时计算通常在内存中进行，而计算结果要通过某种途径保存并展现出来。目前，主要采用缓存或者持久化到磁盘如数据库（非内存数据库）中两种方式对计算结果进行保存。其中，由于缓存方式没有物理磁盘输入/输出（I/O），因此，缓存方式有着非常卓越的消息吞吐能力；但是，由于计算结果没有持久化，缓存方式几乎没有容错能力，也就是说，一旦出现应用程序中断、服务器宕机、缓存被清空等情况，保存在缓存中的计算结果将无法恢复。而采用持久化到磁盘中的方式，可以实现最高级别的容错功能，但是，持久化到磁盘涉及到大量的磁盘写，这又降低了流计算的计算速度，执行效率大约比采用缓存的方式低一个数量级。

图1为现有基本的容错型流计算应用中数据流向示意图，如图1所示，消息中间件集群发送的消息流是一条一条的。为了便于容错，通常流计算产品如图1中的流计算集群对消息流进行消费是以批次为单位的，即将若干条消息捆绑在一个批次中，每一个批次有一个唯一的标识（ID）。对于一个批次的消息，只有批次内的每一条消息都被成功消费后，这个批次的消息才被标记为被成功消费；只要一个批次内有一条消息没有被消费成功，整个批次的消息就会被消息中间件重新发送，被流计算集群重新消费。

最终处理过的消息流存储到磁盘称之为持久化，这一步对于故障恢复是至关重要的。一旦出现应用程序中断、服务器宕机等情况，只有持久化操作才能保证实时计算的结果不丢失。故障恢复、实时计算应用重启时，需要重新从磁盘中加载实时计算的过程数据与结果数据，将所有状态恢复到故障发生之前的一个正确的时间点。在图1所示的ZooKeeper集群中存储有消息中间件集群发送的消息所在的消息队列的偏移量。当消息中间件集群发送给流计算集群一批消息时，ZooKeeper中会记录这批次的消息在消息队列中的起始偏移量。如果这批次的消息被流计算集群成功消费，那么，消息中间件集群会发送下一批次消息，ZooKeeper中记录的偏移量随之更新为下一批次消息在消息队列中的起始偏移量；如果这批次消息被消费失败，那么，流计算集群会从ZooKeeper集群中重新读取这批次消息的偏移量，然后到消息中间件集群中重新请求该批次消息，以实现消息的失败重发。

发明内容

为了解决上述技术问题，本申请提供了一种流计算应用中实现持久化的方法及装置，能够保证故障后数据的安全恢复，提高实时计算效率。

为了达到本申请目的，本申请提供一种流计算应用中实现持久化的方法，包括：

当前批次消息消费成功，根据用于保存当前正在消费的批次消息在消息队列中的起始位置的第一起始偏移量和预先设置的持久化间隔，判断是否需要进行持久化操作；

在需要进行持久化操作时，按照用于保存最近一次持久化操作的下一批次消息在消息队列中的起始位置的第二起始偏移量指示的消息位置进行持久化处理；

持久化操作成功后，分别更新第一起始偏移量和第二起始偏移量为下一批次消息的起始偏移量。

所述流计算应用正常启动，或者故障恢复后启动时，该方法还包括：

根据所述第二起始偏移量请求消息，同时将所述第一起始偏移量的值更改为第二起始偏移量的值。

所述第二起始偏移量的值为空或者未保存有第二起始偏移量时，所述当前批次消息位于消息中间件的消息队列的起始位置；

同时还包括：设置所述第一起始偏移量的值为空。

所述持久化操作失败，该方法还包括：按照所述第一起始偏移量指示，重新对所述当前批次消息中的消息进行消费。

所述判断是否需要进行持久化操作包括：将所述当前批次的ID除以持久化间隔，当其余数为零时，判断出需要进行持久化操作；

其中，批次ID为从1开始以递增步长为1的整数。

所述流计算应用正常启动，或者故障恢复后启动时，所述批次ID接着流计算应用停止前的最后一个成功持久化过的批次ID继续递增步长为1递增。

本申请还公开一种流计算应用中实现持久化的装置，至少存储模块、判断模块，以及处理模块，其中，

存储模块，其中保存有持久化间隔、用于保存当前正在消费的批次消息在消息队列中的起始位置的第一起始偏移量，以及用于保存最近一次持久化操作的下一批次消息在消息队列中的起始位置的第二起始偏移量；